> If the tables have user.author_id and user.publisher_id, yeah.ok, but one of
these fields will always be empty/unused, since a
webuser
is either author or publisher. that's why i doubted it's the perfect
design...
> It mostly has to do with the way the keying of the tables are, and
> how you most often want the data.i need the user model only once to
authenticate a web user.
after authentication every action is checked against session data.
the personal data in author and publisher resp. are used by far more
often.
The associations you have in Cake are 'hasMany', 'hasOne' (which is
just a special case of 'hasMany') and 'belongsTo'. The semantic
definition is very clear -- a city has many roads ; a road belongs to a
city ; a train has many carriages ; a carriage belongs to a train.
The assocition you are looking for is 'is a special kind of' -- an
author is a special kind of user ; a publisher is a special kind of
user. Cake doesn't handle this by itself, so the implementation is up
to you. Here are some possible ways of doing this (this is by no means
an exaustive list!) :
1. You can use the Cake associations to do this. Have one table user
and one table author. The author table has a user_id field, and you
would set up 'author belongsTo user' and 'user hasOne author'. (Note
that we've lost the semantic meaning of belongsTo and hasOne here --
they don't mean anything in the way that the city/road example did). Do
the same for the publisher.
You'd need a way to know if a given user is an author or a publisher
(or both) -- either have a field in the user table that indicates this
property, or simply query the user model with it's associations and
check for the presence of a 'Author' entry in the array.
2. If you are using Cake 1.2, try using behaviours -- I've not used
them yet but as I understand them you could do something like this :
Decide on the fields that are necessary for a user (eg. username,
password). Then create three tables (simple_user, author, publisher)
that contain those fields (plus whatever other fields you need), and
write a User behaviour -- which deals with the 'User' side of things.
Then set each of the models to use this behaviour ; so they will all
act as users manipulating those common fields.
Behaviours aren't really documented yet - have a look here for an
example : http://bakery.cakephp.org/articles/view/198
Anselm
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
