Re: [Components] [MvcTools] Current points to discuss
On Tue, 24 Jun 2008, James Pic wrote: > Tobias Schlitt wrote: > > On 06/23/2008 04:50 PM James Pic wrote: > > > > > 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) As an example, this filter would identify the user and in some cases, if the user needs to be authenticated, it would change the input object variables to make sure the "login" controller is used instead. > > > 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. Yeah, they're still different "routers" though. > > > View-manager > > > > > > 0) Should the view-manager implement the same routing system as the > > > router? > > What are the other options? I think I'd like to see an example on how this would work :) > > > 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. I'd like to have something here that also allows view selection based on user agent strings. For example rendering for mobile devices such as iPhone. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
On Mon, 23 Jun 2008, Joe Kepley wrote:
> > 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
>
>
> Given that it would be bad form to have a GET and POST variable of the same
> name on the same request, I'd agree with this. The system should give higher
> priority to POST vars vs GET vars to help avoid very simple variable
> spoofing.
I think it should still be configurable though - atleast the order of
overriding.
> > 3) Should all uploaded files info be in something like $input->files?
> > > yes
>
> What would the interface for this look like? Suppose I have two fields on my
> input form that take files, maybe and
> . Would this be $input->files['resume'] and
> $input->files['picture']?
>
> Perhaps a cleaner implementation would be to have an object that represents
> the uploaded file, and mix that in with the other input fields.
>
> Let's suppose we have a form with these fields: name(text), email(text),
> picture(file), and resume(file). Maybe my input structure would look like
> this:
>
> $input->parameters: Array('name'=>'Bob Example', 'email'=>'[EMAIL PROTECTED]',
> 'picture'=>[some object representing an uploaded file], 'resume'=>[some
> object representing an uploaded file])
>
> We could have something like an HTTPUploadedFile class with attributes for
> file name, mime type, size, tmp file name, and error code. A saveTo() method
> that calls move_uploaded_file would offer some syntatic sugar as well. Then
> I could say things
> like: $input->parameters['resume']->saveTo('resumes/xyz.doc');
>
> Thoughts?
Sounds like an idea.
regards,
Derick
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
Derick Rethans wrote: > On Tue, 24 Jun 2008, James Pic wrote: > > Tobias Schlitt wrote: > > > On 06/23/2008 04:50 PM James Pic wrote: > > > > 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. > > I'd like to have something here that also allows view selection based on > user agent strings. For example rendering for mobile devices such as > iPhone. Of course, you can do this, as long as the request parser sets the user-agent in the input object. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Roadmap for the next release
On Tue, 24 Jun 2008, Andreas Schamberger wrote: > I'm missing the translation string extraction for templates in the Roapmap. > I can offer to finish the ezlupdate.php that I started to a complete command > line script that also has the ability to create the neccessary TS files for > new languages. Ah, sorry - I forgot about this :-/ I'd greatly appreciate it of you could help us with this one. I'll add an issue to the tracker for it though. regards, Derick PS: Please keep cc-ing the mailinglist on replies. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
On Tue, 24 Jun 2008, James Pic wrote:
> Joe Kepley wrote:
> >
> > We could have something like an HTTPUploadedFile class with attributes for
> > file name, mime type, size, tmp file name, and error code. A saveTo() method
> > that calls move_uploaded_file would offer some syntatic sugar as well. Then
> > I could say things
> > like: $input->parameters['resume']->saveTo('resumes/xyz.doc');
> >
> > Thoughts?
>
> Sounds like that could use a proxy from MvcUserInputTiein...
> I really like this idea.
Actually, UserInput just does filtering - it does not handle uploaded
files. Honestly, I think we might need to consider to forget about
UserInput a bit first.
regards,
Derick
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Roadmap for the next release
On Tue, 24 Jun 2008, Derick Rethans wrote: > On Tue, 24 Jun 2008, Andreas Schamberger wrote: > > > I'm missing the translation string extraction for templates in the Roapmap. > > I can offer to finish the ezlupdate.php that I started to a complete command > > line script that also has the ability to create the neccessary TS files for > > new languages. > > Ah, sorry - I forgot about this :-/ I'd greatly appreciate it of you > could help us with this one. I'll add an issue to the tracker for it > though. I added an issue now: http://issues.ez.no/IssueView.php?Id=13236&; Perhaps we can kick start this off by creating a requirements document? regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
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
Re: [Components] [MvcTools] Current points to discuss
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 Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
Derick Rethans schrieb: > 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. I definitively aggree with you. I'd also suggest to use more of the HTTP protocol available request methods, e.g. PUT for additions/creations and DELETE for drops/removements. This would allow to reuse the same route with four different actions, just by switching the request methods. Cheers, Pierre -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
Hi, Thanks Kore and Pierre for the input! Pierre Minnieur wrote: > Derick Rethans schrieb: >> 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. > > I definitively aggree with you. > > I'd also suggest to use more of the HTTP protocol available request > methods, e.g. PUT for additions/creations and DELETE for drops/removements. > > This would allow to reuse the same route with four different actions, just > by switching the request methods. Problem, we want protocol abstraction, and we want protocol dependant variables. All i can think of filling $input->method with the request parser, but depending on that in the controller is definitively not something we want to do. So, we could specify our own methods, that would be translated in the view-handler and request parser. This way, we could use restfull interface transparently from the protocol. Any suggestion? Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
Derick Rethans wrote: > On Tue, 24 Jun 2008, Kore Nordmann wrote: > > On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote: > > > Output Filters > > > == > > > 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? I though that we could use a list of filter objects in the view-manager constructor. Because the view-manager wraps around the view-handlers, it could either be fed into the view-handler, either be used at the view manager level. > > > > 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. The view-manager should be free to use the input and output objects to figure which view-handler to use? Regards, James -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Current points to discuss
> > > > 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 Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] [MvcTools] Protocol abstraction levels
We want protocol specific variables in the protocol specific view-handler. That means, that the request parser should take some variables and put it somewhere for the view-manager later. OPtions we could think of: - add protocol specific variables in the input object, - make two input objects, a raw input object and a protocol abstract input object Thanks in advance for your input! Regards, James -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Protocol abstraction levels
Hi! On 06/24/2008 01:59 PM James Pic wrote: > We want protocol specific variables in the protocol specific view-handler. > That means, that the request parser should take some variables and put it > somewhere for the view-manager later. > OPtions we could think of: > - add protocol specific variables in the input object, > - make two input objects, a raw input object and a protocol abstract input > object I'd go for the first version. In case more information must be transported, one can extend the input object. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Protocol abstraction levels
Tobias Schlitt wrote: > Hi! > > On 06/24/2008 01:59 PM James Pic wrote: > > We want protocol specific variables in the protocol specific view-handler. > > That means, that the request parser should take some variables and put it > > somewhere for the view-manager later. > > > OPtions we could think of: > > - add protocol specific variables in the input object, > > - make two input objects, a raw input object and a protocol abstract input > > object > > I'd go for the first version. In case more information must be > transported, one can extend the input object. Other possibility:: createRequest(); // 1) Make the abstract input object $input = $request::createInput(); // 2) Get the controller // Note that the router has the input abstract object $controller = $router->createController( $input ); // 3) Run the controller // Again, with the abstract input object $output = $controller->run( $input ); // 4) Handle the view // The view-handler is protocol specific, thus has the complete request object $viewManager = new yourViewManager( $request ); $viewManager->handle(); ?> -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Protocol abstraction levels
On Tue, 24 Jun 2008, James Pic wrote: > Tobias Schlitt wrote: > > Hi! > > > > On 06/24/2008 01:59 PM James Pic wrote: > > > We want protocol specific variables in the protocol specific view-handler. > > > That means, that the request parser should take some variables and put it > > > somewhere for the view-manager later. > > > > > OPtions we could think of: > > > - add protocol specific variables in the input object, > > > - make two input objects, a raw input object and a protocol abstract input > > > object > > > > I'd go for the first version. In case more information must be > > transported, one can extend the input object. > Other possibility:: > > // 0) This request object has protocol specific stuff > $request = $requestParser->createRequest(); > > // 1) Make the abstract input object > $input = $request::createInput(); The $input object could be an child class of the request input object, so that you still *could* pass it to the controller, but you really shouldn't. This makes this more flexible for the cases where you want it to, but you'd lose the nice encapsulation. By creating an input object then you make it clean, but more restrictive. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Protocol abstraction levels
On Tue, 24 Jun 2008, Derick Rethans wrote: > On Tue, 24 Jun 2008, James Pic wrote: > > > Tobias Schlitt wrote: > > > > > > On 06/24/2008 01:59 PM James Pic wrote: > > > > We want protocol specific variables in the protocol specific > > > > view-handler. > > > > That means, that the request parser should take some variables and put > > > > it > > > > somewhere for the view-manager later. > > > > > > > OPtions we could think of: > > > > - add protocol specific variables in the input object, > > > > - make two input objects, a raw input object and a protocol abstract > > > > input > > > > object > > > > > > I'd go for the first version. In case more information must be > > > transported, one can extend the input object. > > Other possibility:: > > > >> // 0) This request object has protocol specific stuff > > $request = $requestParser->createRequest(); > > > > // 1) Make the abstract input object > > $input = $request::createInput(); > > The $input object could be an child class of the request input object, > so that you still *could* pass it to the controller, but you really > shouldn't. This makes this more flexible for the cases where you want it > to, but you'd lose the nice encapsulation. By creating an input object > then you make it clean, but more restrictive. We just had a little discussion, and decided not to go with this. We'd still "abstract" some of the raw request data, but always make the raw request data available through a "raw" array. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Roadmap for the next release
Derick Rethans a écrit : > Hello, > > We've created a roadmap for the upcoming (2008.2) release. In this > release our main focus is to add MVC support to the eZ Components. > Besides this main focus, we will also enhance some of the critical > components that the upcoming version of eZ Publish will require. > > Please see http://ezcomponents.org/overview/roadmap for the full > roadmap. > > regards, > Maybe all the involved parties know much more about the topic at hand than I do, but anyway - this page (http://trac.symfony-project.com/wiki/ComparingPropelAndDoctrine) has a neat little summary comparison of propel vs doctrine. It looks like Doctrine is already quite smart to minimize queries when fetching related objects - something that is on the roadmap for the next version. Ideas to be copied from? -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [MvcTools] Protocol abstraction levels
Derick Rethans a écrit : On Tue, 24 Jun 2008, Derick Rethans wrote: On Tue, 24 Jun 2008, James Pic wrote: Tobias Schlitt wrote: On 06/24/2008 01:59 PM James Pic wrote: We want protocol specific variables in the protocol specific view-handler. That means, that the request parser should take some variables and put it somewhere for the view-manager later. OPtions we could think of: - add protocol specific variables in the input object, - make two input objects, a raw input object and a protocol abstract input object I'd go for the first version. In case more information must be transported, one can extend the input object. Other possibility:: createRequest(); // 1) Make the abstract input object $input = $request::createInput(); The $input object could be an child class of the request input object, so that you still *could* pass it to the controller, but you really shouldn't. This makes this more flexible for the cases where you want it to, but you'd lose the nice encapsulation. By creating an input object then you make it clean, but more restrictive. We just had a little discussion, and decided not to go with this. We'd still "abstract" some of the raw request data, but always make the raw request data available through a "raw" array. I think I second that. It sounds unclean compared to the other proposed approach, but it ends up in being far more flexible, ie. users could build whacky routers/view managers without getting lost in a maze of subclasses. As an example, a typical (?) controller I built tries to answer to multiple-protocol webservice calls, sniffing in order something like this: - GET and no query string => route to ws documentation intro page in html - GET and query string => route to ws action, using rest decoding of params and output view (another option: route to html doc of a single webservice and/or in a given language, and/or in a given format etc...) - POST: check out request http headers to find out if there is any soap header => route to ws action, with soap view - POST with application/json request http content-type => route to ws with jsonrpc view - POST with form-encoded content => route to ws action, using rest view - POST with xml request http content-type => route to ws with xmlrpc view - POST with no discernible http headers => route to ws using jsonrpc (if it decodes the request successfully) this means that GET, POST (in its RAW_DATA form) and http headers could all be needed for the router to make its informed decision. Another unconventional router could be used to parse parameters given from the CLI - I just hate that symfony now deprecates using dispatch() for cli stuff... -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
