FAQ
Are there any projects out there that allow you to embed python in HTML
like PHP? I like the PHP-style of embedding the bits of program in HTML,
but I'd like to use python...
Something like:

<html>
<?python
print "<ul>"
for reptile in ["Crocodile", "Python", "Iguana", "Tortoise"]:
print "<li> %s </li>" % reptile
print "</ul>"
?>
</html>

Search Discussions

  • Fredrik Lundh at Mar 12, 2002 at 9:53 pm

    Rob Nikander wrote:
    Are there any projects out there that allow you to embed python in HTML
    like PHP? I like the PHP-style of embedding the bits of program in HTML,
    but I'd like to use python...
    start here:

    http://thor.prohosting.com/~pboddie/Python/web_modules.html

    </F>
  • Paul Boddie at Mar 13, 2002 at 12:44 pm
    "Fredrik Lundh" <fredrik at pythonware.com> wrote in message news:<3Nuj8.31472$l93.6215261 at newsb.telia.net>...
    Rob Nikander wrote:
    Are there any projects out there that allow you to embed python in HTML
    like PHP? I like the PHP-style of embedding the bits of program in HTML,
    but I'd like to use python...
    start here:

    http://thor.prohosting.com/~pboddie/Python/web_modules.html
    The new recommended starting place is now here:

    http://www.boddie.org.uk/python/web_frameworks.html

    Take a look at the following page for more information on templates:

    http://webware.sourceforge.net/Papers/Templates/

    Paul
  • Andrew McNamara at Mar 13, 2002 at 2:54 am

    Are there any projects out there that allow you to embed python in HTML
    like PHP? I like the PHP-style of embedding the bits of program in HTML,
    but I'd like to use python...
    Something like:

    <html>
    <?python
    print "<ul>"
    for reptile in ["Crocodile", "Python", "Iguana", "Tortoise"]:
    print "<li> %s </li>" % reptile
    print "</ul>"
    ?>
    </html>
    You may want to consider Albatross:

    http://www.object-craft.com.au/projects/albatross

    Albatross encourages (but doesn't enforce) the separation of presentation
    and logic. You might do something like this in Albatross:

    <ul>
    <al-for iter="reptile" expr='["Crocodile", "Python", "Iguana", "Tortoise"]'>
    <li><al-value expr="reptile.value()" whitespace></li>
    </al-for>
    </ul>

    An example Albatross CGI application that demonstrates this is:

    #!/usr/bin/python

    import albatross

    ctx = albatross.SimpleContext('.')
    ctx.locals.reptiles = ["Crocodile", "Python", "Iguana", "Tortoise"]
    template = ctx.load_template("reptiles.html")
    template.to_html(ctx)

    print "Content-Type: text/html"
    print
    ctx.flush_content()

    And "reptiles.html" would contain:

    <ul>
    <al-for iter="reptile" expr="reptiles">
    <li><al-value expr="reptile.value()" whitespace></li>
    </al-for>
    </ul>

    Albatross also gives you an complete templating language, and client and
    server side sessions. The extensive manual is available online as HTML at:

    http://www.object-craft.com.au/projects/albatross/albatross/

    --
    Andrew McNamara, Senior Developer, Object Craft
    http://www.object-craft.com.au/
  • Dave Cole at Mar 13, 2002 at 12:16 pm

    Are there any projects out there that allow you to embed python in
    HTML like PHP? I like the PHP-style of embedding the bits of
    program in HTML, but I'd like to use python... Something like:

    <html>
    <?python
    print "<ul>"
    for reptile in ["Crocodile", "Python", "Iguana", "Tortoise"]:
    print "<li> %s </li>" % reptile
    print "</ul>"
    ?>
    </html>
    The example Andrew presented is certainly the Albatross way, but you
    could also do things like this with Andrew's improved template parser
    in 0.06 (if you were so inclined):

    - - reptile.html - - - - - - - - - - - - - - - - - - - - - - - - - -
    <html>
    <al-exec expr='
    print "<ul>"
    for reptile in ["Crocodile", "Python", "Iguana", "Tortoise"]:
    print "<li> %s </li>" % reptile
    print "</ul>"
    '>
    </html>
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    The example program adds a write() method to the execution context to
    make it look like a file for the print statement.

    - - reptile.py - - - - - - - - - - - - - - - - - - - - - - - - - - -
    #!/usr/bin/python
    import sys
    import albatross

    class Ctx(albatross.SimpleContext):
    def write(self, data):
    self.write_content(data)

    ctx = Ctx('.')
    ctx.locals.reptiles = ["Crocodile", "Python", "Iguana", "Tortoise"]
    template = ctx.load_template("reptiles.html")

    old_stdout = sys.stdout
    try:
    sys.stdout = ctx
    template.to_html(ctx)
    finally:
    sys.stdout = old_stdout

    print "Content-Type: text/html"
    print
    ctx.flush_content()
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Produces the following output...

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Content-Type: text/html

    <html>
    <ul>
    <li> Crocodile </li>
    <li> Python </li>
    <li> Iguana </li>
    <li> Tortoise </li>
    </ul>
    </html>
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    - Dave
  • Ian Bicking at Mar 19, 2002 at 8:03 pm
    Andrew McNamara <andrewm at object-craft.com.au> wrote in message news:<mailman.1015988122.18668.python-list at python.org>...
    Albatross encourages (but doesn't enforce) the separation of presentation
    and logic. You might do something like this in Albatross:

    <ul>
    <al-for iter="reptile" expr='["Crocodile", "Python", "Iguana", "Tortoise"]'>
    <li><al-value expr="reptile.value()" whitespace></li>
    </al-for>
    </ul>
    Why, oh why, does it use HTML-like syntax? People keep implementing
    templating languages that do this over and over, and it's a bad, bad
    idea. Any moderately complex example of templating will violate the
    rules of HTML/SGML, with things like <img src="<al-value
    expr="something">">, which is horrible to read, will anger WYSIWYG
    editors to no end, and isn't at all necessary.

    All you have to do is use [] instead of <> -- it look about the same,
    will have all the good cognitive associations (how nesting works,
    etc), but is orthogonal to HTML, just like your templating system is
    orthogonal to HTML. I.e., you're templates would look like

    <ul>
    [al-for iter="reptile" expr='["Crocodile", "Python"]']
    <li>[al-value expr="reptile.value()]</li>
    [/al-for]
    </ul>

    This still causes problems with repeating table lines (since they'll
    be [al-for...] text between <table> and <tr>), but it will still be
    much better. And it should be trivial to implement :)

    -- Ian Bicking
  • Andy Gimblett at Mar 20, 2002 at 10:09 am

    On Tue, Mar 19, 2002 at 12:03:46PM -0800, Ian Bicking wrote:

    Why, oh why, does it use HTML-like syntax? People keep implementing
    templating languages that do this over and over, and it's a bad, bad
    idea. Any moderately complex example of templating will violate the
    rules of HTML/SGML, with things like <img src="<al-value
    expr="something">">, which is horrible to read, will anger WYSIWYG
    editors to no end, and isn't at all necessary.
    Yeah, this puts me off Albatross too... I've just started playing
    with Page Templates in Zope, and their approach seems excellent: it's
    all done in _attributes_ without adding any new tags.

    Have a look at this example (from
    http://www.zope.org/Members/peterbe/DTML2ZPT):

    <ul tal:define="sequence python:container.mydb.selectbyname(name='peter')">
    <li tal:repeat="item sequence">
    <span tal:replace="item/surname">surname</span>
    </li>
    </ul>

    Now, that's perfectly valid HTML, most WYSYWIG editors will basically
    ignore the tal: attributes and render a single-element list, but the
    ZPT machinery in Zope will pick that up and render a multi-element
    list in a manner which I think it pretty obvious from looking at the
    source.

    In short, I think it's super-neato. :-)

    Now I need to figure out if it can be used outside of Zope. AFAIK
    there _aren't_ any non-Zope implementations, although the language has
    definitely been designed to be general enough to allow its use
    elsewhere.

    -Andy

    --
    Andy Gimblett - Programmer - Frontier Internet Services Limited
    Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/
    Statements made are at all times subject to Frontier's Terms and
    Conditions of Business, which are available upon request.
  • Paul Rubin at Mar 20, 2002 at 11:45 am

    Andy Gimblett <gimbo at ftech.net> writes:
    Have a look at this example (from
    http://www.zope.org/Members/peterbe/DTML2ZPT):

    <ul tal:define="sequence python:container.mydb.selectbyname(name='peter')">
    <li tal:repeat="item sequence">
    <span tal:replace="item/surname">surname</span>
    </li>
    </ul>

    Now, that's perfectly valid HTML, most WYSYWIG editors will basically
    ignore the tal: attributes and render a single-element list, but the
    ZPT machinery in Zope will pick that up and render a multi-element
    list in a manner which I think it pretty obvious from looking at the
    source.

    In short, I think it's super-neato. :-)
    Geez, I find all this pseudo-HTML horrendous. Why not just embed
    normal looking code in <? ?> tags the way PHP does it? Do WYSIWYG
    editors have a problem with that? If worse comes to worse, embed
    the Python code with the kinds of tags used for Javascript. The
    WYSIWYG editors should be used to Javascript by now.
  • Andy Gimblett at Mar 20, 2002 at 12:06 pm

    On Wed, Mar 20, 2002 at 03:45:09AM -0800, Paul Rubin wrote:

    <ul tal:define="sequence python:container.mydb.selectbyname(name='peter')">
    <li tal:repeat="item sequence">
    <span tal:replace="item/surname">surname</span>
    </li>
    </ul>
    Geez, I find all this pseudo-HTML horrendous. Why not just embed
    It's not pseudo-HTML, it's W3C compliant HTML (is "<?", btw?).

    IMHO it's also better looking than <? ?> tags.

    --
    Andy Gimblett - Programmer - Frontier Internet Services Limited
    Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/
    Statements made are at all times subject to Frontier's Terms and
    Conditions of Business, which are available upon request.
  • Paul Rubin at Mar 20, 2002 at 12:46 pm

    Andy Gimblett <gimbo at ftech.net> writes:
    <ul tal:define="sequence python:container.mydb.selectbyname(name='peter')">
    <li tal:repeat="item sequence">
    <span tal:replace="item/surname">surname</span>
    </li>
    </ul>
    Geez, I find all this pseudo-HTML horrendous. Why not just embed
    It's not pseudo-HTML, it's W3C compliant HTML (is "<?", btw?).
    I don't remember "tal:repeat" as a valid property of any HTML tag
    from the HTML spec. That's why I call it pseudo-HTML.
    IMHO it's also better looking than <? ?> tags.
    The issue isn't the <? ?> which can be replaced by something else if
    you want. It's making code look like HTML properties instead of
    making it look like code.
  • Erno Kuusela at Mar 21, 2002 at 4:26 am
    In article <7xelifcsq3.fsf at ruckus.brouhaha.com>, Paul Rubin
    <phr-n2002a at nightsong.com> writes:

    Andy Gimblett <gimbo at ftech.net> writes:
    It's not pseudo-HTML, it's W3C compliant HTML (is "<?", btw?).
    I don't remember "tal:repeat" as a valid property of any HTML tag
    from the HTML spec. That's why I call it pseudo-HTML.
    The issue isn't the <? ?> which can be replaced by something else if
    you want. It's making code look like HTML properties instead of
    making it look like code.
    i think the idea is to not put code in the templates, and using xhtml + xml
    namespaces. it doesn't make it invalid xhtml, afaik.

    -- erno
  • Magnus Lyckå at Mar 20, 2002 at 1:34 pm

    Andy Gimblett <gimbo at ftech.net> writes:
    <ul tal:define="sequence python:container.mydb.selectbyname(name='peter')">
    <li tal:repeat="item sequence">
    <span tal:replace="item/surname">surname</span>
    </li>
    </ul>

    Paul Rubin wrote:
    Geez, I find all this pseudo-HTML horrendous. Why not just embed
    normal looking code in <? ?> tags the way PHP does it? Do WYSIWYG
    editors have a problem with that? If worse comes to worse, embed
    the Python code with the kinds of tags used for Javascript. The
    WYSIWYG editors should be used to Javascript by now.
    Well Paul, this is actually rather clever, particularly

    where the labour is divided between someone who produces
    layout and text, and someone else who writes the code.

    If someone has written the HTML with just mock-up values where
    there should be data from the application you just add the
    attributes to replace the tag contents with program generated
    data.

    The HTML will display the same. You can look at the file in
    a browser or in deramweaver etc, and you will see the correct
    layout with the mock-up values.

    Run it in your application and you will see real data instead.

    With the PHP approach, the "visual designer" won't be able to

    see what the page will actually look like in his HTML editor.
    No way. He will have to guess, and upload it into the application
    and run it there to see if the visual appearence was the way he
    wanted.

    Sure, the data from the application might look fairly different
    from his mock-up data. In the example above he'll only see one
    list element, and in reality there might be many. It's still
    much closer to WYSIWYG than any other approach I've seen though.


    Even if you are the one and the same, it will probably be simpler

    to get the design right with this approach.
  • Duncan Booth at Mar 20, 2002 at 2:05 pm
    Paul Rubin <phr-n2002a at nightsong.com> wrote in
    news:7xk7s7mpiy.fsf at ruckus.brouhaha.com:
    Geez, I find all this pseudo-HTML horrendous. Why not just embed
    normal looking code in <? ?> tags the way PHP does it? Do WYSIWYG
    editors have a problem with that? If worse comes to worse, embed
    the Python code with the kinds of tags used for Javascript. The
    WYSIWYG editors should be used to Javascript by now.
    I think you are missing the point. With <? ?> or javascript, the remaining
    HTML in the file very often isn't valid HTML. In particular you very often
    get situations where the opening and closing tags don't match. Consider
    with your scheme how you might alter the attributes on the <body> tag while
    leaving exactly one body tag visible for the wysiwyg editor?

    ZPT makes this easy provided (and it is a big provided) the wysiwyg editor
    both preserves and ignores unknown attributes.

    --
    Duncan Booth duncan at rcp.co.uk
    int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
    "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
  • A.M. Kuchling at Mar 20, 2002 at 3:33 pm
    In article <mailman.1016626151.9950.python-list at python.org>,
    Andy Gimblett wrote:
    It's not pseudo-HTML, it's W3C compliant HTML (is "<?", btw?).
    Yes; <? ?> is part of the XML spec, and is intended for embedding
    processing instructions in XML.

    Quixote turns the idea of templating on its head and embeds HTML in
    Python code. Section 4 of
    http://www.amk.ca/python/writing/mx-architecture/ talks about why this
    turns out to be a really good idea.

    --amk (www.amk.ca)
    I'm as truthful, honest, and about as boring as they come.
    -- Mel, in "The Ultimate Foe"
  • Jon Ribbens at Mar 27, 2002 at 11:34 am

    In article <slrna9haud.e6b.akuchlin at ute.mems-exchange.org>, A.M. Kuchling wrote:
    Quixote turns the idea of templating on its head and embeds HTML in
    Python code. Section 4 of
    http://www.amk.ca/python/writing/mx-architecture/ talks about why this
    turns out to be a really good idea.
    ... and 'jonpy' avoids the issue entirely by neither embedding Python
    in HTML or HTML in Python. Its templating system embeds *no code of
    any sort* in the HTML and this turns out to be completely super ;-).
    See http://jonpy.sourceforge.net/wt-examples.html#templatecode for
    examples.

    This is especially useful when you have different people generating
    the HTML and the code (as it almost always the case). The designer is
    much less likely to mangle the 'significant' parts of the HTML files,
    and even if they do, it's a matter of seconds to fix. Additionally,
    when the customer says "actually, we don't like the style of the site,
    we want it changed" and you get sent a whole bunch of new code-less
    HTML files, with a PHP-style code-in-HTML you pretty much have to
    reimplement the entire site from scratch, whereas with this system you
    just add back in the section markers and the code (which was in
    separate files anyway) does not usually need to be changed at all.

    Cheers


    Jon
  • Paul Boddie at Mar 29, 2002 at 2:55 pm
    Jon Ribbens <jon+usenet at unequivocal.co.uk> wrote in message news:[HTML in Python code]
    ... and 'jonpy' avoids the issue entirely by neither embedding Python
    in HTML or HTML in Python. Its templating system embeds *no code of
    any sort* in the HTML and this turns out to be completely super ;-).
    See http://jonpy.sourceforge.net/wt-examples.html#templatecode for
    examples.
    It's actually quite reminiscent of the earliest versions of DTML, in
    fact, where comments are used to mark the structure of the "model" as
    opposed to the special tags which were introduced in DTML later on.
    This is especially useful when you have different people generating
    the HTML and the code (as it almost always the case). The designer is
    much less likely to mangle the 'significant' parts of the HTML files,
    and even if they do, it's a matter of seconds to fix.
    Zope Page Templates takes the other "under the radar" approach, of
    course, using special attributes which HTML editors usually don't want
    to touch. I suppose only testing of what different editors do with
    attributes and comments can determine whether special attributes or
    comments are best to avoid "destructive editing" when HTML files are
    redesigned.

    I agree with Jon that the ability to divide work into separate
    activities of page design and application development is very
    important, especially in situations where designs may change rapidly
    over time. Indeed, any help in partitioning workloads is essential for
    many kinds of applications; otherwise the software developers end up
    not only doing their own work, but also intensively managing the
    changes made by designers, potentially resulting in "workflow
    bottlenecks" around developers while designers wait impatiently for
    the application to take on its new look.
    Additionally, when the customer says "actually, we don't like the style of
    the site, we want it changed" and you get sent a whole bunch of new code-less
    HTML files, with a PHP-style code-in-HTML you pretty much have to
    reimplement the entire site from scratch, whereas with this system you
    just add back in the section markers and the code (which was in
    separate files anyway) does not usually need to be changed at all.
    I think that while some applications probably do need a lot of control
    over their own presentation, demanding a programmatic approach to
    output generation, in many applications once the problem of generating
    output in a maintainable way has been resolved, the most common
    subsequent problem is handling the input from users and finding a way
    to reduce the maintenance on this activity as well. In the Python
    community, there is obviously an intense interest in templating, but I
    haven't seen more than a handful of validation packages, and I can
    imagine that few of them actually integrate satisfactorily with
    template packages.

    Paul
  • Oleg Broytmann at Mar 29, 2002 at 3:07 pm

    On Fri, Mar 29, 2002 at 06:55:54AM -0800, Paul Boddie wrote:
    It's actually quite reminiscent of the earliest versions of DTML, in
    fact, where comments are used to mark the structure of the "model" as
    They are not exactly comments, they are modelled after Apache SSI (which
    are comments, I must admit :)

    Oleg.
    --
    Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru
    Programmers don't die, they just GOSUB without RETURN.
  • Jon Ribbens at Mar 31, 2002 at 1:07 am

    In article <23891c90.0203290655.25bbcab9 at posting.google.com>, Paul Boddie wrote:
    It's actually quite reminiscent of the earliest versions of DTML, in
    fact, where comments are used to mark the structure of the "model" as
    opposed to the special tags which were introduced in DTML later on.
    Why were special tags added? I don't see any need for anything above
    the two concepts of 'replacements' and 'sections' that jonpy provides.

    I think the three interesting concepts in jonpy are:

    * absolute minimum of non-html code in html templates

    * correspondence between html sections and nested classes, e.g.:

    HTML:
    <p>Top level.</p>
    <!--wt:section--><p>$$replacement$$</p><!--wt:/section-->
    <p>Top level.</p>
    Code:
    class main(wt.TemplateCode):
    class section(wt.TemplateCode):
    def replacement(self):
    return "Section."

    * dual file hierarchy for html and code, e.g.:

    DOCUMENT_ROOT/index.html
    DOCUMENT_ROOT/img.jpg
    DOCUMENT_ROOT/thing.html
    DOCUMENT_ROOT/subdir/index.html

    DOCUMENT_ROOT/wt/index.html.py
    DOCUMENT_ROOT/wt/thing.html.py
    DOCUMENT_ROOT/wt/subdir/index.html.py
    Zope Page Templates takes the other "under the radar" approach, of
    course, using special attributes which HTML editors usually don't want
    to touch.
    Presumably bad things still happen if the designer deletes the tag
    itself that the magic attributes are attached to though.
    In the Python community, there is obviously an intense interest in
    templating, but I haven't seen more than a handful of validation
    packages, and I can imagine that few of them actually integrate
    satisfactorily with template packages.
    I'm not sure what you mean here. Can you give an example of what a
    "validation package" might do?

    Cheers


    Jon
  • Paul Boddie at Mar 31, 2002 at 4:20 pm

    I wrote:
    In the Python community, there is obviously an intense interest in
    templating, but I haven't seen more than a handful of validation
    packages, and I can imagine that few of them actually integrate
    satisfactorily with template packages.
    Jon replied:
    I'm not sure what you mean here. Can you give an example of what a
    "validation package" might do?
    The way I see things, when developing Web applications, is as follows.
    First of all, developers need to present some state of the
    application, and this is where template systems first get used. Of
    course, as I noted in my previous response, it depends on the nature
    of the application (and how the development work on the application is
    organised) as to whether you prefer HTML-in-Python or Python-in-HTML
    or some "more neutral" template language.

    If the nature of the user responses to a particular "screen" are of
    more than limited complexity, it becomes tiresome to manually code
    HTML form tags, and this is where certain template solutions provide
    some help to developers. For example, JavaServer Pages provide "custom
    tags" which can be used to substitute commonly-used output into pages
    in a nicer way than "home-made" solutions (since the designers did
    think about the re-use of tags across applications, and there's a
    reasonably powerful object model for tags to plug into).

    The next problem, though, is coordinating the output with the input.
    One can invent a "custom tag" (or corresponding feature in one's
    framework of choice) which emits an HTML "input" field, but where is
    the code that checks the value returned by the user through that
    field, and how can we be sure that such code is validating and
    manipulating the same kind of data as that described by the "input"
    field? For example, I could invent a "custom tag" like this:

    <myapp:specialInput name="someField"/>

    This could result in the following HTML being generated:

    <input name="someField" size="30" type="text">

    The intention might be that the contents of "someField" are in a
    particular format. Moreover, such data may be stored in a database
    system, and we might want to keep the "size" or "length" of a piece of
    data synchronized with the data type used in the database - it's not
    uncommon for such things to evolve as the requirements of an
    application change, but it would be very inconvenient to need to
    change HTML form descriptions, validation code, template system code,
    all in a number of different places.

    Template systems typically don't address these issues, whereas
    stand-alone validation systems address the nature of the input data
    but not how such data is "described" to the browser (and thus to the
    user). A coordinated approach which unifies input, output, and
    validation seems to be the logical next step in any significantly big
    or complex application.

    Paul
  • Jon Ribbens at Apr 1, 2002 at 10:21 pm

    In article <23891c90.0203310820.60696fb1 at posting.google.com>, Paul Boddie wrote:
    Template systems typically don't address these issues, whereas
    stand-alone validation systems address the nature of the input data
    but not how such data is "described" to the browser (and thus to the
    user). A coordinated approach which unifies input, output, and
    validation seems to be the logical next step in any significantly big
    or complex application.
    Ah, I see. I must admit I have never seen a web application where
    the benefits this would provide would outweigh the extra complexities
    it would entail. From an HTML point of view, the only two input
    attributes which could be magically generated are 'size' and
    'maxlength'. 'size' is more dependent on the form design than the
    input requirements, and hence it is not appropriate to base this value
    on the input type, and the benefits of automagically setting maxlength
    would seem to be extremely minor.
  • Paul Boddie at Apr 2, 2002 at 8:47 am
    Jon Ribbens <jon+usenet at unequivocal.co.uk> wrote in message news:<slrnaahnai.i1t.jon+usenet at snowy.squish.net>...
    Ah, I see. I must admit I have never seen a web application where
    the benefits this would provide would outweigh the extra complexities
    it would entail.
    I think it depends a fair amount on the application. I've worked with
    "form-heavy" applications myself, and it's not exactly a secret that
    database-driven applications often have their presentation determined
    by the underlying database schema.
    From an HTML point of view, the only two input attributes which could be
    magically generated are 'size' and 'maxlength'. 'size' is more dependent on
    the form design than the input requirements, and hence it is not appropriate
    to base this value on the input type, and the benefits of automagically
    setting maxlength would seem to be extremely minor.
    Yes, I probably got confused between "length" and "size" - I always
    need to refer to the HTML specification in that case. Still, I
    wouldn't underestimate the benefit of making sure that even such
    simple properties are synchronised at all levels of an application.
    From a coding point of view, I would think the benefits are fairly
    small too. In most applications I can think of, input data is usually
    being looked up from rather than entered into a database. For example,
    if the user enters a username the question is not normally "is this a
    valid username?", but "is this an existing username?", so no input
    validation is required. I guess the common exception is email
    addresses.
    Some common validation cases are numbers, dates and monetary amounts,
    and I've also seen systems which validated measurements. To an extent,
    one can break down complicated fields into collections of simpler
    ones, although some people dislike such interfaces. Nevertheless,
    being able to declaratively associate form fields with the means of
    validation, without the explicit need to code it, could well be
    beneficial, in my opinion.
    The nearest jonpy gets to this sort of thing is MultiForm, a class
    for creating multi-page input forms. It provides a 'check' method
    which you override to validate the input data and produce appropriate
    error messages.
    That's another area where automation gives some notable advantages,
    too.

    Paul
  • Jon Ribbens at Apr 3, 2002 at 1:18 pm

    In article <23891c90.0204020047.4d4ae046 at posting.google.com>, Paul Boddie wrote:
    Some common validation cases are numbers, dates and monetary amounts,
    and I've also seen systems which validated measurements. To an extent,
    one can break down complicated fields into collections of simpler
    ones, although some people dislike such interfaces. Nevertheless,
    being able to declaratively associate form fields with the means of
    validation, without the explicit need to code it, could well be
    beneficial, in my opinion.
    Well, it could be done as follows:

    class EmailInput(GenericInput):
    def __init__(self, val):
    if not re.match(r"[^@]+@[A-Za-z0-9-]+\.[A-Za-z0-9.-]+$", val):
    raise ValueError, "%s is not a valid email address" % `val`
    self.val = val

    def __str__(self):
    return val

    The GenericInput class hierarchy could obviously also have any other
    class variables or methods which you might find helpful to define
    input types.

    In jonpy using multiform you would then simply do:

    ...
    class stage0(wt.multiform.Stage):
    ...
    def update_email(self, val):
    try:
    self.container["email"] = EmailInput(val)
    except ValueError:
    self.errors.append("Sorry, the email address you entered is not valid.")

    ... and there you have it. I don't see how you could get much more
    automated than that, really.

    Cheers


    Jon
  • Dave Cole at Apr 2, 2002 at 4:34 am
    "Paul" == Paul Boddie <paul at boddie.net> writes:
    Paul> The next problem, though, is coordinating the output with the
    Paul> input. One can invent a "custom tag" (or corresponding feature
    Paul> in one's framework of choice) which emits an HTML "input" field,
    Paul> but where is the code that checks the value returned by the user
    Paul> through that field, and how can we be sure that such code is
    Paul> validating and manipulating the same kind of data as that
    Paul> described by the "input" field? For example, I could invent a
    Paul> "custom tag" like this:

    Paul> <myapp:specialInput name="someField"/>

    Paul> This could result in the following HTML being generated:

    Paul> <input name="someField" size="30" type="text">

    Paul> The intention might be that the contents of "someField" are in a
    Paul> particular format. Moreover, such data may be stored in a
    Paul> database system, and we might want to keep the "size" or
    Paul> "length" of a piece of data synchronized with the data type used
    Paul> in the database - it's not uncommon for such things to evolve as
    Paul> the requirements of an application change, but it would be very
    Paul> inconvenient to need to change HTML form descriptions,
    Paul> validation code, template system code, all in a number of
    Paul> different places.

    Paul> Template systems typically don't address these issues, whereas
    Paul> stand-alone validation systems address the nature of the input
    Paul> data but not how such data is "described" to the browser (and
    Paul> thus to the user). A coordinated approach which unifies input,
    Paul> output, and validation seems to be the logical next step in any
    Paul> significantly big or complex application.

    Albatross has features which come close to what you are requesting.
    With a little bit of sweat you could make it do exactly what you are
    talking about.

    The built in behaviour for forms creates a Python list of all input
    fields in a form and then pickles (and MD5 signs) that to a hidden
    field in the form. When the browser request comes back the list is
    restored and used for the basis of merging the browser request into
    the "execution context". What this currently gives you is that any
    field which is not filled in and submitted by the browser will be
    detected and the corresponding variable will be set to None.

    The standard behaviour is performed by a combination of the <al-input>
    tag and the NameRecorderMixin class.

    There are two ways that you could change the current Albatross
    behaviour. You could implement your own special input tag to
    construct your special input tags with a special form recorder, or you
    could subclass one of the Application classes and override the
    validate_request() method.

    1) A custom tag is pretty easy to build - check this out:

    http://www.object-craft.com.au/projects/albatross/albatross/cust-ref.html

    By implementing your own RecorderMixin you could store the field
    type with the name for automatic validation on request merging.

    This is the documentation for the default recorder behaviour as
    implemented by NameRecorderMixin:

    http://www.object-craft.com.au/projects/albatross/albatross/mixin-rec-name.html

    To complete the loop you would then subclass one of the application
    classes which inherit from Application and override the
    merge_request() method which takes fields out of the browser
    request in place them into the execution context.

    http://www.object-craft.com.au/projects/albatross/albatross/pack-app.html

    2) This is the easy but less general option. You could subclass an
    application object and provide a validate_request() method which
    field names with embedded type information (hungarian notation) to
    determine the type of the field. By returning FALSE from
    validate_request() you suppress request processing.

    As part of the field validation in your validate_request() you
    could set error messages which were picked up as part of the form
    display.

    At some stage we are going to start building up a cookbook for
    Albatross. This is a good cookbook example.

    - Dave
  • Robin at Mar 20, 2002 at 7:16 pm
    I'm not at all fond of mixing up HTML and code. For real-world sites
    that are not trivially small, this presents a growing maintenance
    problem.

    Much better, IMO, to keep all of the python code in modules, where it
    belongs, and have an simple syntax for mixing the results of executing
    code in with a web page. That way the HTML people can do their thing,
    and the coders theirs.

    My Wasp templating system does this. Pages look like the following:

    =====

    <?w include:header('Example page') ?>
    <?w execute:banner() ?>

    <p>A sample page using Wasp. HTML where HTML belongs; code where code
    belongs.</p>

    <?w include:footer() ?>

    =====

    Most of the HTML is hidden away in the include files, which enhances
    stylistic conformity. These can be passed parameters for simple
    variable content. Anything more complex requires that one execute a
    function; any output from this is put directly inline.

    Additional tags handle conditional output and macros, but these two
    tags are really all you need.

    There are certainly lots of templating systems out there. Here's mine:
    www.execulink.com/~robin/wasp/readme.html

    -----
    robin

    A rich couple found their ideal pet in a dog that makes e-mail
    programs.
  • Andrew McNamara at Mar 21, 2002 at 11:50 pm

    Albatross encourages (but doesn't enforce) the separation of presentation
    and logic. You might do something like this in Albatross:

    <ul>
    <al-for iter="reptile" expr='["Crocodile", "Python", "Iguana", "Tortoise"]'>
    <li><al-value expr="reptile.value()" whitespace></li>
    </al-for>
    </ul>
    Why, oh why, does it use HTML-like syntax? People keep implementing
    templating languages that do this over and over, and it's a bad, bad
    idea. Any moderately complex example of templating will violate the
    rules of HTML/SGML, with things like <img src="<al-value
    expr="something">">, which is horrible to read, will anger WYSIWYG
    editors to no end, and isn't at all necessary.
    The intention is that Albatross templates be valid XML - while Albatross
    will do the expected thing in the example you give above, it generally
    provides a "better" way, such as:

    <al-img expr="something">
    All you have to do is use [] instead of <> -- it look about the same,
    will have all the good cognitive associations (how nesting works,
    etc), but is orthogonal to HTML, just like your templating system is
    orthogonal to HTML. I.e., you're templates would look like
    But this wouldn't be XML... 8-)

    --
    Andrew McNamara, Senior Developer, Object Craft
    http://www.object-craft.com.au/
  • Ian Bicking at Mar 22, 2002 at 12:17 am

    On Thu, 2002-03-21 at 17:50, Andrew McNamara wrote:
    Albatross encourages (but doesn't enforce) the separation of presentation
    and logic. You might do something like this in Albatross:

    <ul>
    <al-for iter="reptile" expr='["Crocodile", "Python", "Iguana", "Tortoise"]'>
    <li><al-value expr="reptile.value()" whitespace></li>
    </al-for>
    </ul>
    Why, oh why, does it use HTML-like syntax? People keep implementing
    templating languages that do this over and over, and it's a bad, bad
    idea. Any moderately complex example of templating will violate the
    rules of HTML/SGML, with things like <img src="<al-value
    expr="something">">, which is horrible to read, will anger WYSIWYG
    editors to no end, and isn't at all necessary.
    The intention is that Albatross templates be valid XML - while Albatross
    will do the expected thing in the example you give above, it generally
    provides a "better" way, such as:

    <al-img expr="something">
    Do you mean that you have a template tag for every kind of tag for which
    you would want to modify an attribute? That's every single HTML tag --
    IMG is hardly the only one. A dynamic CSS class attribute, for
    instance, or events (onMouseOver, etc), id tags, background colors...
    there's a million possibilities.

    Plus you've got the same problems ZPT has, where it's not really proper
    -- or perhaps even possible -- to dynamically generate CSS or Javascript
    with your language, since they are generally guarded by comments and are
    thus opaque to XML.

    XML just seems so darn *hard*.

    Ian
  • Andrew McNamara at Mar 22, 2002 at 12:37 am

    The intention is that Albatross templates be valid XML - while Albatross
    will do the expected thing in the example you give above, it generally
    provides a "better" way, such as:

    <al-img expr="something">
    Do you mean that you have a template tag for every kind of tag for which
    you would want to modify an attribute? That's every single HTML tag --
    IMG is hardly the only one. A dynamic CSS class attribute, for
    instance, or events (onMouseOver, etc), id tags, background colors...
    there's a million possibilities.
    No, we don't, although we're considering some options (such as abusing
    the XML namespace - for example: <al-img expr:src="something"> - thoughts?

    --
    Andrew McNamara, Senior Developer, Object Craft
    http://www.object-craft.com.au/
  • Ian Bicking at Mar 22, 2002 at 6:45 pm

    On Thu, 2002-03-21 at 18:37, Andrew McNamara wrote:
    The intention is that Albatross templates be valid XML - while Albatross
    will do the expected thing in the example you give above, it generally
    provides a "better" way, such as:

    <al-img expr="something">
    Do you mean that you have a template tag for every kind of tag for which
    you would want to modify an attribute? That's every single HTML tag --
    IMG is hardly the only one. A dynamic CSS class attribute, for
    instance, or events (onMouseOver, etc), id tags, background colors...
    there's a million possibilities.
    No, we don't, although we're considering some options (such as abusing
    the XML namespace - for example: <al-img expr:src="something"> - thoughts?
    I assume you are thinking that any al-* tag that isn't otherwise defined
    would turn into a plain tag? So you'd do
    <al-table expr:bgcolor="something"> ? Seems kind of unXMLish as well.

    You could do something like:

    <al-attr name="bgcolor" expr="something"><table>...</table></al-attr>

    That's very long, and you have to parse the entire document (I'm not
    sure if you are doing that now). Actually, it looks horrible and if I
    was using such a language I would hate you. Maybe:

    <al-attr name="bgcolor" expr="something"/><table>...</table>

    I'm not sure if that's quite kosher or not... I guess there's nothing
    really wrong about it, it just doesn't feel much like XML -- something
    about binding two elements together when they are only next to each
    other, not contained, seems odd. And it still isn't pretty.

    Of course there's the ZPT approach, which isn't bad, but then you might
    as well use ZPT. But I guess there's no reason you can't use something
    like ZPT just for changing attributes, like:

    <table al:bgcolor="something">

    And then skip all the looping and such that ZPT does with attributes.
    You'd still have the worry about generating CSS and Javascript, though.
    Dave mentioned performance... doing a full XML parse is
    performance-intensive, but you could fake it for this particular case --
    you don't need to find the </table> tag or anything, you could probably
    do it just with regexes.


    I still think it's so much easier to use [], and make the system
    orthogonal to XML or any other medium you might want to generate. I
    think it actually gives you better tool support as well.

    Ian
  • Dave Cole at Mar 23, 2002 at 3:50 am

    "Ian" == Ian Bicking <ianb at colorstudy.com> writes:
    No, we don't, although we're considering some options (such as
    abusing the XML namespace - for example: <al-img
    expr:src="something"> - thoughts?
    Ian> I assume you are thinking that any al-* tag that isn't otherwise
    Ian> defined would turn into a plain tag? So you'd do <al-table
    Ian> expr:bgcolor="something"> ? Seems kind of unXMLish as well.

    Ian> You could do something like:

    Ian> <al-attr name="bgcolor" expr="something"><table>...</table></al-attr>

    Ian> That's very long, and you have to parse the entire document (I'm
    Ian> not sure if you are doing that now). Actually, it looks horrible
    Ian> and if I was using such a language I would hate you. Maybe:

    Ian> <al-attr name="bgcolor" expr="something"/><table>...</table>

    Ian> I'm not sure if that's quite kosher or not... I guess there's
    Ian> nothing really wrong about it, it just doesn't feel much like XML
    Ian> -- something about binding two elements together when they are
    Ian> only next to each other, not contained, seems odd. And it still
    Ian> isn't pretty.

    I had a crazy idea a while ago which would stop us having to do the
    thing that you pointed out:

    <td bgcolor="<al-value expr="bgcolor">">

    The idea, which I am still not sold on, goes a bit like this:

    <al-attr id="fancytable" name="bgcolor" value="pink">

    <al-td id="fancytable">

    The first bit of template attaches an attribute name and value to an
    attribute id. This attribute association would be stored in the
    execution context so you could define values in your Python code if
    you wished. Albatross tags would then retrieve values from the
    association by using the same id attribute.

    This would allow Albatross templates to be much more flexible.
    Consider the <al-for> tag. At the moment you have to staticly decide
    the name of the iterator. This means that you cannot reuse a bunch of
    template code which paginated a sequence in a macro since you would be
    using the same iterator for multiple sequences. With the above you
    could do this (not really a good example):

    <al-macro name="list">
    <al-for id="list">
    blah blah <al-usearg>
    </al-for>
    </al-macro>

    <al-attr id="list" name="iter" value="i">
    <al-attr id="list" name="pagesize" value="10">
    <al-expand name="list">spam</al-expand>

    <al-attr id="list" name="iter" value="j">
    <al-attr id="list" name="pagesize" value="15">
    <al-expand name="list">eggs</al-expand>

    The functionality would require an extensive reworking of the tags
    code. There are some advantages to the approach but I am still a
    bit concerned that it is too obscure.

    Andrew has since mentioned changing the way that the we name the
    Albatross processed attributes to make them more functional and
    consistent. Something like:

    <al-input name="field"> <!-- normal HTML -->
    <al-input name.expr="expr"> <!-- name from eval'ed expr -->

    I am starting to think that this would be an excellent idea.

    Ian> Of course there's the ZPT approach, which isn't bad, but then you
    Ian> might as well use ZPT. But I guess there's no reason you can't
    Ian> use something like ZPT just for changing attributes, like:

    Ian> <table al:bgcolor="something">

    I have a few concerns about ZPT.

    You are forced to embed programming logic which is used to dynamically
    alter the presentation of the interface directly inside the
    presentation elements. I have a feeling that this makes the whole
    template unduly fragile and resistant to change.

    The idea that an HTML developer who does not understand ZPT will be
    able to ignore the ZPT attributes and just change the interface in
    isolation is a fantasy. The ZPT attributes define an executable
    program - their correct placement is critical to the functioning of
    the template. Note that the same is true of Albatross tags, but you
    can change the HTML in isolation to the Albatross tags.

    Ian> And then skip all the looping and such that ZPT does with
    Ian> attributes. You'd still have the worry about generating CSS and
    Ian> Javascript, though. Dave mentioned performance... doing a full
    Ian> XML parse is performance-intensive, but you could fake it for
    Ian> this particular case -- you don't need to find the </table> tag
    Ian> or anything, you could probably do it just with regexes.

    Ian> I still think it's so much easier to use [], and make the system
    Ian> orthogonal to XML or any other medium you might want to generate.
    Ian> I think it actually gives you better tool support as well.

    The [] characters do not make things much more pretty IMO. You sill
    end up with things like this:

    <td bgcolor="[al-value expr="bgcolor"]">

    Something which would dynamically assign attributes to tags would look
    much nicer.

    <td bgcolor.expr="bgcolor"> <!-- semi ZPT to modify one attr -->
    <al-td id="blah"> <!-- attach arbitrary attrs -->
    <al-td id.expr="yow"> <!-- combination of both -->

    The whole goal of Albatross is to place as little logic as is possible
    in the templating system. All real programming should be in Python.
    Having said that, I recognise that the templating system is far from
    perfect. If it was an easy problem, we would all be using the same
    templating system which was a standard Python module.

    - Dave
  • Ian Bicking at Mar 24, 2002 at 8:00 pm

    On Fri, 2002-03-22 at 21:50, Dave Cole wrote:
    I had a crazy idea a while ago which would stop us having to do the
    thing that you pointed out:

    <td bgcolor="<al-value expr="bgcolor">">

    The idea, which I am still not sold on, goes a bit like this:

    <al-attr id="fancytable" name="bgcolor" value="pink">

    <al-td id="fancytable">

    The first bit of template attaches an attribute name and value to an
    attribute id. This attribute association would be stored in the
    execution context so you could define values in your Python code if
    you wished. Albatross tags would then retrieve values from the
    association by using the same id attribute.

    This would allow Albatross templates to be much more flexible.
    Consider the <al-for> tag. At the moment you have to staticly decide
    the name of the iterator. This means that you cannot reuse a bunch of
    template code which paginated a sequence in a macro since you would be
    using the same iterator for multiple sequences. With the above you
    could do this (not really a good example):

    <al-macro name="list">
    <al-for id="list">
    blah blah <al-usearg>
    </al-for>
    </al-macro>

    <al-attr id="list" name="iter" value="i">
    <al-attr id="list" name="pagesize" value="10">
    <al-expand name="list">spam</al-expand>

    <al-attr id="list" name="iter" value="j">
    <al-attr id="list" name="pagesize" value="15">
    <al-expand name="list">eggs</al-expand>

    The functionality would require an extensive reworking of the tags
    code. There are some advantages to the approach but I am still a
    bit concerned that it is too obscure.
    For this problem, I think the solution is in the interpreter -- your
    macros are just hard to work with (from what I can see), because they
    are dynamically scoped and being used in lieu of real functions. It's
    not a syntax issue.
    Andrew has since mentioned changing the way that the we name the
    Albatross processed attributes to make them more functional and
    consistent. Something like:

    <al-input name="field"> <!-- normal HTML -->
    <al-input name.expr="expr"> <!-- name from eval'ed expr -->

    I am starting to think that this would be an excellent idea.

    Ian> Of course there's the ZPT approach, which isn't bad, but then you
    Ian> might as well use ZPT. But I guess there's no reason you can't
    Ian> use something like ZPT just for changing attributes, like:

    Ian> <table al:bgcolor="something">

    I have a few concerns about ZPT.

    You are forced to embed programming logic which is used to dynamically
    alter the presentation of the interface directly inside the
    presentation elements. I have a feeling that this makes the whole
    template unduly fragile and resistant to change.

    The idea that an HTML developer who does not understand ZPT will be
    able to ignore the ZPT attributes and just change the interface in
    isolation is a fantasy. The ZPT attributes define an executable
    program - their correct placement is critical to the functioning of
    the template. Note that the same is true of Albatross tags, but you
    can change the HTML in isolation to the Albatross tags.
    I'm not sold on all the benefits of ZPT either, but I think it's a
    natural fit for the particular case of replacing an attribute value. To
    me, <td al:bgcolor="something dynamic"> reads pretty well, and should
    make some intuitive sense even if you don't understand the scripting
    itself. All attributes are kind of hidden, and the dynamic statement is
    no more hidden than the thing it is replacing.

    Also, you're left with a mostly-intact tag -- al-td isn't an HTML tag,
    and software that understands HTML won't understand that tag. That
    means you can't preview the unrendered code in a browser and you can't
    let a WYSIWYG editor touch it.

    Ian
  • Dave Cole at Mar 25, 2002 at 2:09 pm

    For this problem, I think the solution is in the interpreter -- your
    macros are just hard to work with (from what I can see), because
    they are dynamically scoped and being used in lieu of real
    functions. It's not a syntax issue.
    I would really like it if you could explain a little further.

    The macros do sort of work like functions in that they pass arbitrary
    template content to the macro for substitution at the location
    specified by the macro.

    I tried to work out a simple way in which values from the execution
    context namespace could be passed as arguments but couldn't see how to
    do it in a nice fashion
    I'm not sold on all the benefits of ZPT either, but I think it's a
    natural fit for the particular case of replacing an attribute value.
    To me, <td al:bgcolor="something dynamic"> reads pretty well, and
    should make some intuitive sense even if you don't understand the
    scripting itself. All attributes are kind of hidden, and the
    dynamic statement is no more hidden than the thing it is replacing.
    I agree. My biggest problem with ZPT was the control flow.
    Also, you're left with a mostly-intact tag -- al-td isn't an HTML
    tag, and software that understands HTML won't understand that tag.
    That means you can't preview the unrendered code in a browser and
    you can't let a WYSIWYG editor touch it.
    The reason for the al- prefix is to allow the regex parser to
    recognise the tag in amongst the plain HTML tags.

    - Dave
  • Ian Bicking at Mar 25, 2002 at 3:11 pm

    On Mon, 2002-03-25 at 08:09, Dave Cole wrote:
    For this problem, I think the solution is in the interpreter -- your
    macros are just hard to work with (from what I can see), because
    they are dynamically scoped and being used in lieu of real
    functions. It's not a syntax issue.
    I would really like it if you could explain a little further.

    The macros do sort of work like functions in that they pass arbitrary
    template content to the macro for substitution at the location
    specified by the macro.

    I tried to work out a simple way in which values from the execution
    context namespace could be passed as arguments but couldn't see how to
    do it in a nice fashion
    Well, you might be able to help the situation some if you create a new
    scope for the macro, and have something like dtml-let -- that way you
    could do stuff like. That way variable assignments inside your macro
    will pass out of scope when the macro finishes, and at least not
    overwrite things in the main scope. You can use some form of let to
    manipulate the namespace when it doesn't match what the macro expects.
    This is what DTML does, and I assume ZPT uses the same mechanisms (it
    only seems to be a change of syntax).

    I don't like this at all, though, as there's all sorts of problems that
    pop up when you start abstracting things more deeply. Also, I think
    macros are very important, and keeping them python-like is a very nice.
    Then you can define, inside a single template, not only the full page
    style, but the style of components of the page. For instance, I create
    pages that create headers with lists underneath them, all entirely
    dynamic. If the template can define what a header and what a list
    should look like, then I have much more power over the look of the page.

    I'd pass arguments like:

    <al-somemacro arg1="value1" arg2="value2">

    This seems pretty straight-forward, and also maps directly to keyword
    arguments. You could add the syntax:

    <al-somemacro arg1 arg2="value2">

    (which isn't XML, but so it goes), which would equivalent to
    <al-somemacro arg1="arg1" arg2="value2"> -- basically saying which parts
    of the namespace to pass in. It should also be fairly easy to create
    Python functions that do the same thing as the macro.

    Some people will still want to pass in entire namespaces... you could
    use inclusion instead of macros in that case, or make another form of
    macros. You could also make another form of setting variables, that
    sets them globally (perhaps as constants) -- this is much cleaner than
    making every passing variable and loop global.

    Ian
  • Dave Cole at Mar 26, 2002 at 10:16 am
    "Ian" == Ian Bicking <ianb at colorstudy.com> writes:
    Ian> Well, you might be able to help the situation some if you create
    Ian> a new scope for the macro, and have something like dtml-let --
    Ian> that way you could do stuff like. That way variable assignments
    Ian> inside your macro will pass out of scope when the macro finishes,
    Ian> and at least not overwrite things in the main scope.

    That seems reasonable. A simple way to do that would be use a special
    tag to enclose the fragment of template which you wanted to be in a
    local scope.

    Ian> You can use some form of let to manipulate the namespace when it
    Ian> doesn't match what the macro expects. This is what DTML does,
    Ian> and I assume ZPT uses the same mechanisms (it only seems to be a
    Ian> change of syntax).

    Ian> I don't like this at all, though, as there's all sorts of
    Ian> problems that pop up when you start abstracting things more
    Ian> deeply. Also, I think macros are very important, and keeping
    Ian> them python-like is a very nice. Then you can define, inside a
    Ian> single template, not only the full page style, but the style of
    Ian> components of the page. For instance, I create pages that create
    Ian> headers with lists underneath them, all entirely dynamic. If the
    Ian> template can define what a header and what a list should look
    Ian> like, then I have much more power over the look of the page.

    Ian> I'd pass arguments like:

    Ian> <al-somemacro arg1="value1" arg2="value2">

    Ian> This seems pretty straight-forward, and also maps directly to
    Ian> keyword arguments. You could add the syntax:

    Ian> <al-somemacro arg1 arg2="value2">

    Albatross macros are a little bit more interesting and useful. In one
    of the samples (the sybase browser) there is a macro for drawing a box
    around enclosed content. The HTML for doing a box is a bit nasty and
    non-obvious. This is the macro:

    <al-macro name="box">
    <table border="0" cellpadding="1" cellspacing="1" bgcolor="black" width="97%">
    <tr><td>
    <table width="100%" border="0" cellspacing="1" cellpadding="2">
    <tr><td bgcolor="white"><al-usearg></td></tr>
    </table>
    </td></tr>
    </table>
    </al-macro>

    The interesting thing to note is the <al-usearg> tag. This is where
    content passed to the macro will be placed. To enclose anything in a
    box all you need to do is this:

    <al-expand name="box">
    Draw a box around me!
    </al-expand>

    This is what happens when you combine the two things:
    from albatross import SimpleContext, Template
    ctx = SimpleContext('.')
    t = ctx.load_template('macros.html')
    t.to_html(ctx)
    t = Template(ctx, '', '''<al-expand name="box">
    ... Draw a box around me!
    ... </al-expand>
    ... ''')
    t.to_html(ctx)
    ctx.flush_content()
    <table border="0" cellpadding="1" cellspacing="1" bgcolor="black" width="97%">
    <tr><td>
    <table width="100%" border="0" cellspacing="1" cellpadding="2">
    <tr><td bgcolor="white">Draw a box around me!
    </td></tr>
    </table>
    </td></tr>
    </table>

    You can nest macros if you like:
    t = Template(ctx, '', '''<al-expand name="box">
    ... <al-expand name="box">
    ... Draw two boxes
    ... </al-expand>
    ... </al-expand>
    ... ''')
    t.to_html(ctx)
    ctx.flush_content()
    <table border="0" cellpadding="1" cellspacing="1" bgcolor="black" width="97%">
    <tr><td>
    <table width="100%" border="0" cellspacing="1" cellpadding="2">
    <tr><td bgcolor="white"><table border="0" cellpadding="1" cellspacing="1" bgcolor="black" width="97%">
    <tr><td>
    <table width="100%" border="0" cellspacing="1" cellpadding="2">
    <tr><td bgcolor="white">Draw two boxes
    </td></tr>
    </table>
    </td></tr>
    </table>
    </td></tr>
    </table>
    </td></tr>
    </table>

    There are lots of interesting things you can do with the macros. The
    above example used a single argument macro. You can pass multiple
    arguments simply by naming them. The Albatross manual goes into quite
    a bit more detail.

    Ian> It should also be fairly easy to create Python functions that do
    Ian> the same thing as the macro.

    It is quite easy. That would defeat the effort to separate the
    presentation and implementation though.

    Ian> Some people will still want to pass in entire namespaces... you
    Ian> could use inclusion instead of macros in that case, or make
    Ian> another form of macros. You could also make another form of
    Ian> setting variables, that sets them globally (perhaps as constants)
    Ian> -- this is much cleaner than making every passing variable and
    Ian> loop global.

    I agree - there are lots of things that could be done. Coming up with
    some "simple" things which can be used for multiple purposes is the
    challenge. It is only by having our assumptions challenged that we
    will be able to improve what we currently have. Your constructive
    criticism is making me revisit some of the early decisions and look
    at them in a new light.

    - Dave
  • Duncan Booth at Mar 25, 2002 at 10:03 am
    Dave Cole <djc at object-craft.com.au> wrote in
    news:mailman.1016855556.16177.python-list at python.org:
    You are forced to embed programming logic which is used to dynamically
    alter the presentation of the interface directly inside the
    presentation elements. I have a feeling that this makes the whole
    template unduly fragile and resistant to change.
    I would have said you are forced to remove almost all programming logic
    from the template entirely and wrap it up in a separate script. All that is
    left in the template is the display logic.
    The idea that an HTML developer who does not understand ZPT will be
    able to ignore the ZPT attributes and just change the interface in
    isolation is a fantasy. The ZPT attributes define an executable
    program - their correct placement is critical to the functioning of
    the template. Note that the same is true of Albatross tags, but you
    can change the HTML in isolation to the Albatross tags.
    I agree with you here up to a point. I would break down the roles into html
    developer who needs to know some ZPT, presentation developer who just needs
    to know what not to touch, and content developer who just needs to know
    which parts of the page require content.

    You can even edit ZPT using Microsoft Frontpage, and mostly things don't
    break. If someone is simply adding content to a specified cell in a table,
    then they can edit happily within that cell. It would be nice though if the
    HTML editor could somehow be told to make the rest of the template
    readonly.

    I think that until I actually used ZPT, it wasn't obvious just how good a
    job it does of separating the logic, the presentation, and the content. In
    particular the CMF skins help a lot.

    --
    Duncan Booth duncan at rcp.co.uk
    int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
    "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
  • Gerhard Häring at Mar 25, 2002 at 12:38 pm

    In article <Xns91DC65AB692BBduncanrcpcouk at 127.0.0.1>, Duncan Booth wrote:
    Microsoft Frontpage Ayee!!
    It would be nice though if the HTML editor could somehow be told to make the
    rest of the template readonly.
    Dreamweaver can do that.

    Gerhard
  • Dave Cole at Mar 25, 2002 at 1:45 pm
    "Duncan" == Duncan Booth <duncan at NOSPAMrcp.co.uk> writes:
    Duncan> Dave Cole <djc at object-craft.com.au> wrote in
    Duncan> news:mailman.1016855556.16177.python-list at python.org:
    You are forced to embed programming logic which is used to
    dynamically alter the presentation of the interface directly inside
    the presentation elements. I have a feeling that this makes the
    whole template unduly fragile and resistant to change.
    Duncan> I would have said you are forced to remove almost all
    Duncan> programming logic from the template entirely and wrap it up in
    Duncan> a separate script. All that is left in the template is the
    Duncan> display logic.

    That is the best way to go IMO. ZPT seems fine to me except in the
    coarser aspects of template programming. Control flow in particular
    just does not look right to me.
    The idea that an HTML developer who does not understand ZPT will be
    able to ignore the ZPT attributes and just change the interface in
    isolation is a fantasy. The ZPT attributes define an executable
    program - their correct placement is critical to the functioning of
    the template. Note that the same is true of Albatross tags, but
    you can change the HTML in isolation to the Albatross tags.
    Duncan> I agree with you here up to a point. I would break down the
    Duncan> roles into html developer who needs to know some ZPT,
    Duncan> presentation developer who just needs to know what not to
    Duncan> touch, and content developer who just needs to know which
    Duncan> parts of the page require content.

    Are you suggesting that there are three different people would work on
    the same template file?

    IMO there would be some sort of graphic design done which may not
    necessarily produce useful HTML - that design would be taken by the
    content developer who would then build the template.

    Duncan> You can even edit ZPT using Microsoft Frontpage, and mostly
    Duncan> things don't break. If someone is simply adding content to a
    Duncan> specified cell in a table, then they can edit happily within
    Duncan> that cell. It would be nice though if the HTML editor could
    Duncan> somehow be told to make the rest of the template readonly.

    I expect that most HTML editors are pretty good when they encounter
    stuff that they don't understand.

    Duncan> I think that until I actually used ZPT, it wasn't obvious just
    Duncan> how good a job it does of separating the logic, the
    Duncan> presentation, and the content.

    You are talking my language there. One of the things which makes me
    dislike PHP is that there is little effort to perform separation.
    Sort of what you would expect from a perl for web pages.

    Duncan> In particular the CMF skins help a lot.

    I haven't looked at CMF skins.

    - Dave
  • Duncan Booth at Mar 25, 2002 at 2:38 pm
    Dave Cole <djc at object-craft.com.au> wrote in
    news:m3663k69rr.fsf at ferret.object-craft.com.au:
    Duncan> I agree with you here up to a point. I would break down the
    Duncan> roles into html developer who needs to know some ZPT,
    Duncan> presentation developer who just needs to know what not to
    Duncan> touch, and content developer who just needs to know which
    Duncan> parts of the page require content.

    Are you suggesting that there are three different people would work on
    the same template file?
    IMO there would be some sort of graphic design done which may not
    necessarily produce useful HTML - that design would be taken by the
    content developer who would then build the template.
    You have someone who does the graphical design, not necessarily in HTML.
    You have someone who converts that into a template (hopefully only one) for
    the entire site. Then there is someone who does the logic for querying
    databases etc. Then there is someone who updates the actual information
    that goes on the pages. Some of these jobs will be done by the same person,
    but say I want to add a new press release onto my site, then I don't want
    whoever does that to need to know HTML.

    I know of one company (Jamkit) near me that uses Zope+CMF to produce
    websites for businesses and charities. They produce the page layout from
    the information given them by the graphical designers, and I guess the
    logic is much the same for most of the sites. I believe they also set up
    the initial content, but after that the customers can edit their own pages,
    and even add new pages or move them around within the site structure.

    The critically important step in this is separating the content from the
    presentation.
    Duncan> In particular the CMF skins help a lot.

    I haven't looked at CMF skins.
    Basically you have a set of folders containing templates. Each template
    builds on the other templates, but the folders are searched in order for
    each template. So for example a form might be defined in news_edit_form in
    the folder zpt_generic, but that calls main_template. main_template is also
    defined in zpt_generic, but if I add a mysite folder before zpt_generic in
    the skin then main_template from mysite would be used instead. So simply
    adding a new main_template instantly changes the appearance of every other
    template in the system.

    The presence of the skin folders is invisible to the templates, which are
    written as though all of the templates were in the current folder.

    You can define several skins, so for example you might have another skin
    which has a 'printable' folder early in its search containing a simplified
    main_template for formatting printable pages.

    For one site I have been playing with recently I have a folder 'ieeditor'
    which defines a wysiwyg editor for IE and changes a couple of the other
    templates to use it. The end user can choose between the plain html forms
    or the fancy (but slower) HTML editor by changing skins. (The end user
    never sees the skin folders, only a choice of skins).

    Python scripts also live in skin folders, so again you can customise
    behaviour by changing the scripts in an earlier folder without having to
    change the original.

    --
    Duncan Booth duncan at rcp.co.uk
    int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
    "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
  • Kevin Dahlhausen at Mar 26, 2002 at 3:02 pm
    Haven't seen anyone mention Cheetah over at
    http://www.cheetahtemplate.org/ :

    <HTML>
    <HEAD><TITLE>$title</TITLE></HEAD>
    <BODY>

    <TABLE>
    #for $client in $clients
    <TR>
    <TD>$client.surname, $client.firstname</TD>
    <TD><A HREF="mailto:$client.email">$client.email</A></TD>
    </TR>
    #end for
    </TABLE>

    </BODY>
    </HTML>


    Graphical designers can graphically design w/some idea of what it will
    look like.

    WYSIWYG editors will not vomit or ignore.

    It requires minimal overhead re. typing extra characters - follows the
    One True Python Way.

    And it supports neato oo constructs such as template inheritance.
  • Dave Cole at Mar 22, 2002 at 7:31 am

    "Ian" == Ian Bicking <ianb at colorstudy.com> writes:
    The intention is that Albatross templates be valid XML - while
    Albatross will do the expected thing in the example you give above,
    it generally provides a "better" way, such as:

    <al-img expr="something">
    Ian> Do you mean that you have a template tag for every kind of tag
    Ian> for which you would want to modify an attribute? That's every
    Ian> single HTML tag -- IMG is hardly the only one. A dynamic CSS
    Ian> class attribute, for instance, or events (onMouseOver, etc), id
    Ian> tags, background colors... there's a million possibilities.

    I think I can see your point. If I knew the perfect solution I would
    have tried implementing that.

    Ian> Plus you've got the same problems ZPT has, where it's not really
    Ian> proper -- or perhaps even possible -- to dynamically generate CSS
    Ian> or Javascript with your language, since they are generally
    Ian> guarded by comments and are thus opaque to XML.

    Ian> XML just seems so darn *hard*.

    I tried doing the ZPT thing - it made the template loading run like a
    slug on valium. You end up with at least one object for every tag and
    every attribute. With the Albatross templates you only end up with
    objects for the Albatross tags and attributes. As machines get faster
    this will not be such an issue.

    - Dave
  • Jim Abrams at Mar 22, 2002 at 8:54 pm
    "Rob Nikander" <nikander at nc.rr.com> wrote in news:Tjtj8.48802$3O2.18198075
    @typhoon.southeast.rr.com:
    Are there any projects out there that allow you to embed python in HTML
    like PHP? I like the PHP-style of embedding the bits of program in HTML,
    but I'd like to use python...
    Something like:

    <html>
    <?python
    print "<ul>"
    for reptile in ["Crocodile", "Python", "Iguana", "Tortoise"]:
    print "<li> %s </li>" % reptile
    print "</ul>"
    ?>
    </html>

    While mentioning M$ is this thread might get me lynched I still feel the
    need to mention (esp since I'm forced to live in a M$ shop) Python in ASP.
    I find it very attractive to be able to do

    <%
    print >> _out, "<ul>"
    for reptile in ["Crocodile", "Python", "Iguana", "Tortoise"]:
    print >> _out, "<li> %s </li>" % reptile
    print >> _out, "</ul>"
    %>

    or even

    <%
    import HTMLgen
    print >> _out, UL(["Crocodile", "Python", "Iguana", "Tortoise"])
    %>

    adding another jelly bean to the shring to MH ly 'yrs

    -Jim

Related Discussions

People

Translate

site design / logo © 2022 Grokbase