Well,
I like this. I'm still not sure I'd use it ;) (see my previous thoughts on the
toy nevow implementation), but I like the syntax. I'm not going to pretend to
know what you're doing to get that to work, but if it works as advertised, I'd
give it a try. I'm also under the impression that this (unlike the toy nevow
thing) would be rewritten at import time, so the performance hit would be no
worse than PTL... Am I right?
Jason
Quoting Graham Fawcett :
> Hi everyone,
>
> 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.
>
> What I'd like to do is add a block-level syntax to PTL. The ability to
> define blocks of HTML/XML as explicit blocks in Python code would
> increase readability and maintainability.
>
> Here's an example of a possible extended-PTL syntax:
>
>
> from extension_tags import * # some tag definitions
> import my_database
>
> people = my_database.get_people()
> title = 'List of all people'
>
> # a custom block definition, using a str() expression
> alert = 'div style="color: red;"'
>
> HTML: # HTML is a tag instance
> HEAD:
> TITLE:
> title
> LINK(rel='stylesheet', type='text/css',
> href='/main.css')
> BODY:
> H1:
> title
> P:
> 'This is a list of the '
> len(people)
> 'people defined in the sample application.'
>
> alert:
> "Kids, don't try this at home!"
>
> TABLE(_class='nice_table'): # or some other class-hack
> TR:
> TH('surname')
> TH('first name')
> TH('email')
> TH('--actions--')
> for person in people: # still have Python blocks!
> TR:
> TD(person.surname)
> TD(person.firstname)
> TD(person.email)
> TD:
> A(href='%d/edit' % person.id):
> 'Edit'
> A('Delete', # *args-style tag syntax
> href='%d/delete' % person.id)
>
> Notes:
>
> * whenever a block-level statement is encountered, and the
> statement does not begin with a Python keyword (e.g. 'def', 'if',
> 'while', ...), then the modified parser will treat the statement
> as an "extended PTL statement".
> * The upper-casing in my example is purely optional, I just think it
> lends to readability.
> * the expression in an ePTL opening-line should resolve to either an
> object that has methods 'open_block' and 'close_block', or it must
> be a string; if not, str() will be used to stringify it.
> * If the expression resolves to an object, then its open_block()
> method is called before the nested lines are evaluated. After the
> nested lines are evaluated, then the close_block() method is
> called. Presumably these would write opening and closing tags.
> * Otherwise, the str() of the epxression is used as the opening-tag
> content, and the first word of the str() is used as the closing
> tag. Thus the expression 'BODY id="foo":' would lead to an opening
> tag and a closing tag .
> * Inlining: Optionally, the str() of a tag object itself should
> render as a single tag. In the example above, "A" is used both as
> a block expression but also as an inline expression. (This has
> nothing to do with the block-parsing proposal really, it's just is
> a nice application of it.)
> * 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.
> * This type of syntax would work well with HTML and XML. XML
> namespaces, CDATA and comment blocks, etc. should not pose any
> problems, and should be codeable with the same regular syntax.
> Theoretically it could do plain-text as well, but that's not the
> target application.
>
> Code that uses this syntax is, of course, not Python. However, tools
> that work well with Python syntax (such as Emacs python-mode) will
> probably recognize the block-level syntax, leading to easy composition
> and editing. While it isn't Python, it's much more like Python than,
> e.g. TAL or Cheetah is.
>
> 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.
>
> I'm probably going to write this up, and give it a try in a few little
> applications. But if you could spare a minute to critique the idea, I'd
> really appreciate your comments.
>
> Thanks,
>
> Graham
>
> _______________________________________________
> Quixote-users mailing list
> Quixote-users@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/quixote-users
>