For example, from a gaming perspective, a guild or a clan can have have members on many servers within the same game and RosterMaster will accommodate this with different Rosters, and character to user associations, for each of those servers. Not only that, but the same guild or clan can also have different rosters for the different servers of the different games they play.
You will also be able to create rosters from either single user groups, or groups of user groups, as well as rosters of the entire user base (for controlled sites). If all works as I would like it to, you will be able to have a roster of user groups that acts like (using the above gaming environment example) another roster of that particular guild.
As should be obvious by now, roster objects will not be limited to any one 'Guild' as the last RosterMaster was and one can build many different roster objects based on many different roster needs.
The current architecture (NOT final) looks like this (I won't claim this is the best setup, but it works with my current aspirations):
ObjectTable MemberTable User(assoc.)Table
ObjectID(prime) ---------- ObectjID(idx) rmUID(prime)
ObjClass MemberID(prime) --------- MemberID(idx)
Name Name pnUserID
etc... etc. etc.
The ObjClass field of the Object Table is a suffix for the module object class called. In the case of Everquest II I used 'EQ2' as the value and named my classes PNRosterMasterEQII and PNRosterMasterEQIIArray calling them with a combination of DBUtil::selectFieldByID([ObjectClass by ObjID) and Loader::loadClasFromModule() with a derived php string as the 'base_obj_type'.
Along with this is a vars table with API functions that work identical to PostNukes' pMod[Get|Set|Del]Var() but requires an ObjID instead of modname so that different sets of vars can be associated to each roster object.
The logging functionality will also be ObjID oriented, and as such care must be taken when setting up logging as to avoid unnecessarily bloated log tables. Accordingly all loging will be set by default to 'off' except in the case of an upgrade from RosterMaster(PostNuke)0.96.
RosterMasters current status is a working upgrade script along with all the functionality of the 'main' RosterMaster display (although the func is now display (ya I'm learning)) for Everquest II. This includes table header reverse sort as well as advanced sort allowing two fields to be sorted in individual directions. The rest is forms and options. Once the EQII class is fully functional I'll begin to set up the other classes and refine the API.
My vision here is to have RosterMaster act as an extensible roster module suitable to organizing and maintaining roster and roster member profiles in association with, or indifferent to, the user base with consideration of user groups.
TaskMaster has the same goals but with reference to levels of accomplished tasks,
All of this has been made possible via PostNukes' 'adambaum' pre-release... this module will not work with anything prior and WILL BE COMPLETELY UNSOPPORTED until the adambaum release (other than beta testing).
Once the EQII class has been made fully functional I'll commit the project to the current PostNuke NOC project SVN for beta testing.
RosterMaster(PostNuke)0.97 and TaskMaster(PostNuke)x.xx naming policy will be dependent on the official release name of the adambaum release.