Hi Alexandru and others !
Thanks for your feedback !
Alexandru Stanoi wrote:
> James Pic wrote:
> A website has three dynamic zones : main, basket and navigation.
>> We discussed of this with Laurent Jouanneau (creator of Jelix), he decided
>> to make a controller of "main" and "zones" for basket and navigation.
>> However, the current requirements involve zone/controller abstraction.
>> So, there should be three controllers : $main, basket and navigation.
>> The input router should select the $main controller, and run "basket" and
>> "navigation" anyway.
>> The output-router should use outputs of these controllers to generate :
>> - the "layout" template,
>> - the "main" template,
>> - the "navigation" template,
>> - the "basket" template.
>> Once the "main" is inserted in the "layout", the new "layout" should
>> have variables to locate placement for "navigation" and "basket".
>> Result : any combination of templates is possible and controllers did not
>> need to select the template.
>
> However I don't really understand everything as it all looks too complex.
> Only in this last mail I see a practical example with the basket and the
> navigation zones. It would have been nice to see more of these examples
> along the way.
>
> But looking at this example, I see a "kill mosquitos with the cannon"
> approach: why is it so complicated that you need 3 controllers, an input
> router and output router just to display a template on the screen?
Making a controller for the basket or the navigation is not mandatory.
You should decide if you want the basket and the navigation to be hard-coded in
the view-handler.
I'm not sure how your basket works, but it can involve many business-critical
checks, the following reasons are valuable in that case :
- controllers can be used "stand-alone", and (almost) natively re-usable with
different protocols,
- testing the input-routers, the view-handlers and the controllers can be done
separately.
Contretly, i'll be asked to make a basket-controller later this year, and to
implement a soap server to interface it. This is just a real-world example.
Elaborations following ...
>
> I don't think that the average web developer knows about things like
> controller and router. He probably knows how to read input from $_GET,
> filter the input, run some SQL queries, create a Template object, pass some
> values to it and voilà! a page is displayed. How would controllers and
> routers simplify these things, or even how would they help in any way?
.mutt/tmp/mutt-paloma-1000-15007-104
22,1 Top
> routers simplify these things, or even how would they help in any way?
I agree that average the developper doesn't need OO or even unit-testing :
I made several average-sized projects in totally procedural code and without
any test, i can elaborate about the pain i've been experiencing in this three
years of maintenance if you want.
I think that this component is usefull for at least medium sized projects.
>
> So I would like to see the answers to the questions:
>
> - why do we need MVC?
It's based on three needs :
- faster development,
- conventions,
- faster testing.
>
> - how to use MVC?
Import your previous routers, controllers or view-handlers if appliable.
Use the tieins to concentrate your efforts on the complex parts of a project in
a first stage.
How to test a router : make the request fixture, make the expected input-object
fixture, run the router with the request fixture, assert that the resulting
input-object matches the expected-input-object-fixture, assert that the expected
view-manager was selected, assert that the expected view-manager was selected.
How to test a controller : make the input-object fixture, make the expected
output-object fixture, run the controller with the input-object fixture, assert
that the result matches the expected-output-object-fixture.
How to test a view-manager : make the output-object fixture, make the expected
response fixture, run the view-handler and assert that the result matches the
response-fixture.
>
> - what benefits does MVC have?
This sounds like agile development of really re-usable classes to me.
That is *my* point of view, and i'm quiet a newbie in *zen* development (i've
made my proofs as a debugger-warrior though).
I've lost more hairs on a couple of projects, than with the thousands of
lemmings
i've managed in my life.
In an unordered and unsorted list :
- convention on testing,
- convention on architecture,
- faster with tieins,
- allowing to concentrate the most challenging parts of a project,
- re-usable ...
--
James Pic
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
