[mod_python] supporting modular mod_python extensions vs."folding" mod_psp

> Dave,

> > > <al-for iter="name" expr="keys">
> > >     <tr>
> > >          <td><al-value expr="name.value()"></td>
> > >          <td><al-value expr="environ[name.value()]"></td>
> > >     <tr>
> > > </al-for>
> > > 
> > > This is not Python. Nor is it HTML.
> > 
> > That is true.  If you restrict yourself to Python and HTML 
> > you are forced to do something like this:
> > 
> > for name in keys:
> >     print '<tr>'
> >     print '  <td>%s</td>' % name
> >     print '  <td>%s</td>' % environ[name]
> >     print '<tr>'

[snip]

> > The introduction of a mechanism (or third "language") that 
> > allows and/or imposes a clear interface between the 
> > presentation and implementation increases the ability to 
> > change one without major impact on the other.  This is a huge 
> > win for applications that will change over time.

> I don't agree with you that banning a 3rd party language implies
> that you're stuck with the horrible
> 
> <%
> 	long and tedious python fragment here
> %>
> 
> style of coding.

You are of course correct.  The <% python code %> construct just makes
it a lot easier to place application code in the wrong place.  That is
not really a criticism of the mechanism, it is a criticism of people
who do that.

Mind you, I could argue that while you have not introduced a third
language, you have introduced a new mechanism.  That was part of the
point I was trying to make.  You need either a new language or a
special mechanism.

> Draco tries to solve this problem in a different way, by still using
> only Python as the scripting language. This works by dividing your
> code in a functional part and a formatting part. The function part
> is put in a so-called handler, which resides in a separate file (1
> per directory).  The functional code execute the user request and
> puts all the results in a dictionary dubbed the interface. This
> almost always reduces your formatting code to something like this:
>  
> <%
>     for tr in rows:
>         print """
>             html formatted string
>              """ % tr
> %>

How is the application namespace made available to the templating?

> The rows variable is set in the handler and contains completely
> processed and ready to print data.
> 
> Using a special notation:
> 
> <%
>     for tr in rows:
>         print """%%>
>             html formatted string
>              <%%""" % tr
> %>

Very sneaky.  I like it.

> The premise on which I've built Draco is that you can't elimiate all
> code from the template, but you can minimize it. A possible solution
> is to use a different templating language but IMHO this just adds
> complexity because you now have two languages (plus html) instead of
> one. Because Python is just as easy to learn as any old templating
> language I don't see how this helps. Maybe at first Python code is a
> bit scary but this should pass quickly.

No argument here.

I have toyed with the idea of experimenting with different templating
mechanisms in Albatross.  The templating is only part of the problem
that Albatross is trying to address.

- Dave

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