On Tue, 24 Jun 2008, Kore Nordmann wrote: > 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.
That is a very good point. I definitely agree with this. > > 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... I agree, we can even use the Accept-Charset http stuff for that. > > 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. Sure, but the thing is *where* they are pluggable I think here. James, can you clarify? > > 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... In the discussion document we list different views: template, php and json. regards, Derick -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
