[albatross-users] Re: Python embedded like PHP

[Ian Bicking]

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