> > > > 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.
Kore makes a good point here. > Output Filters > > ============== > > > > 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 think that was supposed to say 'output' instead of 'input' above. So we could provide charset encoding as an input filter and tidy as an output filter. Those would serve as fairly simple examples. > 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. Since both input and output will likely implement the filter chain pattern, would it make sense to implement that pattern generically? Perhaps as a class in MvcTools; it's probably to simple to warrant its own component. > > 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... The most common basis for view routing will likely be the name of the controller and action called, and possibly the user-agent string or data from the input. For example, the login action is represented in the view by the login template, but you might have separate login templates for Firefox vs IPhone vs JSON requests. The input router is based on evidence from the request, where the view router will be based on evidence from the request plus data sent from the controller.
-- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
