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 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 2) Should this filters be pluggable in the view-manager? > no 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) ? View-manager ============ 0) Should the view-manager implement the same routing system as the router? 1) Should another object be used to factorized processes that are common the the input and the view-router? View-handlers ============= 0) Which should be the first view handler? > PhpViewHandler, PHP being a fine templating languages PhpViewHandler -------------- 0) How should view methods be implemented? > In factories/singletons, it should be easy to port to Template extensions -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
