Hello everybody, It's good that the link posted by Thomas N. is down because the document's quality was very low (a first try).
You'll notice that this document really concentrates on system-conception (high-level and general); because I beleive that I'm bound to fail at real object-conception and implementation questions before working a little more at this stage with everybody :) Feel free to contradict me on that, the document is at an early draft stage anyway. It's attached to this message, and integrates (not brillantly) Thomas N.'s revelant suggestion. Thomas Nunninger wrote: > Can you give an example, where it is usefull (at the beginning of > request handling) to fetch a set of controllers? Perhaps I'm blind or > I'm thinking in a wrong direction, but I can't imagine a situation > where I need this. (Of course, you could need re-routing, but I guess, > this is the result of the controller. Before running the first > controller, I do not know about a second controller.) In some popular MVC-implementations supplied by frameworks, the HTML view is built with a controller and "zones". Assuming that the view manager has the mechanism to render the complete HTML body : "zones" should be abstracted from controllers; making "zones" to not be dependant and more testable and portable. Note that i haven't though very deep about re-routing yet because i still assume that adding a few methods to the router interface for this will suit the needs, but i can be wrong. > > The second point is somehow related: you append several outputs to the > view manager. I'm not sure, if I like this. I think, there should be > one output object. Won't that cause the output object to implement controller-namespace on variables ? > If I'd need something like a set of controllers or outputs, I guess, I'd > implement a controller container that runs the several needed > controllers, and then composes one output object from the several > returned output objects. I pretty sure that it's agile to make a list-class for controllers and their outputs, but could you to elaborate please :) > > Also I think, that I'd put some of your script code in the router's(?) > code. I'd write it somehow like this: > > $parser = new ezcMvcUrlUserInputRequestParser(); > > // The parser returns an instance of ezcMvcInput. > $input = $parser->getInput(); > > $router = new ezcMvcUrlUserInputRouter(); > $output = $router->run( $input ); > > // For example, an instance of ezcMvcTemplateTieinHtmlViewManager > $viewManager = $router->getViewManager( $output ); I think that the router should be able to access the output object when selecting the view manager as well. > > // Creates the response and sends it to the client. > $viewManager->handle(); > > Or even: > > $parser = new ezcMvcUrlUserInputRequestParser(); > > $viewManager = new ezcMvcTemplateHtmlViewManager() Do the requirements allow this or is it the role of the router to select between ezcMvcTemplateHtmlViewManager and ezcMvcPdfViewManager for example, depending on the client request (like GET $pdf = true for example). > > // ezcMvcUrlUserInputTieinRouter implements ezcMvcRouterInterface > $router = new ezcMvcUrlUserInputRouter( > $parser, > $viewManager > ); > > $router->run(); Won't that cause too much dependencies ? Do we need view management to depend on controller interface or should it depend only on output and input objects ? Thanks a lot for your feedback, revelant suggestions and constructive discussion on IRC Thomas ! Cheers ! -- James Pic /me *hopes* that his message is understandable by english-speakers :)
eZ component: MvcTools, Design Draft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :Author: James Pic, Kore Nordmann, Thomas Nunninger :Revision: $Rev$ :Date: $Date$ :Status: Draft .. contents:: Scope ===== The scope of this document is to describe the initial design of a component that provides classes to implement a MVC_ architecture for a web application. .. _MVC: http://en.wikipedia.org/wiki/Model-view-controller Design overview =============== Because of the variaty of protocols and formats that a modern PHP application should handle, this MVC implementation will provide an abstraction to input and output of controllers. Besides that, a few tieins will be provided. The main classes of this component are ezcMvcInput and ezcMvcOutput, which are respectively the abstract input object for the controller and the abstract output object that the controller should return. Additionally, a collection of interfaces will be provided for routing, request-parsing, view-managing and view-handling. Layers ====== The component is basically devided into 4 layers: the request parsing layer is represented by an interface. An instance of such a class is responsible for parsing the request and making an abstract input object. The routing layer is in charge of selecting the controller(s) and the view manager, using the abstract input object. Controllers are the third layers, at this level : classes process the request and select the data to use for making the response : controllers accept the abstract input object and are responsible for returning an abstract output object. View management is the final layer, using on the output and input objects : the view-manager use the view-handler(s) to create the formatted final response to send to the client. Classes ======= ezcMvcRequestParser ------------------- The ezcMvcRequestParser interface has to be implemented by classes that will parse the request and create an ezcMvcInput object. ezcMvcInput ----------- This object encapsulates the client-request, abstracting the request-protocol. ezcMvcOutput ------------ This object encapsulates the controller result, abstracting the response protocol. ezcMvcRouter ------------ This interface is in charge of using an instance of ezcMvcInput to select the controller(s) and the view-manager. ezcMvcViewManager ----------------- This interface has to be implemented by classes that are in charge of rendering the instance(s) of ezcMvcOutput into a format acceptable for the response protocol, using view-handlers. ezcMvcViewHandler ----------------- This interface has to be implemented by classes that handle rendering one ezcMvcOutput object into one formated (part of the) response string. Possible system conceptions =========================== Encapsulate view handler multiplicity into a view-manager ? ----------------------------------------------------------- This will free the router and user-space from rendering tasks, particularely useful when using several controllers at once. I think that the component should provide such a class, letting to concentrate on working on view handlers. The following snippet shows the API calls necessary in the user's public script, in that case :: <?php // ezcMvcUrlUserInputRequestParser implements ezcMvcRequestParser $parser = new ezcMvcUrlUserInputRequestParser(); // The parser returns an instance of ezcMvcInput. $input = $parser->getInput(); // ezcMvcUrlUserInputRouter implements ezcMvcRouter $router = new ezcMvcUrlUserInputRouter( $input ); // An array or list-class with controllers $controllers = $router->getControllers(); // For example, an instance of ezcMvcTemplateHtmlViewManager $viewManager = $router->getViewManager(); // Takes care of running the controllers and rendering their results $viewManager->handle( $controllers ); Attempt of representing a common use case, assuming classic HTML over HTTP : 0) $parser can be used to fetch an instance of ezcMvcInput, wrapping all the client request variables : widget[action]=add&widget[id]=3&menu[selected]=widget 1) $router can be used to fetch a set of controllers : myMvcWidgetController and myDynamicMenuController. 2) $router can be used to fetch the view-manager : ezcMvcTemplateHtmlViewManager. 3) The view manager runs both controllers, and processes two templates using the controllers resulting output object along with ezcMvcTemplateHtmlViewHandler : menu.tpl, widget.tpl 3.0) The widget template has a $menu variable that is replaced by the processed menu.tpl and the response is ready. 3.1) Alternative way : the view manager processes main_layout.tpl, which contains $menu and $widget (or $main instead of $widget) that are replaced by menu.tpl and widget.tpl. 3.2) The view-manager can send HTTP-headers. Encapsulate controller multiplicity outside the router ? -------------------------------------------------------- The following snippet shows the API calls necessary in the user's public script, in that case :: <?php $parser = new ezcMvcUrlUserInputRequestParser(); $input = $parser->getInput(); $router = new ezcMvcUrlUserInputRouter(); $output = $router->run( $input ); $viewManager = $router->getViewManager( $output ); // Creates the response and sends it to the client. $viewManager->handle(); Or even :: <?php $parser = new ezcMvcUrlUserInputTieinRequestParser(); $viewManager = new ezcMvcTemplateTieinHtmlViewManager() $router = new ezcMvcUrlUserInputTieinRouter( $parser, $viewManager ); $router->run(); .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79
-- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
