Re: [Components] MVC design draft

[Derick Rethans]

On Sat, 1 Mar 2008, James Pic wrote:

  Delegate most high-level calls to the user?
  ---

[snip]

 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.

Me too.

regards,
Derick

-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[James Pic]

Derick Rethans wrote:
 On Sat, 23 Feb 2008, James Pic wrote:
 
  Thomas Nunninger wrote:
   Am Freitag, 22. Februar 2008 schrieben Sie:
Thomas Nunninger wrote:
 - I'm still not sure if we need controller multiplicity at all. I
 guess, it's a problem of my limited phantasie/experience as I can't
 imagine a situation where I need it. But if we have only one
 controller, we only have one output - I guess, this will reduce
 complexity.

 The only situation, I can imagine you could use it, is a normal
 portal web site, where you have the main content area and e.g.
 left/right a menu, some info boxes, ... that are content
 independant. But I wouldn't use multiple controllers here because
 this is protocoll/interface depending: you want to have a menu in
 the HTML frontend but perhaps not in the SOAP or whatever
 interface.

 In my opinion, you have one request and this request is handled via
 one controller. (If you have a request that includes several
 sub-request, you should not handle this via router - that only has
 the input to decide on the used controller(s) - but in the
 controller, that can call some sub-controllers/-processes.

 Can you give a real world example where you know (from the
 beginning/ the request input) that you need more than one
 controller?
   
Actually, you'd need one controller and several so-called zones
to build the view of the webportal.
   
   Don't know how other systems solve that. In eZ Publish those zones are 
   just some templates that are included in page_layout.tpl. Things like 
   tree menu or a box with latest news are build via template functions 
   that fetch and represent the data. You can argue that this is a little 
   bit against strict MVC as there is some logic inside the templates. But 
   it is somehow intuitive. Also you do not need to touch the core of 
   your application or change some configs if you want to add a new 
   box/zone.
   
  
  That's exactly what i'm talking about. The other problem with zones is that
  their business-logic is limited to what the template is allowed to use.
 
 Wouldn't it make sense for the actions to make sure those zones end up 
 in the output object? the output object itself can just as well be a 
 container.

Instead, shouldn't the view-manager make sure that the zones end up in the view 
?

Regards

-- 
James Pic
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[James Pic]

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
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[James Pic]

Derick Rethans wrote:
 On Sat, 23 Feb 2008, James Pic wrote:
 
  Gaetano Giunta wrote:
  
   - in the end, MVC !== WEB. This is the biggest pain point with all these 
   routing/chaining problems. Mvc was dreamed in a different era, and fits 
   badly to modern-day web apps (unless maybe you do views in javascript). 
   Other things are also staring to show lots of wrinkles, see eg 
   http://www.codinghorror.com/blog/archives/001057.html for a nice insight 
   about keyboard navigation.
  
  I don't understand what you mean, doesn't that strictly depend on the view ?
  Very good article and the comments are even better btw.
 
 I think what he is trying to say is that MVC isn't really meant as a 
 pattern for web applications. It works much better in longer running GUI 
 apps where none of the overhead (router, controllers) have to be 
 reloaded on every request (action).

Isn't that what Mongrel, the HTTP server in Ruby for Rail does ?
I agree that's a good idea but maybe it should be part of another component ?
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[Derick Rethans]

On Sat, 23 Feb 2008, James Pic wrote:

 Thomas Nunninger wrote:
  Am Freitag, 22. Februar 2008 schrieben Sie:
   Thomas Nunninger wrote:
- I'm still not sure if we need controller multiplicity at all. I
guess, it's a problem of my limited phantasie/experience as I can't
imagine a situation where I need it. But if we have only one
controller, we only have one output - I guess, this will reduce
complexity.
   
The only situation, I can imagine you could use it, is a normal
portal web site, where you have the main content area and e.g.
left/right a menu, some info boxes, ... that are content
independant. But I wouldn't use multiple controllers here because
this is protocoll/interface depending: you want to have a menu in
the HTML frontend but perhaps not in the SOAP or whatever
interface.
   
In my opinion, you have one request and this request is handled via
one controller. (If you have a request that includes several
sub-request, you should not handle this via router - that only has
the input to decide on the used controller(s) - but in the
controller, that can call some sub-controllers/-processes.
   
Can you give a real world example where you know (from the
beginning/ the request input) that you need more than one
controller?
  
   Actually, you'd need one controller and several so-called zones
   to build the view of the webportal.
  
  Don't know how other systems solve that. In eZ Publish those zones are 
  just some templates that are included in page_layout.tpl. Things like 
  tree menu or a box with latest news are build via template functions 
  that fetch and represent the data. You can argue that this is a little 
  bit against strict MVC as there is some logic inside the templates. But 
  it is somehow intuitive. Also you do not need to touch the core of 
  your application or change some configs if you want to add a new 
  box/zone.
  
 
 That's exactly what i'm talking about. The other problem with zones is that
 their business-logic is limited to what the template is allowed to use.

Wouldn't it make sense for the actions to make sure those zones end up 
in the output object? the output object itself can just as well be a 
container.

regards,
-- 
Derick Rethans
eZ components Product Manager
eZ systems | http://ez.no
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[Derick Rethans]

On Sat, 23 Feb 2008, Thomas Nunninger wrote:

 Am Samstag, 23. Februar 2008 schrieb James Pic:
 
  Thomas Nunninger wrote:
  
   Don't know how other systems solve that. In eZ Publish those
   zones are just some templates that are included in
   page_layout.tpl. Things like tree menu or a box with latest news
   are build via template functions that fetch and represent the data.
   You can argue that this is a little bit against strict MVC as there
   is some logic inside the templates. But it is somehow intuitive.
   Also you do not need to touch the core of your application or
   change some configs if you want to add a new box/zone.
 
  That's exactly what i'm talking about. The other problem with zones
  is that their business-logic is limited to what the template is
  allowed to use.
 
 As you can create custom template functions, I see no limits. The only 
 important thing is that you have enough information (in eZ Publish this 
 are e.g. the currennt node/object, the user and some other).

But pulling in content by functions reverses the way how content is 
usually rendered. Then you give the templates logic again, instead of 
letting the logic render its data through a template. I think such 
practise should be avoided.

regards,

-- 
Derick Rethans
eZ components Product Manager
eZ systems | http://ez.no
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[Thomas Nunninger]

Hi,

Am Montag, 25. Februar 2008 schrieb Derick Rethans:
 On Sat, 23 Feb 2008, Thomas Nunninger wrote:
  Am Samstag, 23. Februar 2008 schrieb James Pic:
   Thomas Nunninger wrote:
Don't know how other systems solve that. In eZ Publish those
zones are just some templates that are included in
page_layout.tpl. Things like tree menu or a box with latest
news are build via template functions that fetch and represent
the data. You can argue that this is a little bit against
strict MVC as there is some logic inside the templates. But it
is somehow intuitive. Also you do not need to touch the core
of your application or change some configs if you want to add a
new box/zone.
  
   That's exactly what i'm talking about. The other problem with
   zones is that their business-logic is limited to what the
   template is allowed to use.
 
  As you can create custom template functions, I see no limits. The
  only important thing is that you have enough information (in eZ
  Publish this are e.g. the currennt node/object, the user and some
  other).

 But pulling in content by functions reverses the way how content is
 usually rendered. Then you give the templates logic again, instead of
 letting the logic render its data through a template. I think such
 practise should be avoided.

I know about this drawback. But I'm not sure about a good solution 
regarding the problems in my mail(s). What would you suggest? Would you 
prefer multiple controllers or protocoll-specific routers? Do you have 
some other ideas?

Thanks and have a nice day

Thomas
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[James Pic]

Hi Kevin,

Thanks for your feedback !

Kevin Waterson wrote:
 On Thu, 2008-02-21 at 10:56 +0100, Thomas Nunninger wrote:
 
  - I'm still not sure if we need controller multiplicity at all. I guess, 
  it's a problem of my limited phantasie/experience as I can't imagine a 
  situation where I need it. But if we have only one controller, we only 
  have one output - I guess, this will reduce complexity.
 
 Please allow me to show my newbness and suggest a scenario.
 If I have a controller to handle loading, then need to have that
 method load another (admin) router/controller how would this be done?
 eg: Admin page is loaded. Then select from menu to load admin panel for
 blog and then for edit_blog_entry.

You could either use ajax and use one request per controller.
But you could load all the controllers at once for a client-level safe
interface - if we implement controller-multiplicity.

Regards, James.
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[Thomas Nunninger]

Hi,

 We have worked on the design doc on IRC yesterday and it's ready for
 discussion. It does not meet all requirements but we should agree on
 what has been done before talking about the basic error controller
 and such. It's online on
 http://svn.ez.no/svn/ezcomponents/experimental/MvcTools/design/design
.txt

thanks for the document. Some general points first:

- I'm still not sure if we need controller multiplicity at all. I guess, 
it's a problem of my limited phantasie/experience as I can't imagine a 
situation where I need it. But if we have only one controller, we only 
have one output - I guess, this will reduce complexity.

The only situation, I can imagine you could use it, is a normal portal 
web site, where you have the main content area and e.g. left/right a 
menu, some info boxes, ... that are content independant. But I wouldn't 
use multiple controllers here because this is protocoll/interface 
depending: you want to have a menu in the HTML frontend but perhaps not 
in the SOAP or whatever interface.

In my opinion, you have one request and this request is handled via one 
controller. (If you have a request that includes several sub-request, 
you should not handle this via router - that only has the input to 
decide on the used controller(s) - but in the controller, that can call 
some sub-controllers/-processes.

Can you give a real world example where you know (from the beginning/ 
the request input) that you need more than one controller?


- Some new idea regarding the MvcOutput: it could be a nice idea if the 
output object contains a response state like the HTTP response codes. 
This response code should be abstracted as well and mapped (by the view 
manager/handler?) to a correct protocoll response code. Of course it is 
possible to do this myself as the output object is flexible - but it 
would be nice, to ship it with the component. The biggest problem could 
be to find a set of states. Implementation-wise, I think this is one 
class having many constants and some protocoll-specific mapping classes 
for different protocolls.


- Regarding the router/view manager: If I understood correctly, a view 
manager is protocoll-dependant. On which base could the router decide 
to fetch a view manager? If I'm correct, it has the abstract input 
object only.

Regarding this issue and the question about the need of controller 
multiplicity: perhaps we do not need a view manager but only view 
handlers?


  Open issues
  ===
 
  Should the MVC implementation take care of actions/sub-controllers?
  ---
 
  Controllers have a method looking like : run( ezcMvcInput $input )
  It's up to the controller to figure it's action using $input.

 It's possible that some controllers use actions or sub-controllers.
 For example, a CRUD controller should have methods delete and
 create. Should these methods be selected by the controller itself
 or by the router ?

 In many implementation of MVC, each controller public method is an
 action and the router takes care of selecting the method name using
 the HTTP GET variable action or something like that.
 I see pitfalls of such an implementation :
 - controller's common set-up and tear-down should be in protected
 methods, which should *not* be tested.
 - selecting an action using 2 input variables must be done in the
 router. - selecting an action using an external value, like results
 from a database, must be done in the router.

 I'm convinced that the router should only care about selecting the
 controller, even though i see one possible pitfall :
 - complex controllers will have action routing code.

 But, i'm convinced by the benefits :
 - setting up and tearing down can be tested by stubbing the action
 execution in the controller,
 - action routing can be done with more visibility, and is not
 limited to input-variables.

I agree with you to select the action in the controller. In fact, I 
didn't think about choosing it from the router (even we use ZF at 
work). That way, you can have different styles of fetching an action in 
each controller. And if you want to have it done the same way in all 
controllers, you could e.g. write a controller base class that handles 
the action selection.


  Should the router be selected by a router manager?
  --
 
  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.

 I don't see why there should be 2 routers for one same protocol
 either, although this obviously seem a correct design pattern.
 In the rare cases where several routers should be managed, this can
 be done in the index.php file for example, as a temporary solution
 before factorization.

Is the router protocol dependant? I thought, only the input parser and 
the view handler should 

Re: [Components] MVC design draft

[James Pic]

Hi Thomas,

Thanks for your revelant work !

Thomas Nunninger wrote:
 - I'm still not sure if we need controller multiplicity at all. I guess,
 it's a problem of my limited phantasie/experience as I can't imagine a
 situation where I need it. But if we have only one controller, we only
 have one output - I guess, this will reduce complexity.

 The only situation, I can imagine you could use it, is a normal portal
 web site, where you have the main content area and e.g. left/right a
 menu, some info boxes, ... that are content independant. But I wouldn't
 use multiple controllers here because this is protocoll/interface
 depending: you want to have a menu in the HTML frontend but perhaps not
 in the SOAP or whatever interface.

 In my opinion, you have one request and this request is handled via one
 controller. (If you have a request that includes several sub-request,
 you should not handle this via router - that only has the input to
 decide on the used controller(s) - but in the controller, that can call
 some sub-controllers/-processes.

 Can you give a real world example where you know (from the beginning/
 the request input) that you need more than one controller?

Actually, you'd need one controller and several so-called zones to
build the view of the webportal.
If that's what you mean, why not abstract zones from other controllers
making it all implement the same interface ?
This should allow more flexibility and re-usability ...

Basic case :
0) Client requests
cart[add]=123main[ctrl]=browse_itemsbrowse_items[sort]=price
1) Request parser makes an input object from this, which has the same infos.
2) Router selects controllers : cart, browse_items and dynamic_menu.
3) Each are run and there are 3 output-objects.
4) The view-manager parses templates with the output-objects and creates the
response.

