Class Structure/layout

for user to user permissions

[Tommybs]

Hi all,

Wondering if I could get the input of some fellow coders. I'm looking at setting something up that will allow users varying privacy settings ( think facebook, friends only etc.) and I wanted to ask a question about structure.

Say I have a class Blog that has a users blog entries, and another class of User ( the logged in user). Where would you suggest putting the userCanView style function? Should it sit in Blog or should it sit in User? Or should it sit in a class on it's own? Say I wanted to then have a gallery class, a separate class for privacy would then become beneficial. But then how do I structure the queries?e.g. would privacy then be a separate db table such as

user
entity_type // E.g Gallery or Blog
privacy_type

and then another table that maps users to users?

Would appreciate people's opinions on this?

[Little_G]

Hi,

I suppose it's a matter of personal preference, but if I understand what you've described I'm thinking of something like this.

Page 
+Blog 
+Gallery 
User 

The Blog and Gallery classes extend the abstract class or interface Page (or whatever you want to call it). Page defines methods for displaying itself, etc. It also defines a method or methods for checking user permissions (which can be passed an instance of User). This method can then be implemented by the Blog and Gallery classes to perform the operation in a way that is specific to them.

As for the database there are, as ever, multiple ways of structuring it, a generic table:

permissions 
user_id | property | value 
1 | "blog.viewPostDate" | true

Or, page specific tables:

blog_perms 
user_id | canViewBody | canViewPostDate | canViewAuthor 
1 | true | false | false

And I'm sure a hundred other ways.

Andrew

[Tommybs]

Hi,

Thanks, it's weird, I've been using interfaces and abstract classes a lot more in my code lately, and despite being presented with an ideal situation to use them I failed to notice it. Guess it's back to hitting the books for a bit.

What I did come up with ( which is similar to page) is Entity. I was going to have a number of Entity types which would be defined as constants. I was then going to use an entity_type_id column on the DB to work out what type of entity it was and using another id then use a join to work out permissions. In essence doing it all on the database. Though looking at it this would probably make it more tightly coupled in the long run. I think I'll try out your idea of a "Page" class with an abstract check security method

Thanks again