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
