Hi Tobias, Thanks for your input!
Tobias Schlitt wrote:
> On 06/23/2008 04:50 PM James Pic wrote:
> > 1) Should filter anything?
> >> no
>
> Same as above. Filtering should usually be done in the models, IMO.
Are you sure that persistent object classes should accept invalid values and try
to filter them?
> > 2) Should all the GET/POST variables be mixed together?
> >> yes
>
> No. Or, if necessary, we should offer both: A mixed and single versions.
> It might be possible, that both arrays contain the same keys.
Do you mean that input object should be protocol independant by default, but
allow to identify the protocol of a variable?
> > Input Filters
> > =============
> > 0) Should the component supply an input filter interface?
> >> yes
>
> Not sure here. How would that look like?
interface filter
{
ezcMvcInput public function filter( ezcMvcInput $input );
}
>
> > 1) Should the component supply input filters?
> >> yes, one in a first stage, then many with tieins
>
> We only have UserInput for this purpose, so this would make 1 tiein.
We might want to make an "authentication filter" tieing Authentication, which
would identify the user making the request.
And probably other filters like that. (That is why i called it plug-ins)
>
> > 2) Should the component user handle filtering in his controllers?
> >> yes
>
> Why then an iterface for it? This makes only sense, if we offer
> automatic filtering.
We might want to maintain consistency between filters, to provide a
chain-filtering class.
This would require to only select the filters in the controllers, running them
would be encapsulated.
This might also has some testing benefits ...
> > Output Filters
> > ==============
> > 1) Should the component supply input filters?
> >> yes, one with HTML/Tidy in a first stage, then with tieins
>
> Why this for input?
My bad, thanks!
> > 2) Should this filters be pluggable in the view-manager?
> >> no
>
> Where else will they be plugged then?
Actually, it could not be plugged at all, and directly used by the user *after*
the view-manager returned the response strings.
On the other hand, i'm generally for plug-in systems, i think its really nice
to test.
> > Routing
> > =======
> > 0) Which routed should be developped first? Url, Tree, Regexps, Assertions
> > (railish) ?
> Something without a tiein. I think railish and regex sounds like a good
> start.
> > View-manager
> > ============
> > 0) Should the view-manager implement the same routing system as the router?
> What are the other options?
> > 1) Should another object be used to factorized processes that are common the
> > the input and the view-router?
> What do you imagine here?
If the user should develop the router with the same logic than the view-manager,
maybe we want to have only one router, that decides which controller *and*
view-handler to use.
> > View-handlers
> > =============
> > PhpViewHandler
> > --------------
>
> > 0) How should view methods be implemented?
> >> In factories/singletons, it should be easy to port to Template extensions
>
> Don't really get this question.
We might need some view-generation methods, like we would use template
extensions.
How to implement this is PhpViewHandler?
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
