[albatross-users] Re: Python embedded like PHP

[Dave Cole]

>>>>> "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

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