The hardcoded feeling you get with other options is somewhat artificial. You write about using the database and/or XML to derive a pattern for a page's configuration - largely driving (I assume) the placement and construction of page elements. You can use the exact same system in the other direction though - configuring for View Helpers, their construction and placement. A View Helper can interact with the Model (in read only mode), accept parameters, perform presentational logic, etc. Any actual business logic would be encapsulated in the Model that View Helper is using as the basis of its presentation.
I agree that it's a mental shift ;). The main point is that folk are using Actions based on historical and past experiences and missing the gist that most of what makes their interpretation of actions useful is already the core purpose of the View Helper. The trick is noting that a View Helper's complexity is never defined - the framework may offer some subset of relatively simple View Helpers for mundane formatting tasks but this not preclude them being vastly more purposeful and useful. View Helpers can interact with Models, combine work from entire libraries, etc. The only block to such behaviour is the developer's preconceptions ;).
I'd suggest giving it a trial in some simple use case, see how they contrast to your current practice.
Paddy
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative
From: Matthew Weier O'Phinney <matthew@zend.com>
To: fw-mvc@lists.zend.com
Sent: Fri, December 4, 2009 12:02:51 PM
Subject: Re: [fw-mvc] PageController + ActionStack vs. Simple MVC
-- Christian Ehmig <ehmig@boerse-go.de> wrote
(on Friday, 04 December 2009, 02:39 AM -0800):
> I've read some discussions about the "evil" ActionStack in this forum and
> specifically here:
> http://www.rmauger.co.uk/2009/03/why-the-zend-framework-actionstack-is-evil/
>
> I commented on that (#19).
>
> Now my question is - how do you setup Zend MVC for complex, highly
> configurable websites or portals (not only simple blog applications with
> basic CRUD operations). In particular, websites that consist of many conrete
> pages that make use of (hopefully) reusable components.
>
> For me the best solution is still:
>
> 1. Writing a Zend_Controller_Plugin that hooks into routeShutdown()
> 2. in routeShutdown() compile the set of actions, their parameters,
> templates and layout targets from a given page configuration (xml file,
> database) and the layout file to be used for that page
> 3. Push these actions to the ActionStack
> 4. done
>
> Any other approaches seem not reusable and "hard-coded" for me. I can give
> further details on my implementation if needed. I am just curious how others
> solve the issue "a page consists of several actions and their respective
> views".
I've spoken and blogged a ton on this in the last year. The answer: this
stuff is typically either part of your domain model or part of your view
layer, but has nothing to do with your controllers.
If the reason you're using ActionStack is to re-use business logic...
then that logic should be pushed into your models. If the reason you're
using ActionStack is to re-use view scripts, then simply consume those
view scripts. A judicious use of view placeholders and view helpers can
achieve some tremendous results.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
I agree that it's a mental shift ;). The main point is that folk are using Actions based on historical and past experiences and missing the gist that most of what makes their interpretation of actions useful is already the core purpose of the View Helper. The trick is noting that a View Helper's complexity is never defined - the framework may offer some subset of relatively simple View Helpers for mundane formatting tasks but this not preclude them being vastly more purposeful and useful. View Helpers can interact with Models, combine work from entire libraries, etc. The only block to such behaviour is the developer's preconceptions ;).
I'd suggest giving it a trial in some simple use case, see how they contrast to your current practice.
Paddy
http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative
From: Matthew Weier O'Phinney <matthew@zend.com>
To: fw-mvc@lists.zend.com
Sent: Fri, December 4, 2009 12:02:51 PM
Subject: Re: [fw-mvc] PageController + ActionStack vs. Simple MVC
-- Christian Ehmig <ehmig@boerse-go.de> wrote
(on Friday, 04 December 2009, 02:39 AM -0800):
> I've read some discussions about the "evil" ActionStack in this forum and
> specifically here:
> http://www.rmauger.co.uk/2009/03/why-the-zend-framework-actionstack-is-evil/
>
> I commented on that (#19).
>
> Now my question is - how do you setup Zend MVC for complex, highly
> configurable websites or portals (not only simple blog applications with
> basic CRUD operations). In particular, websites that consist of many conrete
> pages that make use of (hopefully) reusable components.
>
> For me the best solution is still:
>
> 1. Writing a Zend_Controller_Plugin that hooks into routeShutdown()
> 2. in routeShutdown() compile the set of actions, their parameters,
> templates and layout targets from a given page configuration (xml file,
> database) and the layout file to be used for that page
> 3. Push these actions to the ActionStack
> 4. done
>
> Any other approaches seem not reusable and "hard-coded" for me. I can give
> further details on my implementation if needed. I am just curious how others
> solve the issue "a page consists of several actions and their respective
> views".
I've spoken and blogged a ton on this in the last year. The answer: this
stuff is typically either part of your domain model or part of your view
layer, but has nothing to do with your controllers.
If the reason you're using ActionStack is to re-use business logic...
then that logic should be pushed into your models. If the reason you're
using ActionStack is to re-use view scripts, then simply consume those
view scripts. A judicious use of view placeholders and view helpers can
achieve some tremendous results.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
没有评论:
发表评论