Python embedded like PHP
Rob Nikander
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>
Fredrik Lundh
> 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>
Andrew McNamara
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
> >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
Paul Boddie
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
Ian Bicking
> 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
> 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
> 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
> > <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.
Paul Rubin
>
> > > <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.
Magnus Lyckå
>><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
news:7xk7s7m...@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 dun...@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
> 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"
ro...@execulink.com
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.
Erno Kuusela
<phr-n...@nightsong.com> writes:
| Andy Gimblett <gi...@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
Andrew McNamara
> > 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>
>
> 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-)
Ian Bicking
>
> > > 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
>> 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?
Ian Bicking
> >> 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
Jim Abrams
@typhoon.southeast.rr.com:
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
Kevin Dahlhausen
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.
From the sample page:
What is the philosophy behind Cheetah?
Cheetah's design was guided by these principles:
Python for the back end, Cheetah for the front end. Cheetah was
designed to complement Python, not replace it.
Cheetah's core syntax should be easy for non-programmers to learn.
Cheetah should make code reuse easy by providing an object-oriented
interface to templates that is accessible from Python code or other
Cheetah templates.
Python objects, functions, and other data structures should be fully
accessible in Cheetah.
Cheetah should provide flow control and error handling. Logic that
belongs in the front end shouldn't be relegated to the back end simply
because it's complex.
It should be easy to separate content, graphic design, and program
code, but also easy to integrate them.
A clean separation makes it easier for a team of content writers,
HTML/graphic designers, and programmers to work together without
stepping on each other's toes and polluting each other's work. The
HTML framework and the content it contains are two separate things,
and analytical calculations (program code) is a third thing. Each team
member should be able to concentrate on their specialty and to
implement their changes without having to go through one of the others
(i.e., the dreaded ``webmaster bottleneck'').
While it should be easy to develop content, graphics and program code
separately, it should be easy to integrate them together into a
website. In particular, it should be easy:
for programmers to create reusable components and functions that are
accessible and understandable to designers.
for designers to mark out placeholders for content and dynamic
components in their templates.
for designers to soft-code aspects of their design that are either
repeated in several places or are subject to change.
for designers to reuse and extend existing templates and thus minimize
duplication of effort and code.
and, of course, for content writers to use the templates that
designers have created.
Jon Ribbens
> 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
>
[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
> 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/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
Jon Ribbens
> 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
> > 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
> 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.
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.
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.
Cheers
Jon
Dave Cole
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.
Paul Boddie
>
> 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
> 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