Ajax case :
0) Client requests : main[ctrl]=cartcart[remove]=123cart[quantity]=3
1) Request parser makes an input object from this, which has the same infos.
2) Router selects controller : cart
3) cart controller is run and the output object is there.
4) The view-manager parses the templates with the output objects and creates the
response.

The soap case is indeed pretty much like the ajax case because it has one single
controller.

If multiplicity must be encapsulated, i don't think that it's in a decorator
controller, what's your idea ?

.mutt/tmp/mutt-paloma-1000-6427-104 

   19,1   Top
:set nonumber
controller, what's your idea ?


Encapsulate controller multiplicity to avoid the overhead when only one is
used ?


 - Regarding the router/view manager: If I understood correctly, a view
 manager is protocoll-dependant. On which base could the router decide
 to fetch a view manager? If I'm correct, it has the abstract input
 object only.

I remember that Kore pointed this.
Could this be solved by using input *and* output objects in the view-manager to
select the handlers ? I fixed the design docs.


 Regarding this issue and the question about the need of controller
 multiplicity: perhaps we do not need a view manager but only view
 handlers?

If GET[format] = pdf, for example, isn't it the responsability of the
view-manager to select the pdf view-handler ?



   Open issues
   ===
  
   Should the router be selected by a router manager?
   --
  
   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.
 
  I don't see why there should be 2 routers for one same protocol
  either, although this obviously seem a correct design pattern.
  In the rare cases where several routers should be managed, this can
  be done in the index.php file for example, as a temporary solution
  before factorization.

 Is the router protocol dependant? I thought, only the input parser and
 the view handler should be. Rereading the documentation, I see, that
 you talk about an ezcMvcUrlUserInputRouter in the example. Is this
 really neccesary?

