[ANN] HTMLTemplate 1.0.0

Discussion in 'Python' started by has, Jun 1, 2004.

  1. has

    has Guest

    has, Jun 1, 2004
    #1
    1. Advertising

  2. has

    Peter Maas Guest

    has schrieb:
    > Announcing the final v1 release of HTMLTemplate; best damn HTML
    > templating system evar, or yer money back. Enjoy! :)


    Good work BUT
    there are some other Python templating frameworks around, e.g.

    - Cheetah
    - ZOPE's TAL
    - about half a dozen TAL derivatives
    - Quixote's PTL
    - SkunkWeb's STML
    - Yaptu
    - XYaptu
    - Template Macro

    Did you find these alternatives unsatisfactory? If somebody wants
    to use a Python templating framework why should he prefer
    HTMLTemplate?

    Mit freundlichen Gruessen,

    Peter Maas

    --
    -------------------------------------------------------------------
    Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
    Tel +49-241-93878-0 Fax +49-241-93878-20 eMail
    -------------------------------------------------------------------
    Peter Maas, Jun 2, 2004
    #2
    1. Advertising

  3. has

    David Fraser Guest

    Peter Maas wrote:
    > has schrieb:
    >
    >> Announcing the final v1 release of HTMLTemplate; best damn HTML
    >> templating system evar, or yer money back. Enjoy! :)

    >
    >
    > Good work BUT
    > there are some other Python templating frameworks around, e.g.
    >
    > - Cheetah
    > - ZOPE's TAL
    > - about half a dozen TAL derivatives
    > - Quixote's PTL
    > - SkunkWeb's STML
    > - Yaptu
    > - XYaptu
    > - Template Macro
    >
    > Did you find these alternatives unsatisfactory? If somebody wants
    > to use a Python templating framework why should he prefer
    > HTMLTemplate?
    >
    > Mit freundlichen Gruessen,
    >
    > Peter Maas
    >

    It looks cool because it doesn't embed Python code in the template.
    Do any of the other frameworks have this approach?

    David
    David Fraser, Jun 2, 2004
    #3
  4. has

    Duncan Booth Guest

    David Fraser <> wrote in news:c9ka2h$d57$1@ctb-
    nnrp2.saix.net:

    >> Good work BUT
    >> there are some other Python templating frameworks around, e.g.
    >>
    >> - Cheetah
    >> - ZOPE's TAL
    >> - about half a dozen TAL derivatives
    >> - Quixote's PTL
    >> - SkunkWeb's STML
    >> - Yaptu
    >> - XYaptu
    >> - Template Macro
    >>
    >> Did you find these alternatives unsatisfactory? If somebody wants
    >> to use a Python templating framework why should he prefer
    >> HTMLTemplate?
    >>
    >> Mit freundlichen Gruessen,
    >>
    >> Peter Maas
    >>

    > It looks cool because it doesn't embed Python code in the template.
    > Do any of the other frameworks have this approach?
    >


    The earlier Zope templating language DTML had the problem that it embedded
    logic in the templates, and this was one of the main factors behind the
    development of TAL and METAL. TAL still allows simple Python expressions,
    but these are in namespace protected attributes so that the actual template
    is always valid XHTML or XML, and it is quite possible to write TAL without
    using any Python expressions (indeed you can have a TAL implementation that
    doesn't support Python). Ensuring that TAL templates were valid XHTML was
    an important design goal because it allows ordinary HTML editors to be used
    on the template provided they preserve attributes from other namespaces.

    By contrast, a template in HTMLTemplate isn't valid HTML since it contains
    undefined attributes in the default namespace. It is reasonable to expect
    that an HTML editor will strip out the illegal attributes.

    The ultimate Python templating framework for separating Python from the
    template has to be PyMeld. PyMeld templates are pure XHTML with no
    additional attributes whatsoever.
    Duncan Booth, Jun 2, 2004
    #4
  5. has

    Peter Maas Guest

    David Fraser schrieb:
    >> Did you find these alternatives unsatisfactory? If somebody wants
    >> to use a Python templating framework why should he prefer
    >> HTMLTemplate?

    [..]
    > It looks cool because it doesn't embed Python code in the template.
    > Do any of the other frameworks have this approach?


    That's your personal taste. If this is what you like about HTMLTemplate
    that's fine. I don't bother wether a template language contains Python
    code or not. To answer your question:

    Hamish's example rewritten in TAL (TAL lines below Hamish's equivalents):

    <html>
    <head>
    <title node="con:title">TITLE</title>
    ###TAL <title tal:content="here/title">TITLE</title>
    </head>
    <body>
    <ul>
    <li node="rep:item">
    ###TAL <li tal:repeat="link here/objectValues">
    <a href="" node="con:link">LINK</a>
    ###TAL <a tal:attributes="href link/name" tal:content="link/title">LINK</a>
    </li>
    </ul>
    </body>
    </html>

    But I wanted to read Hamish's thoughts. That would be helpful for
    programmers because it takes some time to find your way through the
    maze of Python template languages.

    I prefer Cheetah. Hamish's example in Cheetah:

    <html>
    <head>
    <title>$title</title>
    </head>
    <body>
    <ul>
    #for $link in $links
    <li>
    <a href="$link.href">$link.text</a>
    </li>
    #end for
    </ul>
    </body>
    </html>

    Advantages:

    - No magic
    - placeholders occupy the places of their replacements
    - logic is visible in the template
    -> you see what's going on
    - logic is visible in the rendered html page
    -> you see where the replacements will go
    - Cheetah templates everything, not only markup

    Mit freundlichen Gruessen,

    Peter Maas

    --
    -------------------------------------------------------------------
    Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
    Tel +49-241-93878-0 Fax +49-241-93878-20 eMail
    -------------------------------------------------------------------
    Peter Maas, Jun 2, 2004
    #5
  6. On Wed, 02 Jun 2004 12:27:43 +0200,
    David Fraser <> wrote:
    > It looks cool because it doesn't embed Python code in the template.
    > Do any of the other frameworks have this approach?


    Quixote's PTL embeds the template in Python code. Using the example given
    elsewhere in this thread:

    from quixote.html import href

    def page
    HTML:
     (title, links):
        '<html><head>'
        '<title>%s</title>' % title
        ...
        for link in links:
            '<li>'
    	href(link.href, link.text)
            '</li>'
        ...
    
    See http://www.mems-exchange.org/software/quixote/doc/PTL.html for details.
    
    --amk
    A.M. Kuchling, Jun 2, 2004
    #6
  7. has wrote:
    > Announcing the final v1 release of HTMLTemplate; best damn HTML
    > templating system evar, or yer money back. Enjoy! :)
    >
    > http://freespace.virgin.net/hamish.sanderson/htmltemplate.html


    This HTMLTemplate is quite different from the other HTML-Template's I've
    seen...

    http://html-template.sourceforge.net/ - Perl

    http://phphtmltemplate.sourceforge.net/ - PHP

    http://htmltmpl.sourceforge.net/ - Python & PHP

    http://html-tmpl-java.sourceforge.net/ - Java

    http://shebang.jp/src/ruby/ - Ruby

    http://weitz.de/html-template/ - Common Lisp


    I believe these all share the basic idea of using a common templating
    language within your HTML documents (which can be valid, if using <!--
    comments --> for the tags.)

    The original is the first one, in Perl, and all the others followed,
    implementing in other languages.

    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.

    Pete
    Pete Prodoehl, Jun 2, 2004
    #7
  8. David Fraser wrote:

    > It looks cool because it doesn't embed Python code in the template.
    > Do any of the other frameworks have this approach?


    opagcgilib.py is a simple look for %%key%% in dictionary and substitute
    value type of template tool. Which, quite frankly, is enough for me.
    All of the embedded python whoo-ha is just more of a barrier than
    anything else.

    Every time some bright puppy comes up with another twisted syntax party
    trick, it makes software development even more inaccessible to
    handicapped people like myself.

    I like Python for many reasons but a very important one is that it is
    something I can dictate using unenhanced speech recognition tools like
    NaturallySpeaking. It lets me get my work done and the typing idea have
    to do, doesn't aggravate the pain in my hands/arms.

    So anytime someone creates something with lots of special characters and
    StUDlYCapS, I want to scream but I don't because I don't want to damage
    my voice like I did my hands.

    Every time there is something special in the text that deviates from
    English, I need to go build a special tool to translate English to that
    SpclEnv. It is unfortunately not an easy process because most tools nor
    NaturallySpeaking are built for signaling context changes or making
    context changes. The end result being that I try to create only simple
    grammars and avoid using tools that cause me physical pain.

    having said that, I should probably admit to having created my own web
    page template tool. It is a very simple tool based on the opagcgilib.py
    Toolkit. since opagcgilib.py uses a dictionary as its input, I created
    a dictionary derivative that when an entry is read, it runs the value
    through opagcgilib.py. when a substitution occurs, it triggers a
    recursive run through opagcgilib.py until a value has no substitutions.

    The end effect is if you stuff a dictionary with a template and then all
    the components that will be requested during substitutions, you can
    merge these elements together into a single HTML page. What's a very
    nice is that you can just change the elements you need for subsequent
    pages. there are some helper functions for importing pages or fragments
    thereof into the dictionary.

    the user experience of editing these fragments is actually quite easy.
    All fragments are complete HTML pages and can be edited with an ordinary
    HTML editor. The only thing that is special is that sometimes you see
    %%main_body%% in a fragment. Everything else is just the same which is
    good because high-level editing of HTML is far easier if you are using
    speech recognition. (Are you starting to get a sense of a theme here... :)

    here is a fragment from the camram web site construction code
    (unfortunately line wrapped)

    zodiac = inflatable()
    zodiac["top"] = extract_all("top_template.html")
    zodiac["copyright_date"] = "2002-2004"
    zodiac["main_welcome"], zodiac["title"] =
    extract_core("main_welcome.html", True)
    zodiac["main_news"] = extract_core("main_news.html")
    expel_all ( zodiac["top"], "output/index.html")


    # set up for all internal pages
    zodiac["top"] = extract_all("internal_template.html")

    # now do only per page changes

    # pages referred to by the top menus
    zodiac["title"] = "c a m r a m: Download It:"
    zodiac["body_text"], zodiac["title"] = extract_core("download.html", True)
    expel_all ( zodiac["top"], "output/download.html"

    --------------

    and yes, this is what Python code written by speech recognition looks like.

    ---eric
    Eric S. Johansson, Jun 2, 2004
    #8
  9. has

    has Guest

    Peter Maas <> wrote in message news:<c9k8gt$sqh$>...
    > has schrieb:
    > > Announcing the final v1 release of HTMLTemplate; best damn HTML
    > > templating system evar, or yer money back. Enjoy! :)

    >
    > Good work BUT
    > there are some other Python templating frameworks around, e.g.

    [...]
    > Did you find these alternatives unsatisfactory?


    Yep. Some reasons:

    1. Most Python templating systems are either code-in-markup or
    markup-in-code designs, which don't provide clean separation between
    markup and code. Code-in-markup systems at best separate only business
    logic; presentation logic remains firmly embedded in markup.
    Markup-in-code systems provide no separation whatsoever (the only
    example I've liked the look of is Lisp-based
    <http://www.lisp-p.org/lh/lh.html>, but I'm not a Lisp programmer).

    HTMLTemplate uses a simple DOM-derived approach that provides complete
    View-Controller separation [according to Apple's definition of MVC,
    not Smalltalk's]. An HTML template is converted into a simple object
    model (the View layer) that can be manipulated from your Python script
    (the Controller layer). BTW, how the user defines the Model layer is
    left completely up to them (in simple scripts I just squish any
    business logic into the controller code, in more complex systems I
    keep 'em separate). Not my place to dictate that to them; smells of
    fascism.


    2. A good proportion of other templating systems invent their own
    custom templating languages rather than leverage an existing one (e.g.
    Python). See Greenspun's Tenth Rule for why this is generally a bad
    idea. (I learned this lesson the hard way from writing my second
    templating system, which tried to copy the PHP/ASP custom
    HTML-embedded language approach. Took me two months to write, two
    weeks to debug, and less than a week from completion to burial beneath
    the patio. Just as well really; the v2 TO DO list was growing almost
    as long as the v1 codebase.:)


    3. Most templating systems are either "powerful but complex", "simple
    but underpowered" (i.e. crippled and inadequate) or, in worst cases,
    "complex AND underpowered". "Flexible" costs extra in any case. The
    best solution would be one that's both powerful and flexible while
    also remaining simple in implementation and use: basic Unix
    philosophy.

    After designing/writing two complex, underpowered and inflexible
    templating systems, my third finally met the "powerful" requirement.
    Unfortunately, it proved just as complex and clumsy in practice;
    features added to make it more flexible and easy to use paradoxically
    having the opposite effect. I finally cracked that problem on number
    four (the original HTMLTemplate, of which the Python version is a
    partially reworked port) simply by throwing out every last bit of
    non-essential, non-core functionality I could find and working on what
    was left to get it just right.


    > If somebody wants to use a Python templating framework
    > why should he prefer HTMLTemplate?


    Think of the four years, thousands of lines of code, and dozens of
    features that have gone into its creation. Then do a line count of the
    API and codebase against the rest of the pack. ;)

    HTH
    has, Jun 2, 2004
    #9
  10. has

    has Guest

    Duncan Booth <> wrote in message news:<Xns94FC7930CEC00duncanrcpcouk@127.0.0.1>...

    > By contrast, a template in HTMLTemplate isn't valid HTML since it contains
    > undefined attributes in the default namespace. It is reasonable to expect
    > that an HTML editor will strip out the illegal attributes.


    HTMLTemplate allows you to specify a different 'special' attribute
    name via the Template constructor, so you can use attributes like 'id'
    and XML namespaces instead of 'node' if you prefer. (The reason I made
    'node' the default is that it's more or less self-explanatory so
    convenient for new users. I've updated the HTMLTemplate homepage to
    clarify this issue.)

    It's also quite intelligent in how it parses these attributes. For
    example, when using 'id', an element like <div id="con:foo">...</div>
    would be identified as containing a legal compiler directive, the
    special attribute stripped and a template node created. All other 'id'
    attributes would be left untouched, however, so you can still safely
    use them as normal id attributes on non-node elements.


    > The ultimate Python templating framework for separating Python from the
    > template has to be PyMeld. PyMeld templates are pure XHTML with no
    > additional attributes whatsoever.


    I looked at PyMeld early on as it's closest to HTMLTemplate in concept
    and behaviour and about the same in code size and complexity. Its
    shortcomings are a non-standard licence, an inferior API [compared to
    HTMLTemplate] that requires users to write their own loops and,
    according to its author, some performance issues due to naive
    implementation. All quite fixable, of course, but it was just more
    convenient for me to port my existing HTMLTemplate implementation to
    Python.


    Hope that allays your fears. :)

    --

    (p.s. Inquisitive users may also spot the potential for
    meta-templating that being able to specify one's own 'special'
    attribute names provides. Though whether anyone can come up with an
    actual use for meta-templating is another question entirely...;)
    has, Jun 2, 2004
    #10
  11. has

    has Guest

    David Fraser <> wrote in message news:<c9ka2h$d57$>...

    > It looks cool because it doesn't embed Python code in the template.
    > Do any of the other frameworks have this approach?


    Nevow.Renderer and PyMeld are the only other Python systems I've seen
    that give the same level of separation between markup and code.
    HTMLTemplate has a better API, however. (e.g. A test port I did of the
    Nevow2004Examples/Example1 code halved the length of the Controller
    layer from 29LOC to 14.)

    (Nevow.Renderer also suffers from heavy coupling to the rest of the
    Nevow package and to the Twisted framework. It's still very young,
    mind you, so this may improve in time.)
    has, Jun 2, 2004
    #11
  12. has

    has Guest

    Pete Prodoehl <> wrote in message news:<>...

    > This HTMLTemplate is quite different from the other HTML-Template's I've
    > seen...

    [...]

    I confess that the potential for confusion didn't occur to me till
    fairly late on. I just chose the name because it was self-explanatory
    and didn't clash with the name of any existing modules for the same
    languages, and didn't realise that html-template modules for other
    languages were similarly derived from a single common source. Guess I
    should hurry to snap up any as-yet unaffiliated languages before the
    competition gets there first...;)


    > I believe these all share the basic idea of using a common templating
    > language within your HTML documents (which can be valid, if using <!--
    > comments --> for the tags.)

    [...]
    > 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?
    has, Jun 2, 2004
    #12
  13. has

    Jarek Zgoda Guest

    Peter Maas <> pisze:

    > Good work BUT
    > there are some other Python templating frameworks around, e.g.
    >
    > - Cheetah
    > - ZOPE's TAL
    > - about half a dozen TAL derivatives
    > - Quixote's PTL
    > - SkunkWeb's STML
    > - Yaptu
    > - XYaptu
    > - Template Macro
    >
    > Did you find these alternatives unsatisfactory? If somebody wants
    > to use a Python templating framework why should he prefer
    > HTMLTemplate?


    I tried 3 or 4 from the above list and none fits my needs and taste. The
    only two that I found interesting was ll.xist from LivingLogic and
    HTMLTemplate. For my current needs ll.xist is pure overkill, but I'll
    give it a try some day, since idea of "object-oriented XSLT" seems
    appealing (see http://www.livinglogic.de/Python/xist/index.html).

    --
    Jarek Zgoda
    http://jpa.berlios.de/
    Jarek Zgoda, Jun 2, 2004
    #13
  14. has wrote:
    > Pete Prodoehl <> wrote in message news:<>...
    >
    >>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? ;)

    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.

    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.

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


    Pete
    Pete Prodoehl, Jun 2, 2004
    #14
  15. has

    Duncan Booth Guest

    (has) wrote in
    news::

    >> The ultimate Python templating framework for separating Python from the
    >> template has to be PyMeld. PyMeld templates are pure XHTML with no
    >> additional attributes whatsoever.

    >
    > I looked at PyMeld early on as it's closest to HTMLTemplate in concept
    > and behaviour and about the same in code size and complexity.


    I got the impression that your HTMLTemplate was quite similar in concept to
    TAL but less powerful (probably deliberately). Certainly it looks as though
    most of your constructs map straight onto a very similar TAL expression.
    Duncan Booth, Jun 3, 2004
    #15
  16. has

    has Guest

    Pete Prodoehl <> wrote in message news:<>...

    > >>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.
    has, Jun 3, 2004
    #16
  17. has

    has Guest

    Peter Maas <> wrote in message news:<c9kfd3$854$>...
    > David Fraser schrieb:
    > >> Did you find these alternatives unsatisfactory? If somebody wants
    > >> to use a Python templating framework why should he prefer
    > >> HTMLTemplate?

    > [..]
    > > It looks cool because it doesn't embed Python code in the template.
    > > Do any of the other frameworks have this approach?

    >
    > That's your personal taste.


    While taste certainly plays a role, I think there are also sound
    technical arguments to be made for complete code-markup separation.


    > If this is what you like about HTMLTemplate
    > that's fine. I don't bother wether a template language contains Python
    > code or not. To answer your question:
    >
    > Hamish's example rewritten in TAL (TAL lines below Hamish's equivalents):
    >
    > <html>
    > <head>
    > <title node="con:title">TITLE</title>
    > ###TAL <title tal:content="here/title">TITLE</title>
    > </head>
    > <body>
    > <ul>
    > <li node="rep:item">
    > ###TAL <li tal:repeat="link here/objectValues">
    > <a href="" node="con:link">LINK</a>
    > ###TAL <a tal:attributes="href link/name" tal:content="link/title">LINK</a>
    > </li>
    > </ul>
    > </body>
    > </html>


    This is embedded code, though in a custom language rather than Python.
    This has a couple of advantages: it's terser (less typing) and less
    abstract (easier for non-programmers to cope with).

    The disadvantages are: you've another language to learn before you can
    use the system, you're limited in what you can do and how you do it by
    that language's featureset, and code (Controller) and markup (View)
    are tightly coupled (loose coupling makes for a more flexible and
    easier to maintain architecture, while the standard argument in favour
    of tight coupling - raw performance - doesn't apply in this case).

    Also, the terseness and minimal abstraction are only really advantages
    in simple cases; with more complex systems the number of keystrokes
    saved is an insignificant proportion of the total typing done, and the
    lack of abstraction becomes a significant disadvantage (like having to
    write a 500-line program as a single continuous main() routine without
    procedures or namespaces to structure it).


    I'm not sure if TAL supports callbacks into Python code. ZPT allows
    you to do this, allowing you to fall back to Python for tasks that the
    templating language isn't able to perform itself; your basic two-tier
    hybrid. The two other approaches mini-language based systems seem to
    take are:

    - expand their templating languages till they become full
    Turing-complete programming languages in their own right

    - keep the templating language restricted to the absolute basics:
    insertion, conditionals and iteration.

    The fundamental folly of the first approach ought to be obvious
    enough; see Greenspun's Tenth Rule.

    The second seems quite sensible, at least on paper: state that it is
    not the templating language's job to be a general-purpose scripting
    language, limit its scope to providing only the core functionality
    necessary to insert pre-prepared data into the template, and leave the
    client to do that data preparation themselves.

    In practice though, it seems terribly inefficient and somewhat
    redundant to have your data in one highly structured form, e.g. a
    collection of database tables, file objects, native data structures,
    etc., and have to munge that into another highly structured form, e.g.
    a large, deeply-nested lists-and-dicts structure directly
    corresponding to the template's final structure, just so the
    templating engine can morph this structure into yet another form. It
    would be more sensible to skip the middle step, eliminating all
    restrictions on the type or form of data that the template can
    consume. The temptation then is to evolve the second type of system
    into the first; but then you're back to chasing that never-ending
    feature request list for more power, more flexibility, more
    convenience, and its Greenspun's rule all over again.

    ....

    > But I wanted to read Hamish's thoughts.


    Heh, no chance! My tinfoil beanie successfully blocks your devilish
    CIA X-Ray Secret Mind Reading Abilities, so I'm afraid you'll just
    have to stick to standard plaintext communication protocols. Damned
    inefficient, I know, but I can't risk you finding out where the
    treasure is buried. ;)


    > That would be helpful for programmers because it takes some time
    > to find your way through the maze of Python template languages.


    I am, of course, happy to wait till the rest finally declare that
    "It's a fair cop, guv!" and gracefully concede defeat. (Like that's
    ever gonna happen, hey?;)


    > I prefer Cheetah.


    Teensy request: I think it'd help our readers if you could also show
    your Python code for hooking up to these templates and feeding them
    data; allow them to compare like-against-like. That'd be cool.

    ....

    Hamish's example in Cheetah:
    >
    > <html>
    > <head>
    > <title>$title</title>
    > </head>
    > <body>
    > <ul>
    > #for $link in $links
    > <li>
    > <a href="$link.href">$link.text</a>
    > </li>
    > #end for
    > </ul>
    > </body>
    > </html>


    I like Cheetah less than TAL. TAL, like HTMLTemplate, treats the
    template's HTML as a first-class citizen; Cheetah is much closer to
    the original macro processors from which all PHP/ASP/Cheetah/etc.
    style systems are basically descended and treat everything non-macro
    pretty much as dumb, meaningless character streams.

    Like I think I've said elsewhere, I've already designed, written,
    shipped and canned this sort of system myself before moving to
    DOM-derived designs, so I've firsthand experience from both sides of
    the fence and am quite certain that while there's some situations
    where the former is better, these are really just corner cases and the
    center field would be completely owned by HTMLTemplate-style systems
    if it hadn't been for those pesky PHP kids doing a BASIC upon us
    first. (Ah well; fair fight, early worm, and all that. Can't blame 'em
    for being successful; besides, it's never _too_ late to Change...:)

    ....

    > Advantages:
    >
    > - No magic


    No magic to HTMLTemplate either. It simply uses a more sophisticated
    model to describe and construct renderable templates.

    I'd suggest a good comparison is Apple's excellent Interface Builder,
    which allows desktop applications' Views to be constructed without
    writing or generating a single line of program code. In Cocoa GUI
    construction, everything is done by manipulating object instances
    directly, assembling them into a live, fully-functional object model
    and adding a smidgin of binding information to connect them to the
    application's Controller layer. [1]

    > - placeholders occupy the places of their replacements
    > - logic is visible in the template
    > -> you see what's going on
    > - logic is visible in the rendered html page
    > -> you see where the replacements will go


    These aren't outright advantages; merely differences in goals.

    Plus other advantages, like the ability to mockup your HTML templates
    to look like finished pages - very helpful for designers and clients
    in visualising their designs - are conspicuous by their absence. (Note
    that TAL and some other code-in-markup systems also share this
    ability, so it's not an advantage unique to DOM-derived systems;
    although they're certainly an excellent natural fit for it.
    Conversely, Cheetah's at a decided disadvantage here, since making
    Cheetah templates look anything like the pages they'll eventually
    produce is going to be rather hard with all that macro-style stuff
    strewn throughout.)

    PHP-style systems' lack of abstraction makes them particularly
    appealing to folk with little or no abstract design skills; i.e.
    non-programmers (and crap programmers, if you're being brutally
    honest;). This is certainly a valuable feature for those users, but I
    think this is oversold as an advantage while its disadvantages -
    particularly the ease with which is can yield the most amazing
    spaghetti code when put to use in non-trivial tasks - are
    simultaneously undersold to everybody else.

    Your average Python user, for example, shouldn't have any conceptual
    problems dealing with the stronger abstractions of DOM-derived systems
    like HTMLTemplate; and really, anyone that can understand and write
    basic DHTML should quickly find themselves at home.

    By comparison, while HTMLTemplate presents newcomers with a slightly
    greater conceptual first hurdle to pass, once over it there isn't much
    else left to learn. Meanwhile, the system itself scales extremely
    well: while trivial code examples like the introductory tutorial on my
    site can always be rewritten to look smaller and simpler in an
    embedded language (which I'd never dispute, btw), I think you'll
    really start noticing the difference as you move to larger, more
    complex "real-world" templating tasks. For example, it'd be most
    interesting to see a code comparison between Cheetah/TAL/PSP/EmPy/PTL
    and HTMLTemplate for something like the scripting terminology renderer
    in my appscript package. (Though at several hundred lines of HTML and
    code I won't mind if nobody takes me up on this; it'd take a good few
    hours' work with no actual reward at the end of it.:)

    ....

    Incidentally, one of the projects on my "Fun" list is to write a
    simple template macro preprocessor that can read a simple TAL-like
    template and generate HTMLTemplate-based View and Controller layers
    from it. This could make HTMLTemplate a great sell for developers
    writing "Aunt Millie" shrinkwrapped software (e.g. stuff like
    Fogcreek's CityDesk): non-programmers and "lite" users could use a
    simple embedded macro expansion system to produce simple HTML
    pages/customise their own; advanced users could dive straight in at
    the Python API level.

    The advantage of this approach is that users who start off using the
    macro system can seamlessly transition to the more powerful underlying
    programmatic system; they can even take their previous work with them,
    simply throwing away the original macro-based templates after
    outputting the code-generated versions to file for future modification
    and use.

    So this is definitely something I've thought about; the only
    difference is I'd answer it with a loosely coupled, multi-layered,
    componentised solution, not a big monolithic system that needs a
    chainsaw to reshape into any form not explicitly provided for by its
    designers.
    ....

    > - Cheetah templates everything, not only markup


    HTMLTemplate's motto here would be: "Don't bite off more than you
    really need to chew." As I think I've said elsewhere, most of its
    development history has involved throwing _away_ functionality whose
    presence did not belong in HTMLTemplate or whose cost could not be
    sufficiently justified to merit inclusion. In this case,
    responsibility for non-HTML templating has been turned over to
    texttemplate, which has been deliberately designed as a
    general-purpose templating engine rather than optimised specifically
    for working with HTML. I could just as easily turn this argument
    around by saying that Cheetah spreads itself too thinly, and adds
    unnecessary baggage for users who only want to do HTML templating.

    ....

    Anyway, I think you really need to approach HTMLTemplate on its own
    terms. It was never intended to be
    yet-another-PHP-style-macro-preprocessor-turned-into-full-blown-language
    templating system. It's actually an example of convergent evolution:
    while in the large it aims to solve the same problems as Cheetah
    et-al, it does so from completely different first principles and
    influences and with different detailed goals: total
    designer/programmer separation; desktop application architecture
    practices; DOM/Apple Event Manager object model; minimalist name-based
    object-code bindings.

    Now, the macro processor-style approach certainly works, and has an
    advantage in working equally well with any template type, while
    HTMLTemplate is limited to SGML-based markup (you'll need to use
    texttemplate[2] for templating other types of text). But ultimately it
    achieves its aims more through brute force than real elegance. It
    generally has to expend quite a bit of effort to reach its goals, and
    a lot of hard work that is, unfortunately, entirely self-imposed. A
    quick comparison of the Cheetah and HTMLTemplate APIs and codebases
    will easily demonstrate:

    - Cheetah's API consists of a complete built-in custom scripting
    language in addition to its Python-based "housekeeping" API, while the
    codebase spans twenty-odd modules and a C extension containing several
    thousand lines of code.

    - HTMLTemplate's API consists of four public classes [3] with under a
    dozen properties and methods between them, and the implementation is
    precisely 333 lines long.


    HTMLTemplate's entire API can fit comfortably within Cheetah's
    housekeeping API, with room left over. Cheetah's setup scripts alone
    run to a couple hundred LOC; HTMLTemplate is mostly implemented in
    that. I think if you're going to measure the two, you seriously have
    to consider these aspects as well, because they have major
    implications for things like user learning curves, developer
    maintenance, and, ultimately, reaching that magical v1.0 release that
    says "This System is Officially Complete."

    Cheetah is a helluva impressive achievement in itself; I can't imagine
    how many man-hours, how much blood sweat and tears have gone into
    getting it to where it is today. Though I'm willing to bet it's no
    more than I've put into getting HTMLTemplate to where it is today. The
    only difference is, looking at HTMLTemplate you can't actually see the
    many hundreds of hours and thousands of lines of code that it took me
    to get there, because I spent several hundred more hours getting rid
    of almost all of those thousands of lines of code. Like being a
    professional conjurer: you spend many long years making amazingly
    sophisticated and skillful sleight of hand appear to all the punters
    as if it took absolutely _no_ effort at all. Under those
    circumstances, y'just can't win...;)

    ....

    Funnily enough, if I'm worried about anything, it's that HTMLTemplates
    comparatively tiny size and simple API will cause casual viewers to
    assume it must be a crude, shallow, underpowered system only fit for
    trivial templating tasks. Because, you know, Real Templating is a
    Serious Business, and requires Seriously Large Templating Technologies
    like PHP, Cheetah, Velocity, etc, etc. After all, all that heavy-duty
    engineering must exist for a damn good reason, mustn't it? I mean,
    folk surely wouldn't go to all the trouble of writing it if it
    _weren't_?

    The single most important lesson I've learnt from developing
    HTMLTemplate's predecessors is that although learning how to factor
    and refactor program code well is a valuable skill, learning how to
    factor and refactor program _design_ is a hundred times _more_
    valuable than that[4]. Because ultimately it doesn't matter that much
    how talented a coder you are: if the problem is split along just the
    right plane, even an average programmer like myself can, at the end of
    the day, outstrip one with ten times the coding skills who misses the
    natural grain and smacks it sideways instead. But anyway, I should
    shut-up on this angle before I start sounding like some insufferable
    Smalltalk/Lisp/Unix philosophy weenie. ;)

    ....

    Anyway, hope this mental splurge has been of some use to you (and
    anyone else that's managed this far<g>).

    Cheers,

    has

    --

    [1] There are some differences, of course: an IB GUI is assembled via
    drag-n-drop whereas HTMLTemplate uses compiler directives that
    indicate the type, name and relative location of each object to
    create; and IB pickles the resulting View object models for later
    rehydration and use, while HTMLTemplate users will generally compile
    their Views immediately before use.[1]

    [1a] Incidentally, the original HTMLTemplate did employ pickling, but
    that's because it was written in AppleScript, where it takes several
    seconds to compile a template (mostly because I had to resort to code
    generation to get around its lack of deep language features like
    introspection and dynamic slot addition; fortunately, its built-in
    object serialisation abilities makes pickling a breeze - a Smalltalk
    influence, I think). Eliminating the need for compiled template
    pickling was a major aim of the Python port, and quite successful, I
    think: HTMLTemplate/Python compiles templates in a few
    milliseconds/tens of milliseconds.

    [2] Note that the current texttemplate release, 0.1.0, has an older
    more complex API that I've since reworked for HTMLTemplate and am in
    the process of reworking for texttemplate; so I don't really recommend
    using the 0.1.0 version as its API _will_ be changing soon.

    [3] I fudge the exact number in the documentation; there's several
    subclasses I don't bother to distinguish between as the user has no
    need to know about these (one of the compromises I had to make in
    porting a nice simple prototype-based OO design to a less flexible
    class-based language).

    [4] That's 10x difference in API complexity times 10x difference in
    code length, if you're wondering...;)
    has, Jun 3, 2004
    #17
  18. John Machin wrote:

    > [...]
    > Oh, you want *practical* experience eh? ;)
    >
    > 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.


    XIST follows a different philosophy: All templates are pure XML (in
    fact most of our templates consist of a root element only (something
    like <newsPage/>)). The rest is done in pure Python code. The designer
    develops the XML elements for the layout. This might be something
    simple like:

    class pageTitle(xsc.Element):
    def convert(self, converter):
    e = html.h1(self.content)
    return e.convert(converter)

    These layout elements can then be used for a static mockup to be
    presented to the customer (i.e. <pageTitle>foobar</pagetitle>
    in XML or layout.pageTitle("foobar") in Python). The developer
    responsible for the dynamic part uses these layout elements with
    XIST JSP elements to implement the business logic, e.g. by using
    layout.pageTitle(jsp.expression("myObject.getTitle()")). It would
    be possible to use any other templating system for implementing
    the business logic, e.g. use PHP:
    layout.pageTitle(php.expression("$myObject->getTitle()").

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


    XIST uses another version, just that both logic and presentation
    are implemented in Python. ;)

    You have to say goodbye to your HTML editor with this approach, but
    this gives you better control over your HTML code anyway.

    Our main designer had no previous programming experience and was using
    Adobe GoLive before joining our company. Now he's programming all his
    HTML templates in Python without any problems.

    Bye,
    Walter Dörwald
    =?ISO-8859-1?Q?Walter_D=F6rwald?=, Jun 3, 2004
    #18
  19. Peter Maas <> wrote in message news:<c9k8gt$sqh$>...
    > has schrieb:
    > > Announcing the final v1 release of HTMLTemplate; best damn HTML
    > > templating system evar, or yer money back. Enjoy! :)

    >
    > Good work BUT
    > there are some other Python templating frameworks around, e.g.
    >
    > - ....... etc
    >
    > Did you find these alternatives unsatisfactory? If somebody wants
    > to use a Python templating framework why should he prefer
    > HTMLTemplate?


    Having had a play with HTMLTemplate, albeit after a few tweaks, one area
    where it seems to be perhaps better suited than other methods is when
    an event driven system is being used.

    This is because with most of the other systems the filling out of data and
    rendering of the template is an atomic operation. In other words, you
    execute the operation to render the template and it calls out of the render
    engine to collect data which is used to fill in the data.

    This means the data must already exist if you want to avoid a potentially
    blocking operation which collects it. In an event driven system this isn't
    good as it means nothing else in the application can run. The only way
    around it is to initiate the rendering inside the context of a separate thread.

    When you have to do this on top of an event system it can get messy
    though as you need to then deal with communication between the thread
    and the event system when the rendering is done to say that the event
    system can take up from where it left off.

    Now in order to avoid use of threads, one could go to the extent of collecting
    all the data first, making use of the event system appropriately to ensure
    no blocking operations occur, but that means caching all the data which
    goes towards rendering the template up till the point it needs to be rendered.

    The idea that HTMLTemplate uses of constructing a DOM type model of the
    page is therefore convenient as you can construct the template at some
    point and then over time as event driven callbacks are triggered indicating
    return of required data, you can fill out the template in bits.

    Only when the last bit of data has finally arrived do you then render the
    template back into a textual form. If at any point one of the event callbacks
    indicates an error you can just abandon the template and send back an
    error along with the output of some of template page instead.

    Having said that, the only problem with HTMLTemplate is that its render()
    function actually enforces the model which I said is no good for an event
    driven system. Ie., data collection is triggered by the action to render the
    template.

    To get around this, the render() function implementation needs to be split
    into three phases, the cloning of the template, the execution of the callback
    to fill in the data and the rendering of the template back to text. If the
    cloning and rendering are in separate functions, it then allows an event
    driven system to control things in a more appropriate manner.

    Namely, in one event system callback it can clone the template, in a series
    of other event system callbacks it can fill out the data and then finally in a
    last event system callback it can render the template to text and deliver
    the result to the HTTP servlet engine or whatever other mechanism is used
    to serve up the result.

    The changes to the code aren't that hard and it would make it that much
    more flexible and useful in event driven systems. I have forwarded the
    appropriate changes direct to the author and hopefully he will include
    them, otherwise I will have to use a derived class which delves into the
    private bits of their code. :-(

    Now as to other template systems that are event driven system friendly,
    the only one I know of for Python is Nevow, but that is bound up with
    Twisted and thus couldn't be used with any other system. For my mind,
    from the little I have looked at the Nevow examples, I am also not keen
    on its magic system for callbacks dependent on naming. This sorts of
    binds it quite tightly to a particular way of building your classes which I
    would rather avoid.

    Overall therefore, for what I am doing HTMLTemplate looks like a good
    option.
    Graham Dumpleton, Jun 4, 2004
    #19
  20. has

    has Guest

    "Eric S. Johansson" <> wrote in message news:<>...

    > having said that, I should probably admit to having created my own web
    > page template tool. It is a very simple tool based on the opagcgilib.py
    > Toolkit.


    You might like to post a link on the python.org wiki for reference:
    <http://www.python.org/cgi-bin/moinmoin/WebProgramming>. Seems to be
    the main place for this kind of info.

    HTH

    (p.s. If you try HTMLTemplate, I'd be really interested to hear how it
    goes.)
    has, Jun 4, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike Sampson [MSFT]

    [ANN]: NNTP Server slow downs.

    Mike Sampson [MSFT], Oct 7, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    406
    Mike Sampson [MSFT]
    Oct 7, 2003
  2. Mike Sampson [MSFT]

    [ANN]: NNTP Server slow downs.

    Mike Sampson [MSFT], Dec 6, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    489
    Mike Sampson [MSFT]
    Dec 6, 2003
  3. Richard Grimes [MVP]

    ANN: Free .NET Workshops

    Richard Grimes [MVP], Jul 4, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    501
    Richard Grimes [MVP]
    Jul 4, 2005
  4. has
    Replies:
    0
    Views:
    275
  5. Michael Livsey
    Replies:
    3
    Views:
    415
    Michael Livsey
    May 27, 2004
Loading...

Share This Page