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.