Actually, ezcMvcUrlUserInputRouter is just a router that *could* come
with ezcMvcUrlUserInputRequestParser.

We have not though of abstracting the protocol at the router-level afaik, that's
a good point.

Good day and thanks again,
 James.
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[Kevin Waterson]

On Thu, 2008-02-21 at 10:56 +0100, Thomas Nunninger wrote:

 - I'm still not sure if we need controller multiplicity at all. I guess, 
 it's a problem of my limited phantasie/experience as I can't imagine a 
 situation where I need it. But if we have only one controller, we only 
 have one output - I guess, this will reduce complexity.

Please allow me to show my newbness and suggest a scenario.
If I have a controller to handle loading, then need to have that
method load another (admin) router/controller how would this be done?
eg: Admin page is loaded. Then select from menu to load admin panel for
blog and then for edit_blog_entry.

Kevin

-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[Derick Rethans]

On Mon, 11 Feb 2008, Alexandru Stanoi wrote:

 Another thing: I thought Interface should not be part of class names 
 (see ezcMvcRouterInterface and ezcMvcRequestParserInterface).

That is correct.

regards,
Derick
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Re: [Components] MVC design draft

[James Pic]

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 

[Components] MVC design draft

[Thomas Nunninger]

Hi,

is_null, as we didn't manage to chat directly in IRC on weekend, I post 
my questions related to your design draft 
(http://rafb.net/p/VLt8Wm42.html) here on the list...

The questions are about your example code:

// ezcMvcUrlUserInputTieinRequestParser implements
// ezcMvcRequestParserInterface
$parser = new ezcMvcUrlUserInputTieinRequestParser();
 
// The parser returns an instance of ezcMvcInput.
$input  = $parser-getInput();
 
// ezcMvcUrlUserInputTieinRouter implements ezcMvcRouterInterface
$router = new ezcMvcUrlUserInputTieinRouter( $input );
 
// An array of routers
$controllers = $router-getControllers();
// For example, an instance of ezcMvcTemplateTieinHtmlViewManager
$viewManager = $router-getViewManager();
 
foreach( $controllers as $controller )
{
$viewManager-appendOutput( $controller-run( $input ) );
}
 
// Creates the response and sends it to the client.
$viewManager-handle();

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.) 

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.

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.

