On May 7, 2006, at 9:19 PM, tom wrote:
> > My problem is that I see ACL as a somewhat useful solution, but that > it's so abstract that it needs some kind of wrapper so that ACOs > can be > used as users (especially because it seems like there is absolutely no > other way that they could be used). This is actually by design. Rather than trying to store all your user information in the ACO table, you can use an ID to link it to actual user data. There's a bajillion ways people want to store their users, and by allowing people to link to them, you're able to get the best of both worlds. The other reason is that ACOs are *not* always users in the system. An ACO might be an outside web service, a controller, a controller action. Its meant to be super flexible and powerful. As such, it takes a bit to get going. If you think a simple session and beforeFilter deal works for you, I'd go for it. ACL is not meant for super simple, its meant for granular access and better role management. If you're not even using roles, I don't think I'd be using ACL at all. > Otherwise, it seems like the way to > use ACLs for authenticated users seems difficult enough that people > just homebrew something or other. Again, I'm pretty sure that's what it was designed for. I'm personally against Cake having a complete auth/persistence layer, because I think it changes so much from app to app. The places are available for people to hook things they like in, and by omitting a feature like this, the codebase stays lean and simple. -- 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 -~----------~----~----~----~------~----~------~--~---
