#5 Reasons that make Acl difficult
I just wrote a good sized article about my experiences with CakePHP and Acl that has a list of 5 things that I believe make it very difficult for most people, when trying to get their first Acl experience. So in order to prevent other people from going through the same issues I thought it would be appropriate to send out a little notice to the group. The article can be found over at: http://www.thinkingphp.org --Felix Geisendörfer aka the_undefined --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: #5 Reasons that make Acl difficult
I believe you can update the wiki with that information too.Keeping the wiki up to date will help.On 5/31/06, the_undefined [EMAIL PROTECTED] wrote:I just wrote a good sized article about my experiences with CakePHP and Acl that has a list of 5 things that I believe make it very difficultfor most people, when trying to get their first Acl experience.So in order to prevent other people from going through the same issues I thought it would be appropriate to send out a little notice to thegroup.The article can be found over at:http://www.thinkingphp.org--Felix Geisendörfer aka the_undefined --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: #5 Reasons that make Acl difficult
And thanks for writing the article..On 5/31/06, John Zimmerman [gmail] [EMAIL PROTECTED] wrote: I believe you can update the wiki with that information too.Keeping the wiki up to date will help. On 5/31/06, the_undefined [EMAIL PROTECTED] wrote:I just wrote a good sized article about my experiences with CakePHP and Acl that has a list of 5 things that I believe make it very difficultfor most people, when trying to get their first Acl experience.So in order to prevent other people from going through the same issues I thought it would be appropriate to send out a little notice to thegroup.The article can be found over at: http://www.thinkingphp.org--Felix Geisendörfer aka the_undefined --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: #5 Reasons that make Acl difficult
Since most of the article directly references stuff I've worked on, let me comment a bit: First and foremost, I want to come out and say, that the wiki is *not* official documentation. Its a wiki. Its days are numbered, and will personally burn an effigy of the wiki when it meets its maker in the coming weeks/months. Use it at your own risk, people. Example 1 The manual explains that dbACL is made up of a set of core models. These models are used by Cake... etc. Its all in section three. Do a search in the manual for model in that chapter, and you'll see that it's everywhere. Point taken about the uses(), though. Maybe I assumed that people would know if you want to use a model that's not a controller's model, you need to use uses(), but I can see how that would be hard to come by for newcomers. Example 2 Yeah, the wiki is wrong. It seems a little funny for someone to complain about the verity of a wiki page because for one, they have full power to change it. The user_id/link_id field allows you to hitch your ACL objects to real models. Its not for unique identification of the actual node itself. I'm not even sure what the rant is here, but I think you've missed the point of the user_id field. Example 3 Yet another bad wiki example. Seeing a pattern with the wiki? Why are you still referring to it? Reason #3 Um, the user_id isn't supposed to auto_increment because it is used as a link to another table. Its a normal foreign key to another model in your app. Same goes with object_id. ACL is a structure that sits completely separate from your other data. By leaving those fields in, you can tie a given ACO/ARO to an actual model in your application. I think most of the frustration you've encountered is because of a misunderstanding about how the system works. Maybe I haven't explained it well enough. : / Reason #4 Why should you care how the data is stored and retrieved, as long as it is working well? This is a framework after all, and part of the advantage is you don't have to know the ins and outs of the guts in order to make magic with it. You don't have to know *anything* about MPTT to use ACL like a pro. Reason #5 Bugs are best reported to trac if you have them. I suppose that goes without saying. I realize you cover that in your article, but... you can spend a few hours writing up a section because you got mad, or you can log in to trac or IRC to actually help out. This project lives on user contribution, and I'm not sure how this article contributes to the project. I'm really open and willing to make some improvements here, but writing an article out of anger rather than going through the correct channels is definitely a less effective use of time. I'd be glad to put some of that writing urge to use in the manual ;) -- John On May 31, 2006, at 11:31 AM, the_undefined wrote: I just wrote a good sized article about my experiences with CakePHP and Acl that has a list of 5 things that I believe make it very difficult for most people, when trying to get their first Acl experience. So in order to prevent other people from going through the same issues I thought it would be appropriate to send out a little notice to the group. The article can be found over at: http://www.thinkingphp.org --Felix Geisendörfer aka the_undefined --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: #5 Reasons that make Acl difficult
Hi John, well you are right, this article is not directly a how to work with acl-kind-of-article.*But*, I do think that some of the stuff covered in there can help people that are stuck at one or another point when dealing with Acl. The problem about Acl and support through Irc / the List is, that Acl problems are sometimes long, complex and difficult to explain. For that reason I have choosen to write a blog entry summing up the ones I had and to explain how I approached them. Now, John Zimmermann asked why I don't update the wiki. The reasons for that are simple: I think the wiki is full of old and incorrect information and determined to be removed soon. So meanwhile I don't think I'm good enough with Acl yet to contribute to the official documentation and I needed a place to share my current state of enlightenment *g*. Let me comment on your comments real quick: Example 1: I think one can figure out that the Acl classes are Models by himself, but I figured that no explanation would be needed if we would use them like such. Just some request for KISS. Example 2: I think complaining about the Wiki is valid as long as official documentation is rare. But in general I agree. But when it comes to user_id I disagree. It is the only other way besides the alias to identify Aro elements (If I'm not completly wrong), therefor those id's have to be unique, and should not correspond to the ones of foreign models because if you use multiple models they could overlap! Example 3: Well I guess I needed material to make a point ...? ; ) Reason #3: I hear what you are saying and I agree. But, how do I work it out for multiple models? All the Acl functions right now don't take model as a param making it only useful when working with 1 Model. Reason #4: Why do we organize things in a tree? Because it's a logical hierarchy that's easy to under- stand for others. So we also want to show those Aco Aro trees in our app, and in order to that, we need to work with MPTT, or did I miss some existing functions for that? Is there a core function for retrieving an mptt tree as an nested array? Reason #5: As I said, this little writing was about why I (and probably others) struggle with their first Acl implementation. I think it's useful by showing wrong path's from a users perspective and showing a couple ways to omit them. And like I said in my last lines, I intend to publish 2-3 articles that are actually going to show how to use acl and not the opposite ; ). Maybe we can organize it so I write some of it directly for the cakephp manual and take out some of the spicy stuff for the weblog. How does that sound? And before I forget: Thanks for reading this huge piece of Acl complaints, I appreciate that ; ). --Felix aka the_undefined John David Anderson wrote: Since most of the article directly references stuff I've worked on, let me comment a bit: First and foremost, I want to come out and say, that the wiki is *not* official documentation. Its a wiki. Its days are numbered, and will personally burn an effigy of the wiki when it meets its maker in the coming weeks/months. Use it at your own risk, people. Example 1 The manual explains that dbACL is made up of a set of core models. These models are used by Cake... etc. Its all in section three. Do a search in the manual for model in that chapter, and you'll see that it's everywhere. Point taken about the uses(), though. Maybe I assumed that people would know if you want to use a model that's not a controller's model, you need to use uses(), but I can see how that would be hard to come by for newcomers. Example 2 Yeah, the wiki is wrong. It seems a little funny for someone to complain about the verity of a wiki page because for one, they have full power to change it. The user_id/link_id field allows you to hitch your ACL objects to real models. Its not for unique identification of the actual node itself. I'm not even sure what the rant is here, but I think you've missed the point of the user_id field. Example 3 Yet another bad wiki example. Seeing a pattern with the wiki? Why are you still referring to it? Reason #3 Um, the user_id isn't supposed to auto_increment because it is used as a link to another table. Its a normal foreign key to another model in your app. Same goes with object_id. ACL is a structure that sits completely separate from your other data. By leaving those fields in, you can tie a given ACO/ARO to an actual model in your application. I think most of the frustration you've encountered is because of a misunderstanding about how the system works. Maybe I haven't explained it well enough. : / Reason #4 Why should you care how the data is stored and retrieved, as long as it is working well? This is a framework after all, and part of the advantage is you don't have to know the ins and outs of the guts in order to make magic with it. You don't have to know *anything* about MPTT to use ACL like a pro. Reason
Re: #5 Reasons that make Acl difficult
On May 31, 2006, at 1:16 PM, the_undefined wrote: Hi John, well you are right, this article is not directly a how to work with acl-kind-of-article.*But*, I do think that some of the stuff covered in there can help people that are stuck at one or another point when dealing with Acl. The problem about Acl and support through Irc / the List is, that Acl problems are sometimes long, complex and difficult to explain. For that reason I have choosen to write a blog entry summing up the ones I had and to explain how I approached them. I can see that. It suppose it can work as some initial notes to help me see where people aren't getting things... snip Example 1: I think one can figure out that the Acl classes are Models by himself, but I figured that no explanation would be needed if we would use them like such. Just some request for KISS. Maybe I can try to make the usage cases more clear. Example 2: I think complaining about the Wiki is valid as long as official documentation is rare. But in general I agree. Complaining about the wiki is no longer valid: you've all been warned! ;) But when it comes to user_id I disagree. It is the only other way besides the alias to identify Aro elements (If I'm not completly wrong), therefor those id's have to be unique, and should not correspond to the ones of foreign models because if you use multiple models they could overlap! AR/CO's both have unique identifiers that are auto incremented. Look at the table structure, and you'll see it. You need to look at the user/object_id as a foreign key. The alias is just there for convenience, so that when your structuring your ACLs, you don't just have to stare at numbers. Example 3: Well I guess I needed material to make a point ...? ; ) Sensationalist! ;) For real, though, please don't rely on the wiki. Its bad mojo. Reason #3: I hear what you are saying and I agree. But, how do I work it out for multiple models? All the Acl functions right now don't take model as a param making it only useful when working with 1 Model. Not sure what you're asking here: sorry. Reason #4: Why do we organize things in a tree? Because it's a logical hierarchy that's easy to under- stand for others. So we also want to show those Aco Aro trees in our app, and in order to that, we need to work with MPTT, or did I miss some existing functions for that? Is there a core function for retrieving an mptt tree as an nested array? /cake/libs/controller/components/dbacl/models/aclnode.php Its the parent class for both AROs and ACOs. Its a good place to start, at least. Reason #5: As I said, this little writing was about why I (and probably others) struggle with their first Acl implementation. I think it's useful by showing wrong path's from a users perspective and showing a couple ways to omit them. And like I said in my last lines, I intend to publish 2-3 articles that are actually going to show how to use acl and not the opposite ; ). I'd like to see that in the Bakery. Maybe we can organize it so I write some of it directly for the cakephp manual and take out some of the spicy stuff for the weblog. How does that sound? Sounds good to me. Any help is always appreciated. And before I forget: Thanks for reading this huge piece of Acl complaints, I appreciate that ; ). Thanks for a level headed response. My initial message was written in a bit of a bad mood, so the appreciation is likewise. -- John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cake PHP group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
