[ANN] HTMLTemplate 1.0.0

[has]

Pete Prodoehl <pete.prodoehl at cygnusinteractive.com> wrote in message news:<mailman.524.1086209704.6949.python-list at python.org>...

> >>The nice thing about this is that once you learn the templating tags, it 
> >>doesn't matter what language you use, so you could change the backend 
> >>from Perl to Python and not even have to change any of your templates.
> > 
> > 
> > I've heard this said before, but am curious just how much of an
> > advantage it really is? I'd have thought reimplementing an entire
> > backend would be a much bigger task than porting templates and a
> > relatively rare occurence in practice; not sufficient in itself to
> > justify learning a second language in the first place. Anyone got any
> > practical experience in this and can comment?
> 
> Oh, you want *practical* experience eh? ;)

Yeah, I'm pesky that way... ;)

> I would think the "theory" is that you've got designers/authors working 
> on templates, who don't know code. They know HTML, and know CSS, but 
> they do not program or know any code. You give these people templates to 
> work on.

Absolutely no disagreements there. However, I suspect we disagree on
what actually constitutes "template". HTMLTemplate has a strict policy
of not directly exposing designers to ANY code whatsoever, not even
trivial presentation logic like data retrieval, insertion and
iteration. Designers are still welcome to dive into the controller
code if they want to, but they are not by default exposed to it.

This is very different to PHP-style philosophies where varying amounts
of presentation logic are inextricably bound into the HTML, and the
best that code-averse designers can do is use a WYSIWYG editor that
knows how to hide, or at least disguise, this code from them. And I
think there's a common, almost implicit assumption that, well, they
_are_ the template designer after all, so it kinda sorta could be
considered their responsibility; and besides, a little bit of
presentation logic never really hurt anyone anyway...

Unfortunately, I'm really the last person who could be convinced that
the PHP position is right, as I came from a fine art/design background
long before I learned HTML, and I learned HTML quite a bit before I
learned programming, so the total markup/logic separation of
HTMLTemplate-style systems is to me the original Holy Grail [1] I've
been wanting since year dot.


> You, being a top-notch developer, can implement a system in Perl, 
> Python, Ruby, PHP, etc, and as long as you stick to using the 
> HTML-Template system appropriate for each language, your 
> designers/authors never need to change their templates or learn Yet 
> Another Templating System.

Which is also _completely_true_ of HTMLTemplate [2]. (Aside from the
teensy nitpicky point that it isn't really available for any other
languages. *Yet*:) So I really can't accept this as an argument in
favour of PHP/ASP/Cheetah/html-tmpl/etc. type systems.

Now, if you can make a convincing argument as to why responsibility
for the Controller[3] layer should fall to the UI designer instead of
the application programmer then you have a case, though I've never
managed to make one myself while playing devil's advocate on my own
work so suspect you may have an uphill struggle on this one.<g>


> Another successful separation of logic from presentation... or so the 
> theory goes... ;)

Separation of _business_ logic, yes. Separation of _presentation_
logic, a big fat No.

Funnily enough, I don't mind business and presentation logic being
mixed half as much as I object to mixing presentation logic with
appearance.

For simple applications it makes a lot of sense to stick all the logic
together: it makes the code much simpler and quicker to write (and can
always be refactored into separate layers if the system expands later)
than going with some stiff-necked formal "architecture".

By comparison, one of my biggest turnoffs when perusing other
templating systems is discovering the proud declaration that "System X
ENFORCES separation of business logic and presentation" writ large
upon their policy statement. _Nothing's_ worse than software that
thinks it knows better than me how I should write my own damn program.
It's _my_ rope, after all, and any petty fascist lockstep-marching
program that tells me I can't hang myself on it any time I want to
will quickly find its own smug self being the one sent dangling
instead.

As a result, I've been quite careful designing HTMLTemplate to be as
non-fascistic as possible. So while it divides designers and
programmers across templating's primary natural faultline - that
between HTML markup and Python code - it doesn't dictate how each
party plays within their own domain. And users who like to wear both
hats (like me, for example), can easily hop from one side to the other
as and when they like.

HTH

--

[1] Which must, btw, make HTMLTemplate the Holy Hand Grenade. And PHP
that ruddy rabbit... Boo-Yah! ;)

[2] The only difference between the two is who gets responsibility for
writing the View layer's control logic: in PHP et-al, it's the
webhead; in HTMLTemplate it's the l33t hAX0r.

[3] From the Apple definition of MVC, where the Controller layer
bridges the View (made up of GUI objects) and Model (business logic)
layers. As distinct to the original Smalltalk definition which they
they hijacked to their own nefarious ends.