goes deeper into the application logic of ZF will have to handle it.
I will try to explain why (and sorry for my bad English):
1. First of all I decided to eliminate all Action-Stacks from my ZF
projects. It works fine BUT now almost all of my application logic (I'm not
talking about business logic) goes into controller plugins and view helpers.
They do all the important stuff, while the ZF core components are merely
like helpers and plug-ins! I do not know if this is the goal we want to
achieve.
And there are more drawbacks. For example the view object is instantiated
and ready to use in a controller action. But as I now have very complex view
helpers, I sometimes need to instantiate a new view object within the helper
(as I do not want to have HTML markup in the helper class - in contrary to
most of the built in ZF view helpers) and render the view object before it
is passed to the main view/layout. This can be quite confusing and difficult
to maintain.
2. But I think the problem goes even deeper. In my eyes a website or webpage
is always more than a web application and at the same time less than a web
application. I think, most of the ZF developers treat websites like
applications. They treat URLs like command-line commands and command line
arguments. The logic is: one command for one action (and vice versa). This
logic fits for applications, but on a complex portal-site one has a lot of
'actions' that take place under a single URL. So a complex website is more.
At the same time, as PHP is a server based script language, the hole
application has to start on each request from the beginning (in case of ZF
you could say it has to boot on each request). Now this really is a
performance sink. I think that this is the reason why some ZF developers
tend to solve a lot of things with Javascript and Ajax calls. Because then
you only have to call the controller action once, while after that all the
user action on the page is handled via Ajax. See for example Matthew Weier
O'Phinney's pastebin reference implementation.
Other than that in such complex Frameworks you will need to have partial
caching if you do not use Ajax. But I found partial caching really hard to
implement in ZF (action, view, helpers, layout ...).
3. When developing a webportal with a complete CMS as backend you have to be
able to add pages with different functionality to your website within the
CMS. So in the Controller-Action logic this would mean, that you have to be
able to add new Controllers and Actions within your CMS. The problem again
is that people think of a website as an application. An application is
always limited to specific functionality. For example in Adobe Photoshop you
can create and edit images - nothing more nothing less. But in a CMS you
must be able to say: ok, I create a new page where registered frontend users
are able to upload an image (and see their already uploaded images etc.) and
I create another page just with some text and image content but with the
list of the latest news headlines from the news module ...
As within a CMS or backend it is practically not possible to create new
Controllers and Actions for the frontend (if it would be possible your
editors do not need the CMS as they can code PHP and they know how to work
with ZF) you have to fake your way around this (of course with a controller
plugin that takes the URL and compares it to data from a db or xml file and
than changes or defines the controller and action to take). So again a
webportal is not an application, it is in this perspective more like an
operating system, where you can install and configure different
applications, tools and widgets.
And these are only some problems you have to face, the list goes on and on.
I'm not sure if a conservative interpretation of the MVC pattern, especially
the controller part can cope with all these issues.
Best regards Viktor
Christian Ehmig wrote:
>
> 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".
>
--
View this message in context: http://n4.nabble.com/PageController-ActionStack-vs-Simple-MVC-tp948403p965876.html
Sent from the Zend MVC mailing list archive at Nabble.com.
没有评论:
发表评论