There are certain things I feel should be presented in a database called Settings. Things like Theme would be stored here so the game knows which to choose, GameTitle, Even modules could take advantage of a standardize settings db, or just go with their own. I remember mentioning it before that what I like is a standard such as:
sid (AutoIncrement) | pid (parent SID) | name | title | description | optioncode | value | disporder | isdefault (1 or 0)
-Settings Groups pid are 0
-Optionscode is text that'll contain : yesno, onoff, text, "select 0=Value1 1=Value2 2=Value3", "radio 0=Value1 1=Value2"
-Value is text that'll hold the string that'll go with the optionscode above.
-Disporder is the display order on how groups are ordered, and how subsettings are listed in the groups
The admin panels Settings module can then be created to automatically produce Settings pages for everything that supports this db structure. By parsing the optionscode we can choose the correct html input to use, and which to populate it.
Anyone that doesn't want to use this db structure will still have the option to use the Menu class to add their own custom page to the Admin panel incase there's extra things they want to do.
This standard setup frees module developers from HAVING to create admin pages for their modules. Instead they'll just have to simply add the Settings with Optioncode to our table and they're good to go. IF they want more admin options, like a table to show a custom members list or something like that, then we'll have a menu class and the module/view system in place for them to hook into also.
Vote is on having A structure.
Up for discussion is how it should be structured. Tonight/Tomorrow I'll produce a PoC to go with both a SettingsTable (this one) and the Admin panel.
There are certain things I feel should be presented in a database called Settings. Things like Theme would be stored here so the game knows which to choose, GameTitle, Even modules could take advantage of a standardize settings db, or just go with their own. I remember mentioning it before that what I like is a standard such as:
sid (AutoIncrement) | pid (parent SID) | name | title | description | optioncode | value | disporder | isdefault (1 or 0)
-Settings Groups pid are 0 -Optionscode is text that'll contain : yesno, onoff, text, "select 0=Value1 1=Value2 2=Value3", "radio 0=Value1 1=Value2" -Value is text that'll hold the string that'll go with the optionscode above. -Disporder is the display order on how groups are ordered, and how subsettings are listed in the groups
The admin panels Settings module can then be created to automatically produce Settings pages for everything that supports this db structure. By parsing the optionscode we can choose the correct html input to use, and which to populate it.
Anyone that doesn't want to use this db structure will still have the option to use the Menu class to add their own custom page to the Admin panel incase there's extra things they want to do.
This standard setup frees module developers from HAVING to create admin pages for their modules. Instead they'll just have to simply add the Settings with Optioncode to our table and they're good to go. IF they want more admin options, like a table to show a custom members list or something like that, then we'll have a menu class and the module/view system in place for them to hook into also.
Vote is on having A structure.
Up for discussion is how it should be structured. Tonight/Tomorrow I'll produce a PoC to go with both a SettingsTable (this one) and the Admin panel.