[SM-DEVEL] Re: User Interface -- Templating (RFC)

[Erin S. <ebu...@sq...>]

Juan (and the development team as FYI/RFC) -

Started replying yesterday, then was interrupted...

Juan van den Anker said:
> Hi Erin,
>
> Yesterday i've spoken to Marc regarding the SquirrelMail UI.
> I've been part of the SM development team some time ago but
> haven't had the time to code as much as I wanted to...

Marc did let me know to expect your email, and gave me a rough outline of
what you'd talked about before.

> Never the less, I've monitored SM development and I would
> like to continue developing SM, especially developing a
> template system (smarty, whatever).

It is certainly on the plate, and is a priority - unfortunately, we have =
a
preponderance of priority items at the moment... ;)

> If you want I can start investigating a suitable templating
> system or if that step is already taken; would like to join the
> team and start coding templates... In my opinion, SM should
> start using templates *soon*. I think a respectable mail client,
> such as SM, should be able to use templates. Others do this
> already...

Soon is definitely agreed.

This is my view on templates - I don't want to create a dependency on any
particular templating system. Many users have a lot of trouble installing
SM as it is, and I'm reluctant to place another requirement (much less on=
e
for an externally maintained templating engine) on them.

Some users will want a templating engine, others will not. What I want to
do is separate out the UI, and provide a base set of our own homegrown
templates, with the option in place to plugin in a templating engine if
you want.

I also don't want to have to maintain templates for compatibility with
evolving versions of an external engine.

> Besides templating; I think I can be usefull at creating CSS
> files based on current code. Maybe this step can be taken
> rather easily before actually starting a (more time consuming)
> template system.

There are a lot of requests for using CSS in 1.4.x, i.e. modify the
colors, etc. that we have now into appropriate styles, make named div's
for things like the menubar, etc. It's lots of little tweaks all over the
place.

I've been holding people off of this, as it's sort of a waste, but I'm
looking at the longevity of 1.2.x, and I'm beginning to rethink that.
Since Mark and I are also on the verge of making the everything
unworkable, I've had the following thoughts:

1) Let's keep the 1.5 stream as it is now (meaning, we try the more
complicated fixes on 1.5, and then roll them back on 1.4 - corification o=
f
delete-move-next, adjustment of hooks, etc. can all happen in 1.5, and
then move back to 1.4 when it's been tested). CSS changes should go here,
to try to make the existing look/feel more easily modifiable, this can
then be backported when it's all ready without impacting the release of
new stable versions containing bugfixes, etc.

2) Earth shattering changes (new config system, beginning of templates,
bringing in Marc's new IMAP/Message classes, etc.) should go in the sm2
module in CVS, which I will clean out so that we can start with whatever
we want to bring over from the squirrelmail module. New work with
templating would go here.

Maybe this means that what Marc and I have planned (the new classes, etc)
will actually be 2.0 whenever it gets released - but I think this allows
us to keep stable stable, while allowing us to bring in bigger more
complicated fixes into the stream in a safe way (by using 1.5 first). And
that way Marc and I can break the world with our restructuring without
putting a total halt to intermediate items that count as development in
the meanwhile...

So, Juan - if you want to help with the design/implementation of
templating, I welcome the assistance. There are others on the dev list
that I think would also want to help with template development, including
Chris Hilts, one of our developers with CVS access.

What I'd like to see is the following:
   A comparison of how SMARTY, patTemplate, the template engine in PEAR
interact with an application.
   Some sample Smarty/PHP/PEAR templates for comparison, evaluation,
discussion purposes.
   Some discussion on how an environment/application is best maintained
with regard to templates.

I've certainly chewed on this quite a bit, and have had discussions with
others about it, but I know I haven't the only opinion in the matter.

My concern is what SquirrelMail would have to maintain internally, and
what burden would be placed on the wide range of users that we have. The
home-simple-system user does not need the burden of extensive templating =
-
CSS style sheets with some straightforward, modifiable php modules that
render the page would be more than sufficient.  For those seeking to
integrate SquirrelMail into a more complex environment that uses a
particular templating engine, care would have to be taken to ensure that
everything we need for our environment is in place to function as expecte=
d.

This does tie in with the configuration item, as well. If we move the
initialization of SquirrelMail, and the invocation of methods to retrieve
mail information into an encompassing class, then perhaps integration wit=
h
templates (if desired) becomes a non-issue, and what we ship with SM is a
set of php modules that provide a default set of pages that interact with
this class (which is becoming my favorite idea so far).

However, this will require quite a bit of design, especially considering
the function of plugins and whether or not they provide directly callable
services (think Mail fetch plugin and the menu line, or the calendar, or
the addressbook) - how are those "extra" services managed?

I have some ideas for this, I've certainly been chewing on it long enough=
.

In any case, I'm opening the floor again - open request for comments, all
are welcome.

Erin
(ebullient)

--
'Waste of a good apple.' - Samwise Gamgee
ICQ: 38670353