Hello everybody, I fixed consistency between design and requirements docs, and merged our latest conclusions.
http://svn.ez.no/svn/ezcomponents/experimental/MvcTools/design/requirements.txt http://svn.ez.no/svn/ezcomponents/experimental/MvcTools/design/design.txt Also, please give your opinion about the following issues, which should be fixed before the design becomes final. > Delegate most of the high-level mechanisms to the router? > --------------------------------------------------------- > > The following snippet shows the API calls necessary in the user's public > script, in that case :: > <?php > $parser = new ezcMvcExampleRequestParser(); > > $input = $parser->createInput(); > > $router = new ezcMvcExampleRouter(); > $output = $router->run( $input ); > > //$viewManager = $router->getViewManager( $output ); > $viewManager = new ezcMvcExampleViewManager(); > > // Creates the response and sends it to the client. > $viewManager->handle( $input, $output ); > > Or even :: > > <?php > $parser = new ezcMvcExampleRequestParser(); > > $viewManager = new ezcMvcExampleViewManager() > > $router = new ezcMvcExampleRouter( > $parser, > $viewManager > ); > > $router->run(); Thomas, can you give some arguments about your idea if you want to keep it please ? Else, we have another use-case, which follows. > Delegate most high-level calls to the user? > ------------------------------------------- > > :: > > #0 Invocation of a request-parser > $parser = new ezcMvcExampleRequestParser(); > > #1 Creation of the abstract input > $input = $parser->createInput(); > > #2 Invocation of a router > $router = new ezcMvcExampleRouter(); > > #3 Creation of the controller > $controller = $router->createController( $input ); > > #4 Creation of the abstract output > $output = $controller->run( $input ); > > #5 Invocation of a view-manager > $viewManager = new ezcMvcExampleViewManager(); > > #6 Creation and send of the response > $viewManager->handle( $input, $output ); > > For testing/debugging purposes, it's possible to get the generated response > body and header individually:: > > #6.1 Create the response body > $viewManager->createResponseBody( $input, $output ); > > #6.2 Create the response header > $viewManager->createResponseHeader( $input, $output ); > > Of course, it's possible to implement MvcTools in an OOP way instead of a > procedural way, like for every component:: > > class myMvcRunner > { > public function run() > { > $parser = $this->createParser(); > $input = $parser->createInput(); > $router = $this->createRouter(); > $controller = $router->createController(); > $output = $controller->run( $input ); > $viewManager = $this->createViewManager(); > $viewManager->handle( $input, $output ); > } > protected function createParser() > { > // mechanisms ... > return $parser; > } > protected function createRouter() > { > // mechanisms ... > return $router; > } > protected function createViewManager() > { > // mechanisms ... > return $viewManager; > } > } > We should choose one of those three possible implementations. I prefer the second one because i think that it makes classes to be less dependant : more testable. > > Should the MVC implementation take care of actions/sub-controllers? > ------------------------------------------------------------------- > Currently : > Controllers have a method looking like : run( ezcMvcInput $input ) It's up to > the controller to figure it's action using $input. Kore proposed the the controller implement one method per action. Kore, can you please elaborate on your current position ? > > Definition of the ezcMvcController interface > -------------------------------------------- > > The description and definition of the ezcMvcController interface should be > reworked. The expected behaviour and API of classes implementing this > interface should be described in more details. Currently, controllers implement one method:: ezcMvcOutput public function run( ezcMvcInput $input ) Of course, this depends on delegating selection of the action to the controller. > > Should the router be selected by a router manager? > -------------------------------------------------- > Currently, Tobias and I had chosen : > The router could be selected by a router-manager. In that case, some routing > mechanism should be in the router manager. Router-manager shouldn't be > implemented, routers should be factorized instead. Please agree or argue :) -- James Pic -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
