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 [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 -~----------~----~----~----~------~----~------~--~---
