Daniel McBrearty wrote:
The usual way to make things like this work is by having a
standardised api. In the case of membership for a website, it might
look something like:
get_unique_user_id # of logged in user
get_username_for_id( id )
Then if a forum has tables such as:
thread -> references username
post -> ditto
and maybe methods like
send_pm( user )
find_posts( user )
if you are prepared to sacrifice the actual foreign key relationship,
not that big a thing IMHO, you can do it all through the API. The
person that writes the forum code/schema can actually have two install
options - with and without the user table.
Cat almost has this in place at present.
Seems to me the easiest way would be to have the forum module have it's
own user table, keyed by the same user id as the core user table. Then
it can store whatever it wants in there, like signatures, posting
preferences or whatever. The core user table/object could have a few
well-known attributes like real name, email address and so on, but not
much else.
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
