Web templating/db tool with best designer/coder separation?
Bengt Richter
which do you consider to be the tool(s) to beat, and what would
the killer improvement(s) be? TIA.
Regards,
Bengt Richter
Jon Ribbens
> E.g., if you were hoping for an improvement over current practice,
> which do you consider to be the tool(s) to beat, and what would
> the killer improvement(s) be? TIA.
Take a look at http://jonpy.sourceforge.net/ . It almost completely
separates code and HTML so that the designer and the coder do not
interfere with each other.
Tim Churches
>
> E.g., if you were hoping for an improvement over current practice,
> which do you consider to be the tool(s) to beat, and what would
> the killer improvement(s) be? TIA.
Albatross by Object Craft (see http://www.object-craft.com.au ) does
an excellent job of separating the presentation layer from the
underlying
logic - my understanding is that such separation was one of its main
design goals. However, it does not take a pedantic position on this - it
still allows Python code to be embedded in HTML templates - such
practice
is discouraged, but Albatross provides mechanisms to allow you to do it
if you insist. But more usefully, Albatross provides tags which allow
conditional processing (if-elif-else) and most usefully, iteration, to
be
placed in the HTML template. So your Python business logic code can
assemble
a Python sequence of, say, database query results, but it is the HTML
template
which iterates through that list to create the final HTML which is sent
to the
user's browser. Such a feature is essential, because otherwise the
business logic
Python code ends up needing to creating HTML output itself, which is
then merely
substituted into the HTMl template. Thus, the Albatross model is really
more like:
"all HTML-related stuff, including conditional processing and iteration,
is looked
after in the HTML templates, and all business logic stuff, divorced from
the manner
in which it will be presented, is handled by Python modules." Of course,
this is
just the well-known model-view-controller approach, but Albatross
implements this
very nicely, IMO.
See
http://www.object-craft.com.au/projects/albatross/albatross/fig-presimpexec.html
for more information about this (and to get an idea of the depth of the
Albatross
documentation).
I suspect that the Object Craft guys would welcome help with further
development of
Albatross. What the world really needs are more Pythonic Web
applications, rather
than more Pythonic Web application frameworks.
Tim C
Ian Bicking
> E.g., if you were hoping for an improvement over current practice,
> which do you consider to be the tool(s) to beat, and what would
> the killer improvement(s) be? TIA.
I think Cheetah's methods (#def) are important to real separation of
design (like MVC) -- which isn't quite the same thing as separation of
skills (like designer/coder). Your template is an object (where you
have control of inheritance), and you can define methods for that object
inside your template.
A template should be more expressive than a primitive programming
language -- it should be able to describe how you do something more than
just how to write a page. For instance, how to write a header, or how
to write a list. The whole inheritance thing is pretty nice, too --
inheritance maps really well to sets of templates.
Like other templating systems that compile to Python code, it would do
well to give better error messages. The alternative of interpretation
gives good error messages, but doesn't give good performance.
The NameMapper in Cheetah is also spiffy (in terms of simple syntax, and
easy Python integration), but it's picky and a bit fuzzy in terms of
semantics. Something better defined would be nice.
NameMapper is a way of changing an expression like $a.b.c.d.e into
a.b().c['d'].e (at runtime, of course, because it depends on the types
of the objects). It's great for adding objects and dictionaries to the
template's namespace, without burdening the non-programmer with notions
of type.
Ian
Dave Cole
Tim> Bengt Richter wrote:
>> E.g., if you were hoping for an improvement over current practice,
>> which do you consider to be the tool(s) to beat, and what would the
>> killer improvement(s) be? TIA.
If there was a clear definition of what was required in this area I
suspect that there would be less attempts at building toolkits.
Albatross is a design that evolved from my experience in building a
collection of small but data rich intranet applications. I discovered
that I was doing the same things over and over. It does not show from
the release history of Albatross, but the toolkit was several years in
the making.
Tim> Albatross by Object Craft (see http://www.object-craft.com.au )
Tim> does an excellent job of separating the presentation layer from
Tim> the underlying logic - my understanding is that such separation
Tim> was one of its main design goals. However, it does not take a
Tim> pedantic position on this - it still allows Python code to be
Tim> embedded in HTML templates - such practice is discouraged, but
Tim> Albatross provides mechanisms to allow you to do it if you
Tim> insist. But more usefully, Albatross provides tags which allow
Tim> conditional processing (if-elif-else) and most usefully,
Tim> iteration, to be placed in the HTML template. So your Python
Tim> business logic code can assemble a Python sequence of, say,
Tim> database query results, but it is the HTML template which
Tim> iterates through that list to create the final HTML which is sent
Tim> to the user's browser. Such a feature is essential, because
Tim> otherwise the business logic Python code ends up needing to
Tim> creating HTML output itself, which is then merely substituted
Tim> into the HTMl template. Thus, the Albatross model is really more
Tim> like: "all HTML-related stuff, including conditional processing
Tim> and iteration, is looked after in the HTML templates, and all
Tim> business logic stuff, divorced from the manner in which it will
Tim> be presented, is handled by Python modules." Of course, this is
Tim> just the well-known model-view-controller approach, but Albatross
Tim> implements this very nicely, IMO. See
Tim> http://www.object-craft.com.au/projects/albatross/albatross/fig-presimpexec.html
Tim> for more information about this (and to get an idea of the depth
Tim> of the Albatross documentation).
I think the biggest area which requires improvement in Albatross is
still the documentation.
Tim> I suspect that the Object Craft guys would welcome help with
Tim> further development of Albatross. What the world really needs are
Tim> more Pythonic Web applications, rather than more Pythonic Web
Tim> application frameworks.
People who have tried Albatross could really help us by writing
beginner level instructions and by pointing out where the existing
documentation is misleading. We are all too close to the code to see
clearly.
- Dave
Max M
I do understand that argument, but I almost certainly don't agree that
it is of much use.
In smaller one-of systems it makes sense, but in an app-server like Zope
where the idea is that different components can be joined together to
create a bigger application, there has to be stronger rules for layout
and design of the components so that they will automatically fit into
the bigger whole.
Page template languages is the wrong approach in this regards.
The development of the Cmf and Plone are good examples of this wrongfull
approach. They make it easy to create one single type of application,
but makes it very hard to re-use their components to build other types
of applications.
And I believe that the reason is that they are using pagetemplate
languages to bind it together, which leads to this kind of design.
I my experience, tools which separates logic from view in the
"pagetemplate" approach is doing it wrong.
The layout may be separated, but reuse of code/componentes greatly
suffers from this approach.
regards Max M
Dave Cole
Max> Jon Ribbens wrote:
>> In article <af2gh6$2c2$0...@216.39.172.122>, Bengt Richter wrote: Take
>> a look at http://jonpy.sourceforge.net/ . It almost completely
>> separates code and HTML so that the designer and the coder do not
>> interfere with each other.
Max> I do understand that argument, but I almost certainly don't agree
Max> that it is of much use.
I agree, I am not sure it is such a good argument myself. If you are
working in an environment where HTML editors do not understand the
templating system then you are going to need at least one person who
can post process the HTML and integrate it with the templating logic.
No magic templating system is going to solve that problem.
Max> In smaller one-of systems it makes sense, but in an app-server
Max> like Zope where the idea is that different components can be
Max> joined together to create a bigger application, there has to be
Max> stronger rules for layout and design of the components so that
Max> they will automatically fit into the bigger whole.
Whenever you have a medium to large size system you need to establish
rules to ensure that components fit together. Zope is certainly not
unique in this regard.
Max> Page template languages is the wrong approach in this regards.
Are you able to explain why?
Max> The development of the Cmf and Plone are good examples of this
Max> wrongfull approach. They make it easy to create one single type
Max> of application, but makes it very hard to re-use their components
Max> to build other types of applications.
Whenever you build any toolkit you have to decide on the set of
problems that you wish to solve with the toolkit. The smaller the
problem domain the more useful you can make the toolkit.
If your problem falls within the domain of the toolkit then you will
like the toolkit. If your problem is not addressed by the toolkit
then you are likely to question the usefulness of the approach.
Max> And I believe that the reason is that they are using pagetemplate
Max> languages to bind it together, which leads to this kind of
Max> design.
I suggest that the problem that they are trying to solve has lead to
the implementation. I could be misunderstanding you, but could you
explain an alternative approach to solving the problem which would
deliver a more general solution?
Max> I my experience, tools which separates logic from view in the
Max> "pagetemplate" approach is doing it wrong.
Again, can you explain why?
Max> The layout may be separated, but reuse of code/componentes
Max> greatly suffers from this approach.
Not sure I agree here. Maybe I am missing something because I think
that a clear separation of presentation and implementation increases
the cohesiveness of code and reduces the incidence of pathological
coupling.
Paul Boddie
> >>>>> "Max" == Max M <ma...@mxm.dk> writes:
>
> Max> Jon Ribbens wrote:
> >> In article <af2gh6$2c2$0...@216.39.172.122>, Bengt Richter wrote: Take
> >> a look at http://jonpy.sourceforge.net/ . It almost completely
> >> separates code and HTML so that the designer and the coder do not
> >> interfere with each other.
>
> Max> I do understand that argument, but I almost certainly don't agree
> Max> that it is of much use.
>
> I agree, I am not sure it is such a good argument myself.
It's a sort-of-incomplete argument, really. In most situations, the
designer and developer need to agree on what is being presented, so
they must "interfere" with each other in some way. However, the nature
of the interference should be focused only on the structure of the
data, not on the way the data is stored, for example.
> If you are
> working in an environment where HTML editors do not understand the
> templating system then you are going to need at least one person who
> can post process the HTML and integrate it with the templating logic.
> No magic templating system is going to solve that problem.
If the designer and HTML editor together know nothing about the
templating system, the best that one can hope for is a diminished
amount of work doing that integration for the developer. Moreover,
where changes need to be made again by the designer, it really helps
if the developer can avoid doing any work "unintegrating" the
templates from the system. Being able to make a round trip with the
templates is pretty interesting, in my opinion.
> Max> The development of the Cmf and Plone are good examples of this
> Max> wrongfull approach. They make it easy to create one single type
> Max> of application, but makes it very hard to re-use their components
> Max> to build other types of applications.
>
> Whenever you build any toolkit you have to decide on the set of
> problems that you wish to solve with the toolkit. The smaller the
> problem domain the more useful you can make the toolkit.
Indeed. Some kinds of applications may be addressed well by a
particular toolkit, and since you might spend most of your time
constructing those applications for customers, for example, it would
definitely be worthwhile abandoning "complete freedom of expression"
for something which gets the job done quickly, effectively and
cheaply. This is arguably where many toolkits/frameworks fall down -
by trying to be everything to everyone, they become as complicated as
the language they're written in and don't always offer much more than
the bare language in doing a particular job. Consequently, people get
the temptation to write "rival frameworks" from scratch.
Paul
Bengt Richter
>E.g., if you were hoping for an improvement over current practice,
>which do you consider to be the tool(s) to beat, and what would
>the killer improvement(s) be? TIA.
>
Thank you all (alphabetically: Ian Bicking, Paul Boddie, Tim Churches,
Dave Cole, Max M, and Jon Ribbens ;-) for your thoughtful responses and
links to relevant resources.
For the Python aspect of things, Albatross seems very similar to
(though more elaborate than) what I had in mind, but ZPT is more to my
liking in the HTML markup area.
I looked at stuff at the links offered (and browsed a bit):
http://jonpy.sourceforge.net/
http://www.object-craft.com.au
http://www.object-craft.com.au/projects/albatross/albatross/fig-presimpexec.html
and I Googled for Cheetah:
http://www.cheetahtemplate.org/
No one mentioned ZPT (Zope Page Templates),
http://www.zope.org//Wikis/DevSite/Projects/ZPT/FAQ
and from the description, this would seem to have a real advantage over all of
the above, in that it uses attributes of html tags as opposed to special tags
that browsers or design tools won't generally understand and render usefully.
This is touted as enabling the "round trip" from graphic designer to template logic
programmer and back using the same html source. I assume this is the "round trip"
Paul was referring to. To me, it seems a winning point for ZPT, though I don't know
how ZPT works out in practice.
They have a list of design tools that apparently pass through the ZPT markup they
don't understand. According to the FAQ:
"Q8: What HTML editors work well with ZPT?
We are still compiling a list, but on the commercial (industrial strength)
front, GoLive and Dreamweaver 4 work well with ZPT. Recent versions of Amaya
work well in HTML mode."
Opinions on ZPT?
BTW, which is the most appropriate Python version to assume everyone's servers
will be converging on? 1.5, 2.1, 2.2, or ? Could I reasonably plan on using 2.2?
E.g., I think 2.1 is being included in most newer linux distributions. But more
to the point, what version will most likely be available via server cgi etc.?
I'd like the answer to be 2.2 ;-)
Regards,
Bengt Richter
Evan
> No one mentioned ZPT (Zope Page Templates),
> http://www.zope.org//Wikis/DevSite/Projects/ZPT/FAQ
>
> and from the description, this would seem to have a real advantage over all of
> the above, in that it uses attributes of html tags as opposed to special tags
> that browsers or design tools won't generally understand and render usefully.
>
> This is touted as enabling the "round trip" from graphic designer to template logic
> programmer and back using the same html source. I assume this is the "round trip"
> Paul was referring to. To me, it seems a winning point for ZPT, though I don't know
> how ZPT works out in practice.
It works out quite well, if you're using Zope. I haven't seen much
feedback from people using it independently of Zope, so I can't say one
way or another in that case.
> Opinions on ZPT?
I like it, but then I would :-) My wife (graphic designer) and I were
major contributors to the design of ZPT, so it suits our tastes.
There are also plans in the works for a stylesheet-like extension to ZPT
that would allow the logic (even the presentation logic) to be further
separated from the HTML, without plunging the programmer into the dark
mists of DOM-walking.
Cheers,
Evan @ 4-am
Ian Bicking
> On 22 Jun 2002 18:43:50 GMT, bo...@oz.net (Bengt Richter) wrote:
> and from the description, this would seem to have a real advantage over all of
> the above, in that it uses attributes of html tags as opposed to special tags
> that browsers or design tools won't generally understand and render usefully.
Cheetah avoids using these tags for this reason. It still requires
invalid HTML for some cases, though, particularly:
<table>
#for $item in $list #
<tr><td>$item</td></tr>
#end for #
</table>
(Note that you can use # to end statements, as you should do if you want
the template to work in WYSIWYG tools, which won't preserve newlines)
There's ideas for fixing this, but it's very annoying from the parsing
perspective... right now Cheetah doesn't have to understand markup at
all, but anything that will fix this will likely have to parse the
markup in order to work well.
In most other cases, though, I think Cheetah will be more usable if you
want to expose programming logic to designers. I personally don't feel
that designers should be insulated from the logic -- it is essential to
know, for instance, that something will be repeating, or exactly what
variable gets inserted where. Using dummy information to express this
isn't, IMHO, as transparent or reliable (since the dummy information
isn't necessarily in sync with the programming code).
But this depends on how you view the designer, and what you expect of
them. If you want the designer to be able to code the template, I don't
know how well ZPT will do -- it doesn't seem like an intuitive way to
think of the template (though I would expect a programmer to adapt
easily enough). If you want the designer to only edit documents that
are first created by programmers, then it might work well.
But this is only my intuition, I haven't actually tried to use Cheetah
or ZPT with designers like this.
You might be interested to look at XMLC (http://xmlc.enhydra.org/) --
similar to ZPT, but with greater WYSIWYG support, and with considerably
less transparency (no actual code is contained in the template). It's
kind of the extreme of that direction -- like accessing a DOM where the
markup is annotated and the API is much more friendly. It's not in
Python, though maybe someone has created a clone (which shouldn't be
hard).
> BTW, which is the most appropriate Python version to assume everyone's servers
> will be converging on? 1.5, 2.1, 2.2, or ? Could I reasonably plan on using 2.2?
> E.g., I think 2.1 is being included in most newer linux distributions. But more
> to the point, what version will most likely be available via server cgi etc.?
> I'd like the answer to be 2.2 ;-)
Servers tend not to be very up-to-date. I think 1.5.2 is still quite
common -- at least, it's likely to be /usr/bin/python on lots and lots
of servers (even if python2 is available somewhere).
Ian
Paul Boddie
>
> No one mentioned ZPT (Zope Page Templates),
> http://www.zope.org//Wikis/DevSite/Projects/ZPT/FAQ
This thread wouldn't end if we all started naming template systems,
though. ;-) For something similar to the jonpy templating, take a look
at http://www.clearsilver.org - a system which I was made aware of
recently. If nothing else, that site gives some very good arguments
against "Python in HTML" systems.
> and from the description, this would seem to have a real advantage over all of
> the above, in that it uses attributes of html tags as opposed to special tags
> that browsers or design tools won't generally understand and render usefully.
It should work well with XML-capable tools. However...
> This is touted as enabling the "round trip" from graphic designer to template
> logic programmer and back using the same html source. I assume this is
> the "round trip" Paul was referring to. To me, it seems a winning point for
> ZPT, though I don't know how ZPT works out in practice.
Yes, that was what I was referring to. However...
> They have a list of design tools that apparently pass through the ZPT markup
> they don't understand. According to the FAQ:
>
> "Q8: What HTML editors work well with ZPT?
> We are still compiling a list, but on the commercial (industrial
> strength) front, GoLive and Dreamweaver 4 work well with ZPT. Recent
> versions of Amaya work well in HTML mode."
>
> Opinions on ZPT?
In my experience, "recent versions of Amaya" either don't work with
ZPT, or the secret incantation to make it work hasn't been widely
publicised - "HTML mode" doesn't really tell me anything. What happens
when I try to load ZPT into Amaya is a large number of warnings about
invalid attributes, followed by the loss of those attributes in the
saving process.
On the other hand, if I use some 'id' attributes in HTML to give
"structure" to my template, Amaya will only intervene when two such
attributes are identical. Consequently, it's possible to do like
Enhydra's XMLC and make a template system operating around those
principles.
Paul
Max M
> This thread wouldn't end if we all started naming template systems,
> though. ;-) For something similar to the jonpy templating, take a look
> at http://www.clearsilver.org - a system which I was made aware of
> recently. If nothing else, that site gives some very good arguments
> against "Python in HTML" systems.
Yes but that system os only where Zope is with dtml!
Zpt has been written to not have the faults of dtml ... so Zpt is pretty
well thought out for what it is intended to do.
regards Max m
Dave Cole
>> Whenever you build any toolkit you have to decide on the set of
>> problems that you wish to solve with the toolkit. The smaller the
>> problem domain the more useful you can make the toolkit.
Paul> Indeed. Some kinds of applications may be addressed well by a
Paul> particular toolkit, and since you might spend most of your time
Paul> constructing those applications for customers, for example, it
Paul> would definitely be worthwhile abandoning "complete freedom of
Paul> expression" for something which gets the job done quickly,
Paul> effectively and cheaply. This is arguably where many
Paul> toolkits/frameworks fall down - by trying to be everything to
Paul> everyone, they become as complicated as the language they're
Paul> written in and don't always offer much more than the bare
Paul> language in doing a particular job. Consequently, people get the
Paul> temptation to write "rival frameworks" from scratch.
Touche. :-)
Jon Ribbens
[ZPT]
> and from the description, this would seem to have a real advantage over all of
> the above, in that it uses attributes of html tags as opposed to special tags
> that browsers or design tools won't generally understand and render usefully.
jonpy is also designed to be design-tool-proof, in that the only two
constructs it places into the HTML are simple strings in ordinary
text or attributes (where design tools will not mess with them) and
HTML comments to denote structure (which design tools also will not
generally mess with). So I don't think that ZPT has any advantage over
jonpy here.
Bengt Richter
>On Mon, 2002-06-24 at 19:36, Bengt Richter wrote:
>> On 22 Jun 2002 18:43:50 GMT, bo...@oz.net (Bengt Richter) wrote:
>> and from the description, this would seem to have a real advantage over all of
>> the above, in that it uses attributes of html tags as opposed to special tags
>> that browsers or design tools won't generally understand and render usefully.
>
[...]
>You might be interested to look at XMLC (http://xmlc.enhydra.org/) --
>similar to ZPT, but with greater WYSIWYG support, and with considerably
>less transparency (no actual code is contained in the template). It's
>kind of the extreme of that direction -- like accessing a DOM where the
>markup is annotated and the API is much more friendly. It's not in
>Python, though maybe someone has created a clone (which shouldn't be
>hard).
I'd seen it in a list somewhere, but skipped it as I wasn't interested in a Java tool,
but I do like the minimal intrusion into the designer-mockup HTML world, using
"compilation" etc.
Thanks for the pointer.
Regards,
Bengt Richter
Stephen Tyler
> E.g., if you were hoping for an improvement over current practice,
> which do you consider to be the tool(s) to beat, and what would
> the killer improvement(s) be? TIA.
Well, there are more parties involved than just designer and coder. What
about content providers (authors, illustrators), database administrators
and management (project managers etc). They also play an important role,
and their productivity is affected by the choice of web templating/db
tools.
Most of the web templating debate focuses on the separation (or otherwise)
of the programming code (python) and the markup code (HTML). Most
solutions are variants of:
Python code ----- New programming language
\ /
\ /
HTML
[That is meant to be a triangle]
where "New programming language" is some kind of intermediate execution
model (loops, conditionals) that is supposedly easier for non-coders to
embed (or leave alone) in their HTML.
A simple "include" mechanism whould be on the Python-HTML axis, very close
to the HTML end.
Echo statements in Python is a point very close to "Python code".
And most of the web templating solutions trend towards either defining a new
programming language, or a way to embed Python in HTML.
But, as the new programming language becomes more expressive, it tends to
become yet-another-PHP, and becomes yet another thing to mystify the
non-coders, and another way to write obfuscated code for the coders.
Code should be written in an efficient code for coding (eg Python). And
likewise for the other elements (but I will stop short of saying that HTML
is an efficient code for markup).
In my view, the next generation of web templating/db tool needs to move
beyond the issue of python/HTML separation and start solving some higher
level issues:
- Reuse (both of code, markup and content)
- Authorisation and security
- Higher level structures (forms, tables, lists, trees, navigation should be
handled and manipulated at an abstract level, rather than as a mess of HTML
markup)
- Consistency and style (the "style" of the site should be able to be
changed across an entire site by making small changes to a small number of
items in a small number of places - and my definition of style is much
broader than just CSS)
- Configuration management (Can we revert to the previous version if the
change is not working properly? Can we test the new version on particular
users (or classes or users) before fully commiting to the new version? Can
we track changes to the system?)
Just take the example of form handling:
You have certains fields in certain tables in your database. And you want
the user to be able to change those fields. This is a pretty simple
requirement, yet the solution in most web templating systems is pretty
complex:
- is the user authorised to view, change, or create this record?
- how do we verify the integrity of the user input for each of these fields?
For things like range checks, to date validation, email validation and
dependencies on other fields.
- how do we notify the user of errors in user input?
- how do we notify the user of errors in authorisation?
- how do we notify the web administrator of errors?
- how do we label these fields? If the label needs to be changed or
localised, where do we make those changes?
- how do we access these fields? Do we have to write an SQL query for this
(and every other) data access? Or can the templating system generate the
appropriate efficient SQL query?
- How do we save the results back to the database? How do we cope with
results spread across different tables? Can the templating system generate
the appropriate efficient SQL query? What about transactions?
Now in my view, all the templating systems I have seen turn this "simple"
exercise into a fairly complex code. And 99% of the time, the
implementations of this code ignore several important steps in the process.
And 99% of the time, the code has to be reimplemented for every new form
that is required.
In my view, Zope (with suitable add-ons) comes closest to meeting these
goals. But it is not without its problems:
- It has strong links to a non-standard database. Support for commonly
deployed enterprise databases (Oracle et al) is relatively weak (but that
is not to say that it is strong in other python-based systems)
- It has a version control system, but this is not well integrated with
other version control systems (eg CVS)
- It is difficult to integrate with non-Zope workflow processes usable by
non-coders
- Zope also strongly influences the http-server choices, yet it is not
clearly superior to other http-server alternatives.
- Zope has a mean learning curve. You can't just walk up to it and become
productive from day one. You need good documentation and examples (which
used to be very difficult to find).
The other contenders for my "next-generation" web templating system
typically use XSLT to transform a variety of XML inputs into XHTML output.
But XSLT can be very obtuse for non-coders (and even coders). And it still
needs to be supplemented with a general-purpose programming language.
For my own code, I have developed a number of libraries over the years to
solve these problems. But they have all fallen somewhat short of my goals
in one or more ways (too complex, too specific, inefficient, obtuse or
missing functionality). But I keep trying.
Good luck in your search,
Stephen Tyler
www.ebusinessresults.com.au
Paul Boddie
> Bengt Richter wrote:
>
> > E.g., if you were hoping for an improvement over current practice,
> > which do you consider to be the tool(s) to beat, and what would
> > the killer improvement(s) be? TIA.
>
> Well, there are more parties involved than just designer and coder. What
> about content providers (authors, illustrators), database administrators
> and management (project managers etc). They also play an important role,
> and their productivity is affected by the choice of web templating/db
> tools.
Indeed. But the involvement of many different parties is, in my view,
a strong argument for simplified template systems which can be
"round-trip" edited in WYSIWYG HTML editors, for example. My
justification for this is that otherwise a larger workload may be
placed on the person who has to integrate design changes into the
system.
[Python-HTML-other triangle]
> And most of the web templating solutions trend towards either defining a new
> programming language, or a way to embed Python in HTML.
>
>
> But, as the new programming language becomes more expressive, it tends to
> become yet-another-PHP, and becomes yet another thing to mystify the
> non-coders, and another way to write obfuscated code for the coders.
That's why there's a strong argument for implementing template systems
which are not programming languages - wholly declarative template
notations, for example. Whilst such notations cannot express
complicated dynamic layout, one can always use a layered approach: one
layer builds the forms, another does the fancy colouring, etc.
> Code should be written in an efficient code for coding (eg Python). And
> likewise for the other elements (but I will stop short of saying that HTML
> is an efficient code for markup).
No, but HTML is a standard on the Web...
> In my view, the next generation of web templating/db tool needs to move
> beyond the issue of python/HTML separation and start solving some higher
> level issues:
>
> - Reuse (both of code, markup and content)
The biggest challenge in terms of code reuse is arguably where
validation of data is performed. One problem with markup reuse (as
typically implemented in template systems) is the lack of support for
"includes" in various editing tools, as far as I am aware. Thus,
previewing of templates is fairly impaired in many tools, although I'm
sure that some of them are starting to deal with this.
> - Authorisation and security
The standard authentication mechanism in J2EE, for example, is
interesting because the process of authentication is transparent to
the application - it is the application server which prompts the user
for their details, even using a Web page. An authorisation scheme can
be more complicated to design unless it is deliberately kept simple.
> - Higher level structures (forms, tables, lists, trees, navigation should be
> handled and manipulated at an abstract level, rather than as a mess of HTML
> markup)
I agree with you on the issue of forms, in the sense that form fields
should be consistent with the underlying schema, but tables, lists and
trees all reduce to the same general case. The big question is: how do
you allow someone to edit these objects using a tool giving a more
sophisticated representation than a text editor (or uninspired XML
tree editor)?
> - Consistency and style (the "style" of the site should be able to be
> changed across an entire site by making small changes to a small number of
> items in a small number of places - and my definition of style is much
> broader than just CSS)
Again, this would be great if one could retain a WYSIWYG HTML editor.
> - Configuration management (Can we revert to the previous version if the
> change is not working properly? Can we test the new version on particular
> users (or classes or users) before fully commiting to the new version? Can
> we track changes to the system?)
Well, it would be nice to hear the best practices in this area - how
to develop, test and deploy Web applications using CVS, perhaps.
> Just take the example of form handling:
>
> You have certains fields in certain tables in your database. And you want
> the user to be able to change those fields. This is a pretty simple
> requirement, yet the solution in most web templating systems is pretty
> complex:
In that you often need to build the form fields manually, and don't
have many possibilities for automatic verification/synchronisation of
those fields against the database?
[Access, validation]
> - how do we notify the user of errors in user input?
This is something that a general mechanism can be very helpful with.
Manually coding error checking in both the Python code and the
template can be extremely tedious.
> - how do we notify the user of errors in authorisation?
>
> - how do we notify the web administrator of errors?
Indeed. It's dubious to say that "we log all errors" - who actually
reads the log unless the whole system is down?
> - how do we label these fields? If the label needs to be changed or
> localised, where do we make those changes?
With different templates? Let's say you have a US site and a British
site: "Not many spelling differences there," one may think, until one
realises that the very nature of the user interface could be different
- different information, legal terms, presentation style, and so on,
could all apply.
> - how do we access these fields? Do we have to write an SQL query for this
> (and every other) data access? Or can the templating system generate the
> appropriate efficient SQL query?
I personally wouldn't look to a templating system to generate SQL
queries - that's why we have multi-layered architectures, in my
opinion.
> - How do we save the results back to the database? How do we cope with
> results spread across different tables? Can the templating system generate
> the appropriate efficient SQL query? What about transactions?
Again, it's arguably best to introduce another layer.
> Now in my view, all the templating systems I have seen turn this "simple"
> exercise into a fairly complex code. And 99% of the time, the
> implementations of this code ignore several important steps in the process.
> And 99% of the time, the code has to be reimplemented for every new form
> that is required.
I'll agree with this assessment in principle. I'll also claim that
complicated forms can be a nightmare to implement without specific
assistance from the Web development framework in the areas of
validation and presentation/templating.
[...]
> The other contenders for my "next-generation" web templating system
> typically use XSLT to transform a variety of XML inputs into XHTML output.
> But XSLT can be very obtuse for non-coders (and even coders). And it still
> needs to be supplemented with a general-purpose programming language.
XSLT is (arguably) not easily previewed - at least not in the sense
that one can take an XSL document on its own and say that the final
output "will look something like this". In contrast Zope Page
Templates is designed to make sense in its "uninstantiated" state.
> For my own code, I have developed a number of libraries over the years to
> solve these problems. But they have all fallen somewhat short of my goals
> in one or more ways (too complex, too specific, inefficient, obtuse or
> missing functionality). But I keep trying.
My advice would be to not rely on a single specific technology to do
everything from Web serving to database management, and to expect to
combine frameworks with other projects to solve these kinds of
problems.
Paul
Stefan Franke
>E.g., if you were hoping for an improvement over current practice,
>which do you consider to be the tool(s) to beat, and what would
>the killer improvement(s) be? TIA.
[... and later]
> Opinions on ZPT?
I have a (vague) idea I'd like to discuss in this context. The first
thing that came to my mind while reading the ZPT/TAL announcement
some time ago was this:
It's a brilliant idea to use attributes to specify operations on their
including tags (replacement being the most important operation).
Using special attributes instead of special tags increases the
propability that they're left unchanged by HTML editors.
But does it really go far enough? Still, the presentation logic
substitution, iteration, ..) is encoded within a HTML template file
with (now semantical, not syntactical) non-standard elements, which
makes it hard to hand out the file to a page designer who
knows nothing about programming.
Can we further reduce the 'degree of intrusiveness'? (excuse my clumsy
english) The set of operations we want to perform on a template is
clear (see TAL spec): replacement (of tags or tag content), iteration,
conditionals, adding attributes etc.
But why place these operations inside the tags/template instead of
finding another way of specifying the affected tags?
HTML offers a standard way to address tags by using id attributes.
Can't we leave the HTML alone, just mark the affected tags by giving
them IDs, and put all the replacement/iteration commands into a
separate place?
The presentation commands could be either ordinary Python statements
or some abbreviated/specialized variants of it (e.g. Quixote-like).
The advantages I see here are
- The template document is perfect HTML. Since we have substitution
commands like in TAL, we can fill up the document with dummy data
and make the template itself appear well-formed and reasonable
in any browser
- All the HTML designer has to respect are the IDs of certain tags
("tableLine", "customerNameCell", ..). If he knows JavaScript/DHTML
he should be familiar with this anyway.
- The same replacement logic could be applied to different template
files, we have an additional layer of indirection here.
- One presentation command file could address and assemle
elements from different HTML template files
Disadvantages:
- One has to maintain two documents instead of one (but as I argued, I
see this as an advantage)
- In case of conditionals, there might be difficulties to bear up the
rule that the template file is always perfect visible HTML - at
least without redundancy
- Scoping/local replacement within iteration might become complicated
* * *
What do you think about it? There might well be big things I
left out of consideration, since I'm quite out of web business (my
last bigger project was with Zope 1.10.2 and its DTML...).
Best,
Stefan Franke
Jonathan Hogg
"Stephen Tyler" <nn...@ebusinessresults.com.au> wrote:
> The other contenders for my "next-generation" web templating system
> typically use XSLT to transform a variety of XML inputs into XHTML output.
> But XSLT can be very obtuse for non-coders (and even coders). And it still
> needs to be supplemented with a general-purpose programming language.
Did anyone mention Cocoon yet in this thread? (I didn't follow the start)
<http://xml.apache.org/cocoon/>
I think they've got a very interesting idea based on transforming XML. The
main feature of their model is "Separation of Concern" - enabling content
authors, designers, and programmers to all work independently. It's sort of
like JSP tag libraries, but in multiple layers.
Jonathan
Paul Boddie
>
> HTML offers a standard way to address tags by using id attributes.
> Can't we leave the HTML alone, just mark the affected tags by giving
> them IDs, and put all the replacement/iteration commands into a
> separate place?
This is what Enhydra's XMLC does, and one uses a DOM-like API to
access the elements marked in this way in the document. I've been
experimenting with a system which doesn't modify or replicate the
elements programmatically; instead, the marked elements reflect the
structure of the data being presented.
> What do you think about it? There might well be big things I
> left out of consideration, since I'm quite out of web business (my
> last bigger project was with Zope 1.10.2 and its DTML...).
I think that this is really the way to go for anyone interested in
investigating the subject area further, rather than inventing yet
another "source code in HTML" solution and hoping to find out new ways
of working from that.
Paul
Richie
> Can't we leave the HTML alone, just mark the affected tags by giving
> them IDs
I've been thinking along similar lines recently. The only slight
difference is that for form controls I'm allowing the 'name' attribute as
an alternative to 'id'. These are the notes I have on the way I'd like
the system to work (note that normally the HTML would be read from an
external file rather than included in the source):
>>> import Template
>>> html = """
... <html><body>
... <p>Please fill in your username and the message to send.</p>
... <form id='send' action='test.py'>
... <input type='text' name='username' size='20' value='rjh'><br>
... <textarea rows='10' cols='80' name='message'>Type here...</textarea>
... </form>
... </body></html>"""
...
>>> page = Template.Page( html )
>>> page.send
<Template.Form, name='send'>
>>> page.send.username
<Template.Input, type='text', name='username'>
>>> page.send.username.size
20
>>> page.send.username.size = 30
>>> page.send.username.value = "richie"
>>> page.send.username.render()
'<input type='text' name='username' size='30' value='richie'>'
>>> page.render()
[...what you'd expect...]
> - One presentation command file could address and assemle
> elements from different HTML template files
Yes - eg. a navigation bar down the left-hand side of each page. You have
a master page that contains it, marked as a named div, and put a marker
div of the same name in each page. The marker just contains "Navigation
here!" or something. You then take the menu out of the master page and
copy it into the other pages programmatically:
>>> masterPage = Template.Page( masterHTML )
>>> aboutUsPage = Template.Page( aboutUsHTML )
>>> aboutUsPage.navigation = masterPage.navigation
You can then manipulate it - say you have a 'class' attribute for the menu
links and you use a different class for the current page's entry:
>>> aboutUsPage.navigation.aboutUs.class = "nav-highlight"
(this relies on the links in the menu having 'id' tags).
> - Scoping/local replacement within iteration might become complicated
This is how I envisage iteration working: a designer includes a table of
data in the page using dummy values, and a programmer populates it with
new rows based on the designer's original. The objects have a 'clone'
method which creates a duplicate object, optionally with some attributes
changed:
>>> tableHtml = """
... <table border='2'>
... <tr id='record'><td id='name'>Richie</td><td id='age'>30</td></tr>
... </table>"""
...
>>> table = Template.Table( tableHtml )
>>> templateRow = table.record
>>> templateNameCell = table.record.name
>>> templateAgeCell = table.record.age
>>> table.remove( record )
>>> i = 1
>>> for data in [ { 'name': 'Andy', 'age': 29 },
... { 'name': 'Bill', 'age': 12 } ]:
... row = TemplateRow.clone( id='record%d'%i )
... row.name.setContent( data['name'] )
... row.age.setContent( data['age'] )
... table.add( row )
... i = i + 1
...
>>> table.render()
<table border='2'>
<tr id='record1'><td id='name'>Andy</td><td id='age'>29</td></tr>
<tr id='record2'><td id='name'>Bill</td><td id='age'>12</td></tr>
</table>
When a CGI form is submitted, you recreate the object tree with the
submitted values like this:
>>> page = Template.Page( html )
>>> page.updateValues( cgi.FieldStorage() )
>>> page.send.username.value
"someusername"
You can also update the values using a dictionary, for prepopulating the
page out of a database for example.
The biggest problem I can see is that I'm using object attributes to
represent both HTML tag attributes and child objects. So 'form.name'
could refer to an attribute of the <form> tag or to an input control on
the form. The obvious solution is to put the children or the attributes
(or both) into container objects:
>>> page.send.children.username
<Template.TextInput, name='username'>
>>> page.send.attributes.action
'test.py'
but this makes things look cluttered, especially if you're referring to
objects more than one or two levels deep.
Note that all these classes, Template.Table, Template.Form, etc. etc.,
would probably be created on the fly - there wouldn't really be a chunk of
code in the Template module for every HTML tag.
--
| Richie Hindle, r...@cyberscience.com
| All opinions are mine and not necessarily those of my employer.
| Why did the Zen Buddhist refuse anaesthetic at the dentist?
| Because he wanted to transcend dental medication.
Sam Brauer
http://maki.sourceforge.net/
If you're interested in using XSLT to separate layout/presentation from
data/logic, and prefer Python to Java, it's worth a look.
Stefan Franke
[...]
>This is what Enhydra's XMLC does, and one uses a DOM-like API to
>access the elements marked in this way in the document.
Thank, Paul, for this interesting reference!
* * *
On Wed, 03 Jul 2002 11:11:02 +0100, Richie <r...@cyberscience.com> wrote:
[...]
>The biggest problem I can see is that I'm using object attributes to
>represent both HTML tag attributes and child objects. So 'form.name'
>could refer to an attribute of the <form> tag or to an input control on
>the form.
I don't think this really is a big problem. A HTML document has to be
checked only once if an Id of a son element collides with one of its
attributes (e.g. when modified as a Zope document).
During processing, only the add_attribute() function has to check for
son elements of the same name accordingly.
Name collisions could also be avoided with naming conventions or by
allowing structured names for elements itself (id="attr.color")
>Note that all these classes, Template.Table, Template.Form, etc. etc.,
>would probably be created on the fly - there wouldn't really be a chunk
>of code in the Template module for every HTML tag.
Here I don't (yet) see the advantage of having different classes mirroring
the different HTML tags. Ok, the table object in your example offers add()
and remove() methods, OTOH ZPT shows us that a set of uniform operations
replacement operations is sufficient.
The XMLC Paul mentioned seems to use a single class for this as well
(org.enhydra.xml.xmlc.html.HTMLObject, as far as I interpret
http://webreference.com/xml/column23/3.html).
I would try to keep things even more simple: Is there really a need for
a DOM-like access where each tag and sub-tag of interest has to be
tree-like identified? If there's only one place where substitution
should happen, it's not necessary to mark more than one tag, even if
this one is deeply nested.
Thus, the document tree would fall apart into a forest of sparse subtrees,
each of which usually not more than 2 or 3 levels deep. This help a lot
to keep the addressing simple, and allows more abstration between the HTML
documents and the templating scripts - in case the same script is used
with multiple documents, only the 'abstract' document structured, as
given by the identified tags, has to match.
In a perfect world, we had even two layers of template substitutions: A
'low-level' one based one a Python API (like yours above), and a higher
level one that specifies the substitutions in a more condensed way,
(a little context-specific, mayve Quixote-like language).
Since the latter one is restricted to a few operations, it could be
pre-compiled together with the HTML documents for maximum performance.
Stefan
Richie
> > The biggest problem I can see is that I'm using object attributes to
> > represent both HTML tag attributes and child objects.
>
I think I agree. The purist in me wants the two to be unambiguously
separated, but the pragmatist wants a simple API that lends itself to
intuitive code.
> I don't (yet) see the advantage of having different classes mirroring
> the different HTML tags.
Only that certain tags could behave in friendly ways; the Input class
could know that its 'size' attribute is an integer, and return an integer
for its value rather than a string, for instance. It's not necessary, and
could be too much black magic.
> Is there really a need for a DOM-like access where each tag and sub-tag
> of interest has to be tree-like identified?
No, not at all - the hierarchy would only include things with 'id' or
'name' attributes, so if you only needed to replace one thing you'd only
give that thing an 'id' attribute and it would be at the top of hierarchy.
If you do *need* a deep hierarchy, there's no reason you can't shortcut
straight to one element, as long its name is unambiguous:
>>> page = Template.Page( complicatedHtml )
>>> page.topsection.userinfo.loginform.username == page.getElement( 'username' )
True
Your "forest of sparse subtrees" idea (nice phrase!) is no problem.
> In a perfect world, we had even two layers of template substitutions: A
> 'low-level' one based one a Python API (like yours above), and a higher
> level one that specifies the substitutions in a more condensed way,
> (a little context-specific, mayve Quixote-like language).
I'm only really interested in what you call a low-level interface - two
languages, HTML and Python, are enough for me! But I think the low-level
interface should work with any other interface - after all, it just takes
HTML, manipulates it, and outputs HTML. There's no reason why the HTML
couldn't have come out of Quixote.
--
Richie Hindle
ric...@entrian.com
Stefan Franke
[...]
>I think that this is really the way to go for anyone interested in
>investigating the subject area further, rather than inventing yet
>another "source code in HTML" solution and hoping to find out new ways
>of working from that.
>
>Paul
What makes we wonder is, that XMLC was at least mentioned on zope-dev
along with the abandonment of Hiperdom in favour of the upcoming ZPT
about two years ago - as a quick archive search yielded.
Nevertheless it didn't have influence any influence on the design of ZPT.
Or were there any deliberate design decisions against this approach?
Paul Boddie
>
> What makes we wonder is, that XMLC was at least mentioned on zope-dev
> along with the abandonment of Hiperdom in favour of the upcoming ZPT
> about two years ago - as a quick archive search yielded.
>
> Nevertheless it didn't have influence any influence on the design of ZPT.
> Or were there any deliberate design decisions against this approach?
I'm not familiar with the ZPT design process, but there are several
advantages in having some kind of "declarative" template language
which automatically reflects the state of data structures (like DTML
does with the looping and value tags, for example) without needing
programmatic intervention behind the scenes. Certainly, it can be
easier to verify whether a template is going to present the correct
data, and to do it properly, if there's no run-time activity which can
change the nature of the data being presented.
It certainly seems very elegant to use a DOM-like API to edit parts of
a Web page, for example, and I would argue that the ability to isolate
a document structure (around the data being represented) within
another document structure (that describing the final output) is
almost essential to separate presentation from logic. However, it's
arguably tedious to write lots of stuff for a DOM API, not to mention
having to maintain such code (in addition to the other stuff) when the
fundamental data structures in a particular system need changing.
Paul