Graham Fawcett wrote:
> >We should use htmltext() consistent with our recommendations to users.
> >It's already confusing enough to know when to htmltext() things and when
> >to str() them. So anything that comes in with markup chars should be
> >htmltext'd or generated by htmltag().
> >
> Good point.
This means you should call htmlescape() on all input text, and it will do
the Right Thing automatically.
My article analyzing htmltext, PTL, and the html module may be helpful
background.
http://linuxgazette.net/117/orr.html
> >> * I've considered a tag-inlining syntax, so that you could write
> >> one-liners like "UL: LI: A('Main', href='/')". I'm torn, though;
> >> while more efficient, it would be harder to parse, and
> contravenes
> >> the Python-style recommendation against inlining block-level
> >> expressions.
> >
> >
> >Sounds too confusing for human maintainers. What would the indentation
> >be? What would a dedent do? A one-LI UL is so rare we don't need a
> >one-line syntax for it.
>
> One-line ULs might be a bad example, I do have a lot of code like "P:
> A(href='foo'): ...". But in the sake of consistency, I'll drop this
> idea.
Python allows a one-line body to be inline. But you can't stack two block
constructs together. I tried it now just to check.
>>> for x in "abc": if x == 2: print "Is"
SyntaxError: invalid syntax
> >>I think it takes the regularity of 'stan' syntax, and adds great
> >>readability through the block syntax, without requiring map() or
> >>listcomps to get iteration, or other declarative hacks to handle
> >>conditionals in the midst of a complex page.
> >
> >Yes, it reminded me of stan, but with an even cleaner syntax. It has
> some
> >good potential in that regard. I'm just not sure of putting it into the
> >default PTL, which is already magical enough with its import hook and
> >straight-to-pyc compiling. Could it be done as a third-party
> alternative
> >to PTL?
>
> It could be separated from PTL. But, in my mind, the proposed syntax
> depends heavily on PTL's "collect the bare expressions" strategy. I
> suppose it's conceivable to use the block-syntax without this.
I just mean to distribute it as a third-party module for now, then worry
about integrating it into the Quixote base. There's no reason to avoid
the PTL code if it's useful. Just copy it into your module or subclass
it.
> Before responding to your message, Mike, I rigged up a horrible little
> implementation (don't read the code, just execute it! :-) You can hook
> it into PTL with a quick, easily-reversed patch, and give it a try.
>
> http://fawcett.medialab.uwindsor.ca/quixote/eptl-1.0.tar
>
> Of course, it's pre-feedback, so some of my earlier ideas are present
> in the implementation. (If anyone actually tries the implementation,
> but has problems with it, email me directly with bug reports; I don't
> want to clutter the list.)
Looking at the source, it preprocesses the ePTL script to regular PTL, and
doesn't require any other changes in the PTL package, good.
On Python 2.3.4, Linux Gentoo, did:
$ cd /tmp/s
$ rm -rf *
$ wget http://fawcett.medialab.uwindsor.ca/quixote/eptl-1.0.tar
$ tar xvf eptl-1.0.tar
$ mkdir tmp_lib
$ (cd ~/src/Quixote-2.1; python setup.py install
--install-lib=/tmp/s/eptl/tmp_lib)
$ python setup.py install --install-lib=/tmp/s/eptl/tmp_lib
$ ls tmp_lib
eptl.py eptl.pyc eptl_tags.py eptl_tags.pyc quixote
$ export PYTHONPATH=/tmp/s/eptl/tmp_lib
$ python -c 'import quixote; print quixote'
$ cp tmp_lib/quixote/ptl/ptl_compile.py tmp_lib/quixote/ptl/ptl_compile0.py
$ (cd tmp_lib/quixote/ptl; patch output.html
### In browser, displays a 3-row table.
Works fine. I assume the patch problem is due to my limited experience
with the patch program.
--
-- Mike Orr