-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODOS
executable file
·166 lines (129 loc) · 6.77 KB
/
TODOS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
GENERAL
-------
TODO: Start making unit tests!
CORE FEATURES/CHANGES
---------------------
TODO: Finish the guide pages.
TODO: Fatal error handler in register_shutdown_function?
TODO: Fix the router class to be flexible, to accept quick regex
or special syntax routes and also accept binding of route
classes. Kind of like the DIC accepts quick bindings to
eliminate the need to code simple factories but also provide
the ability to use provider classes for complex instances.
Figure out the syntax to be used in quick syntax and API
for regex mode.
TODO: Write custom exception classes for core exceptions thrown,
assign error code for them, and then in the exception
handler, you can try to dynamically load pointers and hints
of how the problem began and how to solve it.
TODO: BindingsConfig should be the default behavior for the DIC,
the user should not need to instantiate it and assign it
manually. Let's just make BindingsConfig the fallback, i.e.
executed only if there is no user configuration for the
particular class.
TODO: BindingsConfig should not only read arguments, but also
read default values. If BindingsConfig is in 'auto' mode,
and the object in question has non-object constructor
parameter, then it should also check if it can bypass the
non-object parameter. If it can, it should bypass it.
TODO: BindingsConfig should also have events/special rules.
For example, I want every class implementing LoggerInterface
to be injected with instance of Logger, or maybe I want
every class that uses LoggerTrait to be setter injected with
Logger object, or maybe I want every class that extends
AbstractCanDoLogging class be setter injected with Logger
class. The rules can be about inheritance, traits, interface,
or it can be about namespace (in this namespace, not in this
namespace, in this namespace but not its child), or the class
name (fully qualified or just the class name).
TODO: Make everything easier to use by removing some of the
unnecessary considerations/modifications list:
- Request doesn't need an interface, since it is just used
by our default route classes.
- User can create their own request object and have it
injected to the classes that uses them.
- Refactor routing, think on more simple object design
for routes, router, and URIs.
TODO: Finish the hassle on multibyte routing by forcing some rules
and lowering the requirements:
- Require all PHP files to be written in UTF-8.
- Treat the 'path' part of the URI as UTF-8, as per W3C
specification. There might be isolated cases where the path
part gets sent as Windows-1552, but let's worry about that
later.
- Do not mess with the query strings since the encoding is
more mercurial. Simply do not add default routing capabilities
that makes use of query strings - they are not supposed to
be used as routing anyway, since they are not part of the
'path' part of the URI - you should be able to find some
pointers from W3C recommendations or RFCs on URLs about
the semantics of it.
- If the user wants to deal with non UTF-8 path strings he/she
can use the multibyte routing classes (make one), or they
can create their own route classes.
TODO: The autoloader file should be independent, as in, it should
be able to register autoloading on its own, even though it should
still return the instance of AutoloaderInterface to the caller.
The AutoloaderInterface::register() method should already be
called by the user.
TODO: The configuration object (RouteConfig, InjectionConfig), the
action object (RouteInterface, InjectorInterface) and the mother
object (Router, Container) triad should be used? It seems to be
good OO-design. The configuration object translates the user
configuration into multiple action objects, which is then used
and managed by the mother object.
TODO: Simplify things by hiding advanced configurations?
TODO: Finish the logging part! Find out what is the difference/relationship
between logger and profiler, and see if you can have both in
your framework.
TODO: Don't worry about caching, just finish the architecture first.
Caching should be easily achieved using a good event dispatcher
system. You just need to build the library then.
TODO: Design and code a better Event Dispatcher/Handling system, where
the called method can return something, according to a contract
(an interface?), which can then alter the flow of another part
of the system.
NEW MODULES/CLASSES
-------------------
TODO: Carrot\Session package, get hints from Symfony, add flash
variable, different storage mechanism support, consider
SessionStorageInterface.
TODO: Carrot\Helper\Config, for immutable configuration files.
TODO: Carrot\Helper\URL, with autodetection for base URL and stuff.
TODO: Carrot\Validation package, make it easier to use! Use lambda
function for on the spot validation function, or callbacks.
Take hints from Zend_Validation.
DOCUMENTATION
-------------
TODO: Fix comments on all classes, add @throws to denote exception
thrown, and why it is thrown.
TODO: Fix comments on all classes, add @see to denote protected
class caller.
TODO: Use the 'use' keyword for all classes, but only once.
TODO: Fix comments on Database library (you changed namespaces,
wait for it to stabilize).
DONE
----
TODO: Create an core event manager to handle callbacks (see
Symfony's event handler for inspiration). There would be
events like 'Carrot\Core\System!Bootstrap',
'Carrot\Core\System!ResponseReturned', or
'Carrot\Core\System!RouteDiscovered'. Example use cases
include redirecting links like '/blog/title' to
'/blog/title/' for canonical version, filtering the final
response body, request/response logging, for initializing
PHP session and setting session save settings/handlers
before the script is started, for privilege checking after
routing is done, etc.
CANCELLED
---------
TODO: Inject the DIC and Autoloader to the exception handler for
debugging purposes. Have the DIC log which instance names
are instantiated (how many times) and providers used
(if any). Have the Autoloader load which file is loaded and
what class is expected on that file, the time of the load,
which file gets loaded first, etc.
TODO: Also for debugging purposes, inject the Router to the
ExceptionHandler so that it can read some information from
it, like what is the active route ID and which callback was
returned from the routing.