Also I think, that I'd put some of your script code in the router's(?) 
code. I'd write it somehow like this:


// ezcMvcUrlUserInputTieinRequestParser implements
// ezcMvcRequestParserInterface
$parser = new ezcMvcUrlUserInputTieinRequestParser();
 
// The parser returns an instance of ezcMvcInput.
$input  = $parser-getInput();
 
// ezcMvcUrlUserInputTieinRouter implements ezcMvcRouterInterface
$router = new ezcMvcUrlUserInputTieinRouter();
$output = $router-run( $input );
 
// For example, an instance of ezcMvcTemplateTieinHtmlViewManager
$viewManager = $router-getViewManager( $output );
 
// Creates the response and sends it to the client.
$viewManager-handle();

Or even:

// ezcMvcUrlUserInputTieinRequestParser implements
// ezcMvcRequestParserInterface
$parser = new ezcMvcUrlUserInputTieinRequestParser();
 
// For example, an instance of ezcMvcTemplateTieinHtmlViewManager
$viewManager = new ezcMvcTemplateTieinHtmlViewManager()
 
// ezcMvcUrlUserInputTieinRouter implements ezcMvcRouterInterface
$router = new ezcMvcUrlUserInputTieinRouter(
$parser,
$viewManager
);

$router-run();
 
Btw: Who talked about an eZ Publish rewrite in 10 lines? :-)

Have a nice day

Thomas
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components