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
