1) Create a preference/config system where we group settings per module in associative arrays (easy to extend) and add support for access control list. A squirrelmail admin should be able to do the following actions per setting: * make settings visible or hide them * set default values * override user settings * permissions on settings with acl support
I'm feeling like it would be *much* easier to visually parse this code if we shove it into a set of classes and *not* into a bunch of (nested) associative arrays. That would make it as (if not more) extensible, and would make us organize it a lot better. I agree that user prefs should use the same code as system config settings. Not that the array idea won't work, but just another way to think about it.
Internally we need to tune our config system and see how we can combine current config widgets with templates. I didn't make up my mind yet about how to deal with that. I only know we should autocreate configpages just as we do now so leaving it all to a template is probably not an option.
So you want to pass HTML to a template? I'm not sure that'll go over too well unless the HTML is very limited. I agree that it seems like we have a good thing going right now with our auto-generated config pages, but am wondering if the extent to which that auto generation should happen in a templating context is to merely generate a list of needed widgets (and their attributes), which the template then has the responsibility to build.
Probably introducing template widgets for each kind of option (boolean, optionlist, dropdownlist, groupbox, whatever) and a config template wich includes the widget templates is an option but hey i'm not a template specialist.
Huh, yah, that seems neat. In my template experience (and I'm no expert either), I've seen this kind of thing work fine. I would stop short, however, of then presuming we can paste those things together and spit them out as is, since surely some template developers will want to reorg the actual placement of the resulting widgets.
In the end, though, I'm not sure this is necessary: why not just pass a list of widget names/types/values/etc to the template and let the template do all the hard work? The template can do its own inclusion of widget templates if it wants to, in nearly the same way you are proposing, but what is better is that this keeps the presentation code in the presentation layer and the core only has to call one template and not paste a bunch together or other such...
2) finish a template class 3) create templates for the mailbox option page 4) create templates for all other regrouped option pages 5) ...
6) figure out how we can make plugins work with templates. bleargh.
A lot of work !!!
you said it
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- squirrelmail-users mailing list Posting Guidelines: http://squirrelmail.org/wiki/wiki.php?MailingListPostingGuidelines List Address: squirrelmail-users@lists.sourceforge.net List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
