[FEATURE REQUEST] comment at the top of DTML Methods and Documents
Hi, I think that putting an HTML comment at the top of DTML Methods and DTML Documents just like the one at the top of Python Scripts would be VERY useful. (at the bottom it would be useful too, I really don't care) This comment would just give the object meta-type and the preferred object id. This would allow for ZShell, and possibly other products or external software, to dump (ZShell's dump command) and restore objects (ZShell's wget command) transparently: Say I dump a DTML Method, it's saved as pure DTML source, because I just write the document_src() output to an external file. Now I reload it into the ZODB using the wget command, which in fact uses the mime type to determine what object type to create: There's a problem because it's impossible to differentiate a DTML Method from a DTML Document, because both are detected with the same mime type: text/html So I think such a comment would help when importing objects into the ZODB in unusual ways (not from the ZMI). I've not yet tried using webdav or ftp with Zope, but I suppose this would help there too. Any comments ? If you don't agree, please could you explain why ? Thanks in advance. Jerome Alet
I disagree with this idea a lot. Someone should not be able to view the page source for the webpage and see the objects involved. I would rather see this done using dtml-comments or information stuck in the property sheets since that doesn't get sent to the web browser. Another reason not to do this is if you have a page that gets composed of a hundred or more objects having comments display for each on on the in the page source is a fairly major amount of data sent to the web client for no purpose. Designing the webpages of tomorrow http://webme-eng.com Designing the MMORPGS of tomorrow http://worldforge.org On Thu, 24 May 2001, Jerome Alet wrote:
Hi,
I think that putting an HTML comment at the top of DTML Methods and DTML Documents just like the one at the top of Python Scripts would be VERY useful. (at the bottom it would be useful too, I really don't care)
This comment would just give the object meta-type and the preferred object id.
This would allow for ZShell, and possibly other products or external software, to dump (ZShell's dump command) and restore objects (ZShell's wget command) transparently:
Say I dump a DTML Method, it's saved as pure DTML source, because I just write the document_src() output to an external file.
Now I reload it into the ZODB using the wget command, which in fact uses the mime type to determine what object type to create:
There's a problem because it's impossible to differentiate a DTML Method from a DTML Document, because both are detected with the same mime type: text/html
So I think such a comment would help when importing objects into the ZODB in unusual ways (not from the ZMI).
I've not yet tried using webdav or ftp with Zope, but I suppose this would help there too.
Any comments ?
If you don't agree, please could you explain why ?
Thanks in advance.
Jerome Alet
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Thu, May 24, 2001 at 02:23:51PM -0600, kosh@aesaeion.com wrote:
I disagree with this idea a lot. Someone should not be able to view the page source for the webpage and see the objects involved. I would rather see this done using dtml-comments or information stuck in the property sheets since that doesn't get sent to the web browser. Another reason not
in the property sheet it would be of no value, since external editors/tools can't deal with Zope's property sheets. I mean when you edit the raw object's content, you must have something to say to Zope to import this object as this meta-type when using special tools, and when you use the ZMI you can always override this. But I don't want the comment to be really present at the top of the document source, I just want Zope to add it when downloading the source (so just in document_src())
to do this is if you have a page that gets composed of a hundred or more objects having comments display for each on on the in the page source is a fairly major amount of data sent to the web client for no purpose.
think about Python Scripts: when you edit them the comment are not there, but if you want to download the source, the comments are there AND USEFUL. When you do View Source in your browser, it's different from calling document_src() on the server. I really don't see any problem or difficulty there. bye, Jerome
On Thu, 24 May 2001, Jerome Alet wrote:
think about Python Scripts: when you edit them the comment are not there, but if you want to download the source, the comments are there AND USEFUL.
but also syntactically correct and meaningful to python. I can see extending this into: <dtml-comment> Meta-Type: DTML Document Property X: Foo </dtml-comment> at the beginning but that's rather baroque and akward. Also, this would just work for DTML content, what about future formats? Page templates? Perl scripts? Sounds like we would need to reproduce this mechanism for every language out there, and what happens when you have content that does *not* have an explicit comment syntax, like structured text? You'd have to invent one, or wedge an existing one (like # python style comments) into a format that wasn't intended to handle it. -Michel
From: "Michel Pelletier" <michel@digicool.com>
but also syntactically correct and meaningful to python. I can see extending this into:
<dtml-comment> Meta-Type: DTML Document Property X: Foo </dtml-comment>
at the beginning but that's rather baroque and akward. Also, this would just work for DTML content, what about future formats? Page templates?
Page Templates already have something like this, at least when there are errors. Compile-time and macro errors are inserted into the source text as specially formatted HTML comments, and stripped out when the text is saved to Zope. It would be a small step from there to what Jerome is describing. I've already changed Zope 2.4 Scripts to do the same with their errors, and was considering extending it to DTML. It is extremely handy when you're forced to deal with the complexities of an object database as though it were a filesystem. Scanning every arbitrary text block saved as a new Zope object through FTP or WebDAV for every possible variant of this scheme could become unwieldy, but maybe not. Combine it with extension-based discrimination, and a PUT factory, and it wouldn't be so bad. Cheers, Evan @ digicool & 4-am
I think that putting an HTML comment at the top of DTML Methods and DTML Documents just like the one at the top of Python Scripts would be VERY useful. (at the bottom it would be useful too, I really don't care)
Sorry I disagree.
This comment would just give the object meta-type and the preferred object id.
Whats a preferred object id, is that different to the objects actual id?
There's a problem because it's impossible to differentiate a DTML Method from a DTML Document, because both are detected with the same mime type: text/html
Yes but you can access the object's type through its meta_type. I think the problem is you're trying to solve the inability of a client tool, by fiddling with some of the base parts of zope objects. Yes some changes can be made to Zope, but really its the client that needs fixing. What next, would you want the comment to include property x? Then you have to change the comments. Then a new object comes along and has to use these comments. All these properties on an object are already available through many different protocols, use one of them to find out what you want rather than repeating data on an object. Your analogy of writing comments in python script doesnt make sense since I can write comments in a dtml method or document using <dtml-comment>. Perhaps you are asking for something else? -- Andy McKay
participants (5)
-
Andy McKay -
Evan Simpson -
Jerome Alet -
kosh＠aesaeion.com -
Michel Pelletier