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 [email protected] http://lists.ez.no/mailman/listinfo/components
