> Marc Groot Koerkamp wrote:
>>>> 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
>>> 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.
>> I'm not sure what you have in mind with shove it into a bunch of
>> classes. I was refering at the internal format, after parsing the files
>> which contain the preference definition (in whatever format we decide
> Create classes that encapsulate a preference setting, and when the
> config file and/or user prefs are parsed, each setting gets inserted into
> its own object. This would be an alternative to keeping everything in an
> array and may be more extensible as we decide to change the format of
> stored data or what kind of extra attributes we may want to store with
> each setting. Of course, as you know, it also keeps the methods that work
> on the data in one place...
Right. a couple of things:
1) Associative multidimensional arrays are extensible and theirfor have
room for extra attributes
2) Because we cache the preferences in the session, keeping prefs in
objects requires loading the classes before we load the session (but
that's no big deal)
3) I'm still talking about internals. Storage of settings is something
completely different. We should put storage related action in extendable
persistor class objects so we are able to call the write/read methods from
the persistor class and the backend of the persistor class deals with the
read/write implementation for the specific backend (ldap,file,db). The
config system on it's own should not need to worry about how stuff
lowlevel is written to or read from the backend. This also means that from
the config system point of view it doesn't matter if the data is stored as
xml, serialised data or some binary form.
However, I also want the preference definition files externally which is
something different then the actual per user or per sm install stored
prefs. The preference definition files contains info, as mentioned before,
about a short and long description, default values, permissions, acl's etc
etc. It's only used for the config system so that part should probably
be parsed in some config system class method. Initially it's read only and
the definition files can be edited manually to change the behaviour of the
specific config var. In the future we could create an interface so that
admins can completely tune the behaviour of sm by disabling prefs, fixing
prefs etc etc. Something to keep in mind when we start designing.
4) No matter if we use objects or arrays, we should choose for a sollution
which is generic and is useable for all kind of preferences. We should not
stimulate a wild grow of special pref definitions which require their own
specific methods. I rather see a fit to all pref definition because I
think it's easier to use.
>> Parsing stuff can be of course be done in classes. The rest of the code
>> can also be put in classes but using classes as storage container for
>> information is something I think about a bit different now then in the
> Meaning...? Granted, using classes as a storage mechanism can take more
> overhead, but that's generally the tradeoff that comes with the somewhat
> higher-level concept of classes. If you are saying it's overkill, I'm not
> sure I disagree with you; but I am thinking that the class approach allows
> us to make changes in the future w/out having to rewrite more of the
> array-based code and create any backward incompatibilities. It also makes
> things a little easier to understand IMHO (which a lot of SM is not).
I'm not saying it's overkill. The only overkill in squirrelmail we have to
deal with is imap communication and not so smart time consuming alogithm.
>> If you can use associative arrays instead then i go for the array
>> approach. A class is only usefull if you also have methods which only
>> apply for the information stored in the related class object. But then
>> again, if for each specific type of var we need different function to
>> handle them then using a base class and extending it for each type is a
>> nice approach.
> I didn't envision too many different child classes; I was mostly
> thinking about the base class, which would hold all the generic methods
> that parse, load, save, determine acl, visibility, and anything else for
> any one setting.
Agreed, except the parse, load, save and acl. Parsing is a separate task
which is done a lot in many places in squirrelmail and theirfor it's
better to try to implement some abstract reuseable parsing class. Load and
save, see the persistor class example (also reuseable). Regarding acl, I
already have a abstract acl class which i want to use in a tree class
where i can store message structures, mailboxtrees, threaded message list
(the key is reuseability).
Of course for the sake of speed it can be easier to embed a few things in
a class which at a later stage can be removed because the reuseable code I
talked about isn't very well tested or ready to rock.
>> Right now I see the configuration vars as an associative array with a
>> set of entries needed to generate the widgets. After our vision towards
>> the new system gets more shape we can decide what's the best way to
>> implement it and of course it should be an implementation which is ready
>> for the future and can be extended when we want to extend the
> I'm sure we can manage it either way. Just contemplating other
>>>> 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
>>>> 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...
>> Templates rock but they also have their limitations. The problem I see
>> is that as times go by there will be new configuration vars / groups and
>> there will disappear stuff. Template development will always lag
>> behind sm development and if we let the templates do handle the
>> placement of each var then i see problems.
> Absolutely! What I was suggesting was not hard-coding anything into the
> templates. It is entirely feasible to do exactly what you were proposing
> in the templates themselves: template code should be capable of looping
> thru a list of widgets and including the correct widget code from another
> file (if desired) depending on the widget type. This keeps things dynamic
> and keeps the gui code out of our hands.
Exactly what I had in mind.
>> Thats why we probably should force templates to handle what we provide.
> I don't think I agree. I don't see a good reason to force this; plus,
> if we can let the template do that work, not only does it make our life a
> bit easier, it lets the template authors retain maximum
> flexibility/autonomy (and we get less complaints).
I was refering at the looping stuff. What i wanted to prohibit is letting
a template directly access the configuration entries by key because the
number of array keys can grow or even change by name. On the other hand,
it shouldn't be difficult to fix the key names so that templates can
handle a few option group boxes different. As long as they process the
other entries as well no matter if the template is aware of it's existence
or not. (looping makes everything available)
>> should provide the individual settings in groups. The template should
>> display the groups in the order we provide because the template does
>> not have knowlege about the amount of groups we provide and the number
>> of vars in a group.
> There is no reason why a template can't run a loop over the list of
> groups and vars in each group that it is given and dynamically generate the
> corresponding display code.
>> We can provide extra information to a group like an "advange"
>> tag so the template can decide to hide those groups initially or place
>> them behind an individual tab (of course the template is free to stuff
>> each option group in a individual tab). A group should contain the
>> information like a short description, long description or even help
>> Now I come to your point 6 below. A plugin should be able to insert
>> option groups on the specific module it applies. Maybe it even should
>> have the possibility to insert plugin option vars in existing option
>> groups belonging to a module (a module is i.e. compose, the message list
>> or the message display (read_body) )
> yuh huh. :) in fact, plugins can do that now. my point 6 was not so
> much about config settings, which should be easy... it was more
> reminiscent of the last thread we had about that topic and how we can
> provide hooks for plugins that are functional only, visual only, or
> possibly both.
Visial plugins only work if we make use of css and define some common
class attribute names which the templates use. If the template supplies
it's own css sheet with the known class attribute entries then the layout
of a visual plugin which make use of the same class attributes looks good.
Of course the template should contain the hook for displaying the visual
plugin. (easy with php templates)
functional plugins ... probably it's easier to support a lot of functional
plugins related to imap and smtp in core.
I'm sure we need to brainstorm a lot more about the plugin problem and
Okey, enough for now, back to work.
>>>> 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
>> Many hands reduce the amount of work so lets work on brainstorming and
>> after that generate the specification so we can share the development
>> process with others ;)
> 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-devel mailing list Posting Guidelines:
> List Address: squirrelmail-devel@...
> List Archives:
> List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=7139
> List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel