[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqwebmail
Subject:    Re: [sqwebmail] Proposal to make the SqWebMail highly user configurable and extensible
From:       Brian Candler <B.Candler () pobox ! com>
Date:       2003-10-27 16:24:30
[Download RAW message or body]

On Mon, Oct 27, 2003 at 08:00:57AM -0800, Sagara Wijetunga wrote:
> Thanks Brian and James for your comments. I think you
> both missed the point I?m trying to convey. Let?s take
> an example.

OK, well I think you are saying that the single tag [#L#] expands into a lot
of HTML - indeed it does - and you want to be able to modify parts of it
without modifying the C source. Well, that's essentially my point (3), but
it's a lot of work. You give examples in Perl, but sqwebmail isn't written
in Perl.

Designing a *good* templating engine is not straightforward, and nor is
rewriting sqwebmail to use it.

> James is going to rewrite templates with CSS. If large
> number of CSS tags are inside the C code, does he has
> the freedom to change, add or drop these CSS tags
> without changing the C programs?

That's the whole point of CSS. You write it once, and tag everything once.
You can then write as many different matching stylesheets as you like.

> What if an user want to drop the radio button? Can
> they do with CSS? :)

Probably not. But you do have an extraordinary level of control over the
format and appearance of the output. If you've not seen it, go to
http://www.csszengarden.com/
and try selecting different stylesheets. Each page has a hugely different
feel and layout, but they all use *exactly* the same source HTML.

Dropping a radio button is generally a dangerous thing to do, since the CGI
will be expecting that input. You could replace it with a hidden constant
field to fake up the value, but then you've lost functionality. You can't
just create a new page and move the function there; the logic of which pages
contain which buttons and what they do *is* hard-coded into the C code, and
I don't see how your templating system would let you create entire new pages
and bind them to functions.

So, really, the only safe thing you can do is to keep all the existing
controls and just alter the layout - and CSS lets you do that.

Another problem with letting people meddle with templates, is that you are
very likely to break compatibility with future versions of sqwebmail when
they are released (e.g. the new version of sqwebmail has an extra page or an
extra control on a page; it simply will not work with old templates). For
that reason, I don't allow users to change templates at all. They can upload
a new stylesheet, and they can upload replacement gifs, but that's all.

Now of course, if you're not a large ISP, and you're just modifying
sqwebmail's look for your own use, then you can modify sqwebmail's templates
every time a new version comes out. But then equally you could modify the C
source every time a new version comes out.

> What if an user want different icons for Inbox,
> Drafts, Sent and Trash? 

You can do that now; you just replace the .gifs

> What if an user want different color for a hard coded
> element like above?

Colours of gifs are stored within the gifs, so you replace them. All other
colours will be in the CSS.

> See according to the method I proposed, users do have
> the full freedom to decide the presentation, change
> the HTML, add or drop CSS tags, etc. The SqWebMail
> does not even have to be aware what language the
> template is written (eg. HTML, XML, etc)!

Sure, you could rip out all of sqwebmail's HTML generation and replace it
with a templating engine, but it's hard, and for the reasons given above, I
don't think the benefits are as great as you imagine.

Brian.

[prev in list] [next in list] [prev in thread] [next in thread]