Brian Candler writes:
> 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.
I agree with the proposal that this would generally be a good thing.
> Designing a *good* templating engine is not straightforward, and nor is
> rewriting sqwebmail to use it.
Indeed. A good templating engine has some way of specifying loops,
for starters. So it would be a lot of work. Maybe worth the effort,
maybe not.
> 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.
You can change a lot with CSS, but not everything, and what you can
change is limited to the foresight used in adding classes. For
instance, if you want to increase the cell padding around <td> elements
you can, provided that the HTML has an appropriate class that affects
only those <td> elements you want to affect and no others on the page.
But what you cannot do with CSS is alter the column order in a table.
IIRC, earlier versions of sqwebmail did not make every field in the
message list a link to the message and it was only after a code rewrite
that this happened. But with a ${link_to_message} tag you could decide
if only the subject, or only the from address, or both are links to
the message just by changing the HTML.
> Dropping a radio button is generally a dangerous thing to do, since
> the CGI will be expecting that input.
Actually, the most commnly-displayed buttons in sqwebmail are checkboxes
and if none are selected then the browser should not send anything
containing the names of those checkboxes. And although the HTML specs
have always stated that a browser should not allow all radio buttons in a
group to be deselected, most browsers let you do just that and some
CGIs require the capability to deselect all radio buttons for full
functionality (I'm thinking of one particular message board CGI which
has a radio button to select a smiley to place against the subject -
use lynx and you cannot post a message without a smiley). So if the
CGI is expecting one radio button to be selected it is in for a lot of
disappointment - it might be correct according to the specs but "be strict
in what you send, be tolerant about what you receive."
> You could replace it with a hidden constant field to fake up the value,
> but then you've lost functionality.
The whole point is that he might WANT to lose the functionality. Ummm,
like where company policy is that no mail must EVER be deleted. Hint:
I wonder how many times the delete button was clicked in the White House
between Ashcroft saying there would be an investigation into the Plame
affair and sending the White House staff a "do not delete/destroy
relevant documents" message a couple of days later. Sometimes, in
ethical organizations, there is a need to enforce a strict audit trail
on everything to ensure that staff do not cover up their misdeeds. Yeah,
you can copy every incoming message and every outgoing message, but then
you have to sort through a lot more messages than if you can just look
in somebody's inbox and sent folders.
> I don't see how your templating system would let you create entire new
> pages and bind them to functions.
It could, although I can't see much need for it and a lot of the time
the functions would have to return a "you can't do that here" message
where the function didn't make sense in the overall context. Lots of
additional sanity-checking involved even though putting the hooks in
to allow any function on any page would be relatively simple (although
inefficient).
> 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.
Not fully, it doesn't. What if you want to duplicate the controls at
the top of a folder listing at the bottom and vice versa? I frequently
find I've scrolled down to the bottom of the page to look for a message
and find it's not on that page so have to go to the next one - and the
only way to do that is to scroll back to the top because that is where
the "next page" button is. Far better if those controls were at both
top and bottom of the page. Quite frequently a new message comes in
and I want to move it to another folder so I have to scroll down to
get to the move controls. I could make life easier by not having
50 messages per page or not sorting the messages so the newest comes
first, but that would make life a lot harder for me in other ways.
Offhand, I don't even know if I can duplicate those controls by modifying
the HTML alone or if I have to twiddle the C too. The point is that there
are changes that people want to make that cannot be done in CSS alone,
and the more the HTML is decoupled from the C the better.
> 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;
Absolutely. But who said it was going to be the users messing with it?
Some ISPs have graphics people who want to customize things for general
use across the board and are prepared to have to possibly rework that
customization when they upgrade. To be honest, most of our users probably
shouldn't be let near CSS either, because they'll only end up with white
text on a white background and expect us to sort it out for them for free.
Even the time taken to look at the problem and spot that it's their fault
and tell them so is more than I would want to spend given how stupid some
of our customers are.
> But then equally you could modify the C source every time a new
> version comes out.
Yes, you could, but the more HTML that is entwined in the source the
harder it is to do. It requires the graphics designer capturing
the source to the page, modifying it, then a software engineer comparing
the differences and finding whether those bits are in the HTML or the
source (and often such changes span both). It is far from easy, which
is one of the reasons that templates for other languages are so rare and
the few which exist are so out of date.
> 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.
It would be a lot of work to do. I don't think the benefits are as great
as he imagines but I don't think they're as small as you imagine. Whether
or not any of us think it is or is not worth the effort, only one person's
opinion is going to count - Mr Sam's. But if he has as much difficulty
as the rest of us do in introducing changes that span both HTML and code,
perhaps it might be to his long-term benefit too.
--
Paul Allen
Softflare Support
