> Hal wrote: > > Where Lee and I disagree is that Lee doesn't see any > distinction between isArticleReader and the set of > permissions, hasReadArticlePermission and > hasSearchArticlePermission. In Lee's model, there are > no such things as independent permissions. Lest I > misrepresent it, here are Lee's words: > "What's a Permission? Show me one? It's a very abstract > little beastie. Too abstract for me."
Okay, that makes sense. I think everyone is saying the same thing, with the one exception that you noted above. Actually, I think I may prefer Lee's solution. :) Permissions are hard-coded into the application. We can add new permissions to the database easily, but they don't mean anything unless there's an if statement guarding some functionality within the app. If you want to do it right, you would not only guard the functionality, but hide the option to use that function, so that users aren't lead to dead ends and access denied messages. In essense, it's very expensive to change a permission. A role, on the other hand, is very inexpensive to change, because it isn't embedded in the application code. But in my experience, there tend to be no more than three or four roles for a given application at any one time. Also, after the application is built a change in a role is usually coupled with the addition of a new permission. Most of the people who use my applications are okay with the idea of assigning people to groups, and assigning roles to groups/people, but don't understand or care to understand the difference between a role and a permission. What I'm getting at is the distinction between roles and and permissions, while technically elegant, isn't saving me much work. When a role changes I always have to get involved, and as often as not I also have to write code. Lately I've been creating a new interface for each role. That way, when a role changes I only have to worry about changing the interface for that role. I don't have to worry about messing with permissions and if statements. An added benefit is that I can design each interface with a single role in mind, making it more useable. Sometimes one or more roles can do the same thing (permission) and in this case I have some redundant code, but I'd rather have a little redundant code than a lot of extra conditional code. Also, next month at the annual PHP Down Under conference in Pig's Dribble, I'll be revealing a way that there doesn't need to be much redundnant code at all. Patrick ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
