Re: Thoughts on a block-syntax extension to PTL

[email protected] wrote:

 >Graham Fawcett wrote:
 >
 >>This is a request-for-speculation. I've been thinking about an extension
 >>to PTL that I'd like to make, and wondered if you might scan my example
 >>below & provide feedback.
 >
 >
 >Interesting idea.  My concerns would be not getting in the way of existing
 >usage, not being fragile, and not being a huge code bloat.  I'm not sure I
 >would use it; when the template starts to use several levels of tags
 >(indented levels), I start reaching for a traditional template language
 >like Cheetah that makes the tags explicit in the source.

Thanks for the feedback, Mike. Fragility would be a concern; yet
another layer of code-transformation would take place during a PTL
import, and that could lead to a lot of confusion when something goes
wrong. I don't think bloat is as significant, unless you mean "concept
bloat"; the translation code itself could be quite compact. It is
another concept to soak in, and in that sense it may be a deterrent to
new PTL users. Having said that, I think these same problems occur
(sometimes) with other templating languages: yet another language to
learn, yet another way to do it.

 >If we do this, we should probably define a third output style rather than
 >overloading '[html]'.  But this would be orthogonical to the [text/html]
 >switch.  Maybe '[html, block]'.

Interesting idea. Perhaps it could also be an extension to the
enable_ptl call, like 'enable_ptl(extended_syntax=True)'.

 >>        TABLE(_class='nice_table'):     # or some other class-hack
 >
 >css_class= is the Quixote standard.

Ah, true. I never really used the forms modules, and should have
checked this. Of course, that's the tags, not the block-syntax, but it
ought to be consistent with Quixote.

 >># a custom block definition, using a str() expression
 >>alert = 'div style="color: red;"'
 >>        alert:
 >
 >This syntax and use is a bit surprising.  What about requiring tags to be
 >your special tag object?  And encouraging .open_block() and .close_block()
 >to call quixote.html.htmltag(), so there will be consistency between the
 >parts of a Quixote application.  Somehow you'd want to support default
 >attributes but let the user override them.  Maybe something like this:

Yes, the string-syntax was a bit of a throw-in. I will yank it out of
the proposal, unless anyone chimes in and absolutely loves it. ;-)

 >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.

 >>                        A(href='%d/edit' % person.id):
 >>                            'Edit'
 >>                        A('Delete',     # *args-style tag syntax
 >>                          href='%d/delete' % person.id)
 >
 >
 >In Python, keywords introducing a block cannot also be function names.
 >I'm not sure we should break that tradition.  It would also prevent us
 >from leveraging the Python parser, I think.

Well, it might. But even if it didn't, a consistent syntax is a good
idea, and certainly the example above is inconsistent. I would be
happy with the block-only form; it may be verbose at times, but it's
clean.

 >Putting the body (positional arg) before the attributes (keywords) is
 >confusing.  How urgent is it to support the args-style syntax?  Could we
 >have a special keyword arg for the body (body=)?  Are multiple positional
 >args allowed?

Yet another point in favour of dropping the tag-as-function
alternative. I'm leaning toward tags as blocks, and only tags allowed
in block definitions (where a "tag" is any object that supports
"open_block" and "close_block" methods).

 >>    * 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.

 >>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.

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.)

Thanks,
Graham