[ZPT] zpt 1.0 feedback

Martijn Pieters mj@digicool.com
Mon, 9 Apr 2001 16:00:54 +0200


On Mon, Apr 09, 2001 at 11:27:11PM +0900, Joseph Wayne Norton wrote:
> I would like to provide some feedback regarding the zpt 1.0 release.
> As a start, we really like the direction taken by the ZPT product and
> look forward to using it further.
> 
> Here is our current set of issues:
> 
> # zpt/zope with go live
> 
> a. we tried using the webdav features of go live with zope but ran
> into some trouble.  go live was not able to see or edit the raw PT
> source via webdav mode.  either go live or zpt/zope would cause zope
> to render the document and then overwrite the PT source with the html
> output.  i haven't spent enough time yet to investigate the exact
> source of the trouble.  ftp mode was fine.

This is because WebDAV uses normal 'GET' requests to retrieve documents
(just like pointing your browser at an object). Use the -W switch on z2.py
to start an extra 'WebDAV Source' server that will only serve the source
code of DTML and ZPT objects on a seperate port number.

> b. we tried integrating some existing dtml/python methods with a zpt
> but ran into the trouble of the handling of "." in the object names in
> zope and go live not understanding (for example) that "index_html" is
> really html. probably a pure zpt solution with standard suffixes
> (.html,etc.) might be fine.  a design or style guide of good practices
> on using zope and go live together would be helpful.

The same guidelines apply for many other WebDAV and FTP editors, like
DreamWeaver and other tools. HTMLKit is so far the only HTML tool I was
able to get to open suffix-less objects in it's own editor (via FTP).

> # zpt/zope
> 
> a. html preview mode generates a URL (<name>/source.html) for browsing
> the html source.  Due to the additional directory in the name path, we
> were having trouble with broken images.  Part of my goal for using zpt
> is to allow for "demo" html to be equally viewable inside zope and
> outside as external files.  I would prefer to minimize these issues.

Ai. I'll leave this to Ethan et al.

> b. we were not able to render the following zpt templates:
> 
> ------------------------------------------------------------------ 
> <html> 
> <head> 
>     <title>tag test</title> 
> </head> 
> <body bgcolor="#FFFFEE"> 
> <table border="1" cellspacing="0" cellpadding="0" bgcolor="white"> 
>     <tr> 
>         <td tal:content="string:<b>I WANT TO BE BOLD!!!</b>">DUMMY 
>         </td> 
>     </tr> 
> </table> 
> </body> 
> </html> 
> ------------------------------------------------------------------ 
> 
> The above template is modifed and stored as the following document:
> 
> ------------------------------------------------------------------ 
> <html> 
> <head> 
>     <title>tag test</title> 
> </head> 
> <body bgcolor="#FFFFEE"> 
> <table border="1" cellspacing="0" cellpadding="0" bgcolor="white"> 
>     <tr> 
>         <td tal:content="string:&lt;b&gt;I WANT TO BE BOLD!!!&lt;/b&gt;"> 
> DUMMY 
>         </td> 
>     </tr> 
> </table> 
> </body> 
> </html> 
> ------------------------------------------------------------------ 
> 
> Is this a feature or a limitation?

That would be a feature. First of all, you can't use '<' and '>' in
attribute values, so they are escaped for you. Secondly, unless you mark
the content as 'structure' you are dealing with text that will get special
characters escaped. See the TAL spec on the 'content' keyword.

If you change the attribute to read:

  tal:content="structure string:&lt;b&gt;I WANT TO BE BOLD!!!&lt;/b&gt;"

the correct HTML will be inserted.

> c. TALES: what is the policy for allowing (or disallowing) nested
> single and double quotes in a string TALES expression?  I haven't
> checked yet, but I'm assuming the python TALES expression is identical
> to the python handling of nested quotes.

Don't know, bu I see a problem with using '"'s here. You could try and use
HTML quotes here though.. (disclaimer: I didn't check this at all).

> d. TAL: is possible to construct an else/elsif construct using the
> condition statement?

Nope, not unless you use multimple condition-marked tags that complement
each other. This is under discussion in another thread on this list
though.

> e. TALES: can you provide a few more examples describing the "here"
> Optional Name?

'here' comes out best when your template is acquired into another part of
the tree. 'here' then applies to the object at the top of the acquisition
stack, like a Folder object. Using 'here' makes sure you get your
attributes and methods from the correct object. Compare this to 'context'
in Python Scripts.

> f. TALES: i'm not clear on the meaning or usage of the "modules"
> Optional Name?

Neither am I. I don't see it implemented in the source either..

> g. TALES: the "request" Optional Name is available but what about
> "response"?

You should be able to access that with request/RESPONSE.

> i. It would be nice to be able to specify have a "default" TALES
> expression type for an entire PT document (or having some other ways
> of helping to remove some of the additional typing effort required by
> zpt).

I think the explicitness was a design goal; it makes your source much more
readable.

-- 
Martijn Pieters
| Software Engineer  mailto:mj@digicool.com
| Digital Creations  http://www.digicool.com/
| Creators of Zope   http://www.zope.org/
---------------------------------------------