Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
On Fri, 20 Jun 2008, James Pic wrote: Kore Nordmann wrote: - Controllers only return some view structure, which may contain semantic information about the data to display or information about the template to use. Did you mean: may *not*? - The view router decides on base of that, what view to actually use. - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. Yes, I think this should be up to the view/view manager. However, we might want to standardize some common UI needs, like with a list of user-messages or something like this: sorry, you don't have the permission to do something. Sorry, please try again later ... Yes, perhaps - although those will never show for normal redirects obviously. Request Parser == Filtering for common actions on every request, for example checking for authentication and sessions. Should the request parser identify the user making the request? I though that we decided to do this in the controller. Yes, we did. Filters can be set on the controller, which are called first and work on the input - modify, action being run at all ... Callbacks? Or a filter configuration? How deep do we want this? I think that when adding a filter to a controller/default controller, they should be callbacks to other classes/methods. This allows us to provide filters in tie-in components (such as for authentication/identification). The actions should have access to the request data, for example to render links to the app back etc. The request parser should not do user identification, this belongs in the controller. The user cannot be authorized on the request level, as you'd need some kind of model / backend to validate the provided data. The user data of course needs to be extracted at this stage and provided to the controller. The user object should be accessible in the view as well, to allow for anonymous/authenticated. Do we want a user interface or something like that? (to make the code portable and testable) Not sure what you mean here, could you provide an example? regards, Derick -- Derick Rethans eZ components Product Manager eZ systems | http://ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
Hi, I just copied the document from google docs, only applying some reformatting. So that the contents will definitely need some refactoring... On Fri, 2008-06-20 at 14:22 +0200, James Pic wrote: Kore Nordmann wrote: - Controllers only return some view structure, which may contain semantic information about the data to display or information about the template to use. Did you mean: may *not*? No. The key point of dispatching the view structures in the view handler are the smatics of information returned by the controller. For example the controller may return a fooUserStructure, so that a special template could be used to display the user information. Another possible way to go is the provide some path to some template in the view structure, which would be possible, but I'd always prefer the first way, but using this both remains possible. - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. No, no protocol specific stuff in controller at all. The key point of this is, that the controller returns something, and the view decides to do a redirect because of the provided view structure. The same for error codes, or whatever. However, we might want to standardize some common UI needs, like with a list of user-messages or something like this: sorry, you don't have the permission to do something. Sorry, please try again later ... This may be implemented in one of our example implementations... Request Parser == Filtering for common actions on every request, for example checking for authentication and sessions. Should the request parser identify the user making the request? I though that we decided to do this in the controller. Yeah - not sure what this point is about. The request parser should of course include such relevant information in the input structure, but the actual filtering is an optional preprocessor step in the controller. Filters can be set on the controller, which are called first and work on the input - modify, action being run at all ... Callbacks? Or a filter configuration? How deep do we want this? Depends on the implementation. I would not want to enforce this, but we should provide an example implementation with a complete filter stack. The user object should be accessible in the view as well, to allow for anonymous/authenticated. Do we want a user interface or something like that? (to make the code portable and testable) I don't think we should specify up to this point. It entirely depends on the view structures you pass back from the controller. Like the first example shows there may be big differences in what users might want there. And it is trivial to provide some application dependant user view structure. Also we said, that we want to include the (unauthorized, unvalidated) in the input strucutre, defined by the request parser and pass this structure also to the view - so the information will probably be available somehow... Kind regards, Kore -- 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] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
Derick Rethans wrote: On Fri, 20 Jun 2008, James Pic wrote: Kore Nordmann wrote: - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. Yes, I think this should be up to the view/view manager. How do we want that standartized for the output object? Here is a short list of proposals: - $output-status: status identifier, like OK, FAIL, REDIRECT ... - $output-redirect: the redirect object, with variables that should be sent and the controllr name - you-name-it However, we might want to standardize some common UI needs, like with a list of user-messages or something like this: sorry, you don't have the permission to do something. Sorry, please try again later ... Yes, perhaps - although those will never show for normal redirects obviously. What do we want? Here is a short list of proposals: - A sort of ArrayObject in $input-messages, that would contain ezcMvcMessage, - $input-locale, that would contain the locale string, - $input-user, that would contain the user object that is doing the request, - $input-protocol, that would contain a protocol identifier, you-name-it ... Filters can be set on the controller, which are called first and work on the input - modify, action being run at all ... Callbacks? Or a filter configuration? How deep do we want this? I think that when adding a filter to a controller/default controller, they should be callbacks to other classes/methods. This allows us to provide filters in tie-in components (such as for authentication/identification). Callbacks or filter-objects directly? I ignore how you want to do this, may you supply a high(system)-level example please? The user object should be accessible in the view as well, to allow for anonymous/authenticated. Do we want a user interface or something like that? (to make the code portable and testable) Not sure what you mean here, could you provide an example? Me neither, yet, I'll come back on this later ;) (for certain tieins) Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
Hi, Kore Nordmann wrote: I just copied the document from google docs, only applying some reformatting. So that the contents will definitely need some refactoring... On Fri, 2008-06-20 at 14:22 +0200, James Pic wrote: Kore Nordmann wrote: - Controllers only return some view structure, which may contain semantic information about the data to display or information about the template to use. Did you mean: may *not*? No. The key point of dispatching the view structures in the view handler are the smatics of information returned by the controller. For example the controller may return a fooUserStructure, so that a special template could be used to display the user information. Mind to show a little example please? - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. No, no protocol specific stuff in controller at all. The key point of this is, that the controller returns something, and the view decides to do a redirect because of the provided view structure. The same for error codes, or whatever. Ok, i understand your point. See my suggestion on the reply to Derick. Request Parser == The user object should be accessible in the view as well, to allow for anonymous/authenticated. Do we want a user interface or something like that? (to make the code portable and testable) I don't think we should specify up to this point. It entirely depends on the view structures you pass back from the controller. Like the first example shows there may be big differences in what users might want there. And it is trivial to provide some application dependant user view structure. Also we said, that we want to include the (unauthorized, unvalidated) in the input strucutre, defined by the request parser and pass this structure also to the view - so the information will probably be available somehow... I agree that we need to ettofate the input structure, mind to add/comment stuff to/in the list that i sent as a reply to Derick please? Thanks for your enlighting feedback! Regards, James. -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
On Mon, 2008-06-23 at 14:41 +0200, James Pic wrote: Derick Rethans wrote: On Fri, 20 Jun 2008, James Pic wrote: Kore Nordmann wrote: - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. Yes, I think this should be up to the view/view manager. How do we want that standartized for the output object? Here is a short list of proposals: - $output-status: status identifier, like OK, FAIL, REDIRECT ... - $output-redirect: the redirect object, with variables that should be sent and the controllr name - you-name-it Imho: No standard. Each view router (or how we called it) may be implemented in a way it makes sense for the respective application. -- 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] [svn-components] 8444 - /experimental/MvcTools/design/discussion_2008_06_20.txt
Kore Nordmann wrote: - Controllers only return some view structure, which may contain semantic information about the data to display or information about the template to use. Did you mean: may *not*? - The view router decides on base of that, what view to actually use. - (HTTP) redirects are also just some view structure, which is returned by the controller, and the view actually performs the proper action depending on the context. Do we want the controller to set HTTP headers in the output object? I'd say that the view-manager should take care of figuring the response code by itself. However, we might want to standardize some common UI needs, like with a list of user-messages or something like this: sorry, you don't have the permission to do something. Sorry, please try again later ... Request Parser == Filtering for common actions on every request, for example checking for authentication and sessions. Should the request parser identify the user making the request? I though that we decided to do this in the controller. Filters can be set on the controller, which are called first and work on the input - modify, action being run at all ... Callbacks? Or a filter configuration? How deep do we want this? filter chain. It is also useful to do on output, for example to gzip or run http tidy and strip out whitespace. The actions should have access to the request data, for example to render links to the app back etc. The request parser should not do user identification, this belongs in the controller. The user cannot be authorized on the request level, as you'd need some kind of model / backend to validate the provided data. The user data of course needs to be extracted at this stage and provided to the controller. The user object should be accessible in the view as well, to allow for anonymous/authenticated. Do we want a user interface or something like that? (to make the code portable and testable) Uploaded files should be handled in the request parser and for example be provided as list of files names in the input object. The Tree component could be part of a router tiein. Things we can provide: - Request parsers for HTTP (with files), mail (with attachments), IM - E-mail routing example like bugzilla, where some specific parts map to the URL. - Controller provider as a tutorial, perhaps with a base code generator. - Model example with PersistentObjectTiein. - A base router, a normal one, one bound on Url, one on the Tree, one that looks like rails (like jetfuel), one based on regular expressions. - A MvcTemplateTiein, as well as a basic PHP view, simple JSON / XML views just encoding the view structures - The router constructs a Url object as part of the input, which then can be used by the action to generate links to other controllers/actions - including a template function for this. Sebastien will suggest a way to use assertions in the router and the view-manager. Regards, James -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
