Re: [Phpwebsite-developers] Storing user level options for modules

[Jason C. <cam...@xp...>]

I would think the table naming should sort of be consistent so you can tell 
which tables are for modules.  Like say for the calendar it would be 
mod_calendar_user_options or just mod_calendar_opts or something like 
that.  I think thats what we have right now in place for modules.  At least 
the new calendar module and a few others I've been working with do it that 
way right now, which, to me seems like a good naming convention.

What we dicussed earlier, we were thinking about either having one table to 
have the security info for all the modules or 1 for each module.  Not sure 
which would be best right now.  I've been thinking about the modules in 
general terms.  IF each module would have a security table, it would have 
to be named like the module tables of course, say mod_calendar_admin or 
something like that and the table structure could be something like below 
to some degree.

table: mod_calendar_admin
user_id REFERENCES users.user_id (foreign key to core users table)
seclevel INTEGER
something something something else....


Some of this would depend on how involved the module actually is.  Like the 
calendar would be a major module in the overall portal and might have 
different admin features or just one global one, based on whatever the 
module writer sees fit....

-- 
Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com
phpWebSite Developer


> As I posted to the website tonight I just thought about something we
> need decide.  How will user level module options be stored?  I'm
> thinking of a module level table as follows (assuming calendar module):
> 
> table: calendar_user_options
> user_id REFERENCES users.user_id (foreign key to core users table)
> option INTEGER or TEXT (as decided by the module designer)
> 
> --Todd
> 
>