question I can't answer for you. While an action helper may fit your
needs very well, IMHO, a successful integration is one which serves many
common approaches and is the least limited implementation. For example,
some of the comments so far have related to treating actions as
resources. Many people see actions as privileges on resources, and one
common view of what a resource is is a controller resource. If this is
such a person's view on the subject, an action helper seems fairly
limited since you are dispatching to a controller before you actually
check resource access. I'd rather back things up a few steps and check
before any particular resource is called. But that is my opinion, and I
do know I'm not alone there. I believe, and correct me if I am wrong
here, but the action helper preDispatch() method is called after the
controller init(), which is also after any controller preDispatch()
method, which is also after any plugin preDispatch methods. Seems to me
a lot has happened before you ever checked to see if any of that should
have happened in the first place.
I am less familiar with all the things you can do with an action helper
and how one might wrest it to do your will. My understanding of the ZF
plugin architecture is more detailed since I have spent some time
tracing through the code, how plugins are called, when, etc. Anyway, I
know that plugins can do exactly what I want, but I'm less sure that an
action helper would fit my needs.
The second comment is that plugins are called before ANY dispatching (of
any sort) occurs. Not even a controller init() method has been called
yet. I can create one plugin, set it up in Zend_Application, and all my
ACL code is in one place, once line of code to setup the plugin, and I'm
done. The plugin is post routing, so it has the filtered request object
to work from. You can load your rules and then feed isAllowed your
controller or action name, or whatever criteria you want. If you want
actions to be resources, fine. If you want controllers to be resources
and actions privileges, fine.
And best of all, a plugin can alter the request object before
dispatching occurs. So I can actually redirect without "redirecting", if
you know what I mean, in response to access being denied.
To sum up, I don't think an action helper would be an implementation
that I would personally want to use. I have many modules, many
controllers, many actions, and while, yes, I could write one action
helper and call it from anywhere, I'd really rather not have to write 50
lines of code to just to call it from each controller I happen to have.
And I'd rather not instantiate a controller that a person doesn't have
access to in the first place. Just my 2 cents.
--Seth
-----Original Message-----
From: jThierry [mailto:thierry@jossermoz.net]
Sent: Thursday, August 27, 2009 9:44 PM
To: fw-mvc@lists.zend.com
Subject: [fw-mvc] MVC integration of Zend_Acl
Hi all,
I've been working on a component to realise the MVC integration of
Zend_Acl which is different from the proposal
(http://framework.zend.com/wiki/pages/viewpage.action?pageId=39025) that
seems to be on hold.
I'm using an action helper the perform the checks at pre dispatch time
on controllers implementing Zend_Acl_Resource_Interface instead of a
plugin and am wondering if there's any underlying reason that would
encourage the use of a plugin.
I would really much appreciate your feedback on the action helper
approach.
The code can be found there: http://code.google.com/p/oolala/
Thanks,
Thierry
--
View this message in context:
http://www.nabble.com/MVC-integration-of-Zend_Acl-tp25183254p25183254.ht
ml
Sent from the Zend MVC mailing list archive at Nabble.com.
没有评论:
发表评论