Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksqTY4ACgkQ3XeSMIaeNkmEYwCeIZWqQDjF+I1n2eK4A//eH5LW
A9UAn2Xpu30hA/+YwkhBbujOS5Yl1+47
=f9ez
-----END PGP SIGNATURE-----
Hi All,
I do not understand the frustrations surrounding actionstack. Maybe
it's just my inexperience with the framework, but what so far my
experiences with actionstack have not been all that bad. I've only been
using ZF at more than just a "hello world" level for only about two weeks.
I do not think that the actionstack is the best solution for highly
complex web pages/portals that require several calls to individual
actions. But to address this problem of needing navigation and other
portal elements (I haven't done this or even provided a proof of
concept, but to me it seems like a reasonable solution), I have to ask
how easy or difficult would it be to apply decorator-pattern objects* to
the response object? Please do not confuse this with Zend_Form
decorators. This is the way that desktop applications work: if you want
a vertical scroll bar applied to a window, you have a VerticalScroll
object to use to apply as a decorator to the window. On a complex ZF
web page, what can be done to add this sort of decorator pattern
functionality? It seems to me that this may be applied at the
postDispatch layer of the controller workflow. I don't think that a
separate layer should be created to add this functionality: my JSON
clients have no need for a navigation. However, depending on what your
response object needs to see (this can be configurable at many stages)
decorators may be applied at this time.
Viktor,
To address 1:
> my application logic (I'm not talking about business logic) goes into
controller plugins and view helpers
It is my understanding that this is the intent of providing views and
plugins. Business logic is for the domain and application logic is for
that particular application view.
> But as I now have very complex view helpers, I sometimes need to
instantiate a new view object within the helper
Sub-classing a view object and adding that needed functionality won't work?
To address 2 and 3:
I see where you're going with this argument, but I think you should keep
in mind that complexity exists in all non-trivial applications,
Photoshop included: it's just hidden from you because it's easy to use.
As a developer, you want to make to make your application easy to use
as well.
Also, there exists a need in which you may want to provide different
interfaces to it via channel other than the web (read: XMLRPC, command
line, and desktop apps). Why recreate the wheel for just because you
want to provide a local desktop application for business users and a web
application for outside contractors, etc?
Disclaimer: Again, I've just started delving deep into ZF, so if I am
wrong in any way please correct me.
* http://en.wikipedia.org/wiki/Decorator_pattern
ViktorG wrote:
> In my opinion this problem is a serious and difficult one and anybody who
> 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".
>>
>
--
Andrew Sledge
andrew.j.sledge@gmail.com
PGP Key: 0x869E3649
http://pgp.mit.edu:11371/pks/lookup?search=0xDD779230869E3649
没有评论:
发表评论