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