Hello everybody,
NB: Two assumptions were made in this document:
- ViewHandler renaming to View was OK,
- RequestParserManager exists, is required and similar to the View/Router
Manager.
Points are made troughout this document.
Routers can be protocol dependant, view-handlers are protocol dependant.
This is why there is ezcMvcRouterManager, which uses the request object to
instanciate the router; and ezcMvcViewManager which uses the request and result
objects to instanciate the view handler.
When this decision was taken, there were no plans on supplying dispatcher
classes.
The dispatcher that will be provided require three abstract methods to be
implemented, for it's own configuration:
- createViewManager(),
- createRouterManager(),
- createRequestParser(): this one is invalid.
Actually, the email request parser to be shipped in MvcMailTiein
requires a new interface: ezcMvcRequestParserManager, and this method in
the dispatcher:
- createRequestParserManager()
Anyway, allowing to encapsulate parsing the request for different protocol in
different classes is an implicit requirement, even though we want the request
object to be filled with the maximum protocol-independant variables.
Question 0: Aren't these three managers required to configure a dispatcher
causing a useless overhead?
Note that requirements for all the 3 dispatchers that might be proposed have not
been done yet:
- regular dispatcher: usable in production.
- debug dispatcher: usable while developping, would get/display additionnal
variablesi.
- client dispatcher: similar to the django test client:
http://www.djangoproject.com/documentation/testing/#default-test-client
- usable in code only,
- does not require a web-server,
- could be used in unit tests.
- an extension of it could implement some *very simple* http handling
features,
allowing to need a real http server on the production server only (not
listing the other interresting use-cases it could handle).
I have no more information about it for the moment, so it's probably not a good
idea to discuss it now.
However, I'll admit that we want to use several dispatcher for different
purposes.
As we have not worked on possible requirements and design in details yet, i can
only suggest a dispatcher interface *idea*::
<?php
/**
* All supplied dispatchers would implement the following interface.
*/
interface ezcMvcDispatcher
{
/**
* Runs the dispatcher with the passed configuration, (which could have
* been set in the constructor but that's not the point i'm trying to
* make).
*/
public function run( ezcMvcDispatcherConfiguration $configuration )
}
?>
Question 1: Do we want to extend each dispatcher and instanciate the same
RouterManager, RequestParserManager and ViewManager in each?
I think that we want to encapsulate the selection and instanciation of the
router, request parser and view handler in another user-implemented class::
<?php
/**
* You should create your configuration by creating a class implementing this
* interface.
*/
interface ezcMvcDispatcherConfiguration
{
/**
* You should figure the protocol used request your dispatcher and create
* the request parser.
*
* Depending how you intend to expose your application, you should know
* some way to figure the entry point, because you are free to use PHP
* superglobals safely until the request object is instanciated.
*/
public function createRequestParser();
/**
* Create the router that is needed to figure the actual controller that
* will be able to process that request.
*/
public function createRouter( ezcMvcRequest $request );
/**
* View-routing is done here.
*/
public function createView( ezcMvcRequest $request, ezcMvcView $view );
}
?>
This would allow getting rid of the router manager and the view manager.
This would prevent from having to make the difference between view routing and
view handling. Allowing xViewHandler to be renamed to xView, and
createViewHandler() to be createView(). I've assumed that in all this document.
Note that ezcMvcDispatcherConfiguration could implement
ezcMvcRequestParserManager, ezcMvcRouterManager and ezcMvcViewManager, if we
decided to keep them.
Although this won't force you to encapsulate the management of the
request parser, router and view handler in different classes, you can still do
so if you want to::
<?php
class ezcMvcDispatcherManagementConfiguration implements
ezcMvcDispatcherConfiguration extends ezcBaseStruct
{
public $parserManager, $routerManager, $viewManager = null;
public function __construct( ezcMvcRequestParserManager $parserManager,
ezcMvcRouterManager $routerManager,
ezcMvcViewManager $viewManager )
{
$this->parserManager = $parserManager;
$this->routerManager = $routerManager;
$this->viewManager = $viewManager;
}
public function createRequestParser()
{
return $this->parserManager->createRequestParser();
}
public function createRouter()
{
return $this->routerManager->createRouter();
}
public function createView()
{
return $this->viewManager->createView();
}
}
?>
What do you think?
BTW, you are probably interrested in the requirements and designs of
ezcMvcRegexpRouter and ezcMvcTemplateViewHandler that have just been commited
to the respective documents (assumption made because you have read the mail that
far).
Thanks for your attention, thanks in advance for your feedback!
Regards, James.
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
