Re: [fw-mvc] MVC integration of Zend_Acl

Doing that in the service layer at least prevents from having to choose
between a helper and a plugin! :-)

As you said, when it comes to needs... I find this helper a "simple"
alternative for applications/models not requiring sophisticated acls.

Actually, I hadn't really thought about where to create the acls. Doing it
in the init() method at the controller level makes it easy indeed to add
their own ones.

Matthew Weier O'Phinney-3 wrote:
>
> -- Seth Atkins <satkins@nortel.com> wrote
> (on Friday, 28 August 2009, 12:52 PM -0500):
>> Two main comments from my part. The first is a fairly open ended
>> 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.
>
> Close, but not quite. Order is:
>
> front controller plugin preDispatch
> action helper init()
> controller init()
> action helper preDispatch()
> controller preDispatch()
>
> The only place you can circumvent is at the plugin preDispatch(); if you
> call _forward() later, it will continue to execute through the
> controller preDispatch(); the only thing skipped will be the actual
> controller action (and postDispatch, of course).
>
>> 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.
>
> What action helpers provide you is integration with the action
> controller. Basically, you can place metadata or methods in your action
> controllers that the action helpers can then query (or manipulate) to do
> things.
>
> Some examples of such integration:
>
> * ViewRenderer: sets the view object, as well as renders the view
> script postDispatch() based on the action executed
>
> * ContextSwitch/AjaxContext: if certain properties are set in the
> action controller, will query those to determine if a context was
> invoked, and, if so, change the view script rendered (as well as
> potentially inject response headers)
>
> Basically, what action helpers do is make it easier to place the context
> for a decision close to the decision point.
>
> However, as you note, there may be a performance cost associated with
> this.
>
>> 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.
>
> You have valid points. The points in the proposal are also valid. They
> are very different approaches, however, and there are different
> ramifications involved with both. In your situation, you get good
> execution speed -- but at the cost of having to update ACLs and
> controllers separately. In the approach proposed, your ACLs are part of
> your application structure, making maintenance easy -- but you lose some
> performance.
>
> As I noted earlier, I personally like to put my ACLs with my service
> layer. This means that I'm actually executing my action before I find
> out if the user has the ability to do something -- probably your worst
> nightmare.
>
> However, what this affords me is the ability to re-use my service layer
> for web services -- I can create a service proxy object that I attach to
> Zend_XmlRpc_Server, Zend_Json_Server, Zend_Amf_Server, etc -- and my
> ACLs continue to work as expected. I don't have to do anything different
> whatsoever.
>
>> 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.
>
> Again, as noted above: there are different approaches. Use the one that
> suits your application and/or programming needs.
>
>
>> -----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.
>>
>>
>
> --
> Matthew Weier O'Phinney
> Project Lead | matthew@zend.com
> Zend Framework | http://framework.zend.com/
>
>

--
View this message in context: http://www.nabble.com/MVC-integration-of-Zend_Acl-tp25183254p25212360.html
Sent from the Zend MVC mailing list archive at Nabble.com.