On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote: > Hi, this is the updated current points to discuss. > Feel free to comment or add any ;) > > HTTP Request Parser > =================== > > Reminder: the request parser creates the abstract input object. > > 0) Should it allow plugins? > > no > 1) Should filter anything? > > no > 2) Should all the GET/POST variables be mixed together? > > yes
GET variables should be used for view selection, or maybe selection of the data to display, while POST data should be used for modifications. I wouldn't like that those semantic differences between thse two data arrays are lost in the request parser. But since I am able to extend those classes / replace them this isnÄt a big issue. > 3) Should all uploaded files info be in something like $input->files? > > yes > > Input Filters > ============= > > 0) Should the component supply an input filter interface? > > yes > 1) Should the component supply input filters? > > yes, one in a first stage, then many with tieins > 2) Should the component user handle filtering in his controllers? > > yes > > Output Filters > ============== > > 0) Should the component supply an output filter interface? > > yes > 1) Should the component supply input filters? > > yes, one with HTML/Tidy in a first stage, then with tieins I don't see a real necessity for this, as told before, a charset charset encoding conversion filter could be more useful as a simple example... > 2) Should this filters be pluggable in the view-manager? > > no IF we support output filters, they must be pluggable. Hardcoded filters are imho a no-go. > 3) Should this filters be freely usable by the component user once he has his > output from the view manager? > > yes > > Routing > ======= > > 0) Which routed should be developped first? Url, Tree, Regexps, Assertions > (railish) ? A regexp based router is more or less trivial... > View-manager > ============ > > 0) Should the view-manager implement the same routing system as the router? How could that work? I don't think the view routing will be URL based in most cases, but "just" based on the provided view structures. Not sure if some basic general implementation is useful here... > 1) Should another object be used to factorized processes that are common the > the input and the view-router? I don't understand, what you mean here... > View-handlers > ============= > > 0) Which should be the first view handler? > > PhpViewHandler, PHP being a fine templating languages - TemplateTieIn - Plain XML / JSON serialization > PhpViewHandler > -------------- > > 0) How should view methods be implemented? > > In factories/singletons, it should be easy to port to Template extensions I don't see a real reasoning for factories or singletons here. Just something like the following should be sufficant: > $foo->viewRouter = new myViewRouter(); Where the view router then instantiates the proper template and passes the values returned by the controller to the template and maybe also the input structure... -- Mit freundlichen Grüßen / Med vennlig hilsen Kore Nordmann (GPG: 0xDDC70BBB) eZ Components Developer eZ systems Headquarters tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751 [EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
-- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
