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 #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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~----------~----~----~----~------~----~------~--~---
