I am working on a custom DTML tag (that I may unleash on the world when finished) that has brought to my attention an interesting feature of the DTML parser: It preparses everything in the block(s) between the start and end tags before the document containing the code is committed. My tag is a little different in that I don't want to put DTML inside it, therefore this parsing is undesirable. There is however one built-in tag that this is true for as well: <dtml-comment>. Many a thread has been burned about that issue. I propose a change to DT_String to allow a tag to turn off this preparsing feature. It should be easy enough to implement by adding a class attribute to the tag class such as disable_dtml_block_parsing = 1. Is this abhorrent to anyone? If not, I will make a patch for DT_String to support this. The beneficial side affect would be that <dtml-comment> could be "fixed" so that its contents need not be parsable anymore, just like every other language I know of. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
On Monday 22 January 2001 08:54, Casey Duncan wrote:
I am working on a custom DTML tag (that I may unleash on the world when finished) that has brought to my attention an interesting feature of the DTML parser:
It preparses everything in the block(s) between the start and end tags before the document containing the code is committed.
My tag is a little different in that I don't want to put DTML inside it, therefore this parsing is undesirable. There is however one built-in tag that this is true for as well: <dtml-comment>. Many a thread has been burned about that issue.
i've been bitten by this 'feature' as well. i hacked out a bad solution where i checked the length of the block, and raised an error if it was larger than one. but this didn't solve the problem that the nested dtml was still evaluated. which troubles me since i think it could be a security problem in the context of my tag.
I propose a change to DT_String to allow a tag to turn off this preparsing feature. It should be easy enough to implement by adding a class attribute to the tag class such as disable_dtml_block_parsing = 1. Is this abhorrent to anyone?
sounds good to me.
If not, I will make a patch for DT_String to support this. The beneficial side affect would be that <dtml-comment> could be "fixed" so that its contents need not be parsable anymore, just like every other language I know of.
cool. Kapil Thangavelu
Casey Duncan wrote:
If not, I will make a patch for DT_String to support this. The beneficial side affect would be that <dtml-comment> could be "fixed" so that its contents need not be parsable anymore, just like every other language I know of.
With your patch applied, will nested dtml-comment tags still work? <dtml-comment> Some code commented out <dtml-comment> Documentation in a comment </dtml-comment> Rest of code commented out </dtml-comment> -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
With your patch applied, will nested dtml-comment tags still work?
<dtml-comment> Some code commented out <dtml-comment> Documentation in a comment </dtml-comment> Rest of code commented out </dtml-comment>
-- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
In present form no. It also does not support block continuation tags. I will see what I can do about this. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
Casey Duncan wrote:
Steve Alexander wrote:
With your patch applied, will nested dtml-comment tags still work?
<dtml-comment> Some code commented out <dtml-comment> Documentation in a comment </dtml-comment> Rest of code commented out </dtml-comment>
-- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
In present form no. It also does not support block continuation tags.
I will see what I can do about this.
OK, I have developed a new patch that almost completely fixes this issue. In fact I am happier with it in general than my first patch. There is only one flaw, although you can nest comments inside of one another, and you can have any manner of broken dtml inside, if you open another comment tag inside it, it must be properly balanced or you will get a parse error. Here are some examples: These do not generate errors with my new patch: <dtml-comment> <dtml-if blah> </dtml-comment> <dtml-comment> </dtml-with> </dtml-comment> <dtml-comment> <dtml-asdfsadf> </dtml-comment> <dtml-comment> <dtml-comment> Blah Blah </dtml-comment> </dtml-comment> These do: <dtml-comment> <dtml-comment> </dtml-comment> <dtml-comment> <dtml-if foo> <dtml-comment> </dtml-if> </dtml-comment> </dtml-comment> I am a bit concerned that <dtml-comment> should ever generate errors at all, but this is certainly an improvement. Anybody have any thoughts? -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
Casey Duncan wrote:
OK, I have developed a new patch that almost completely fixes this issue. In fact I am happier with it in general than my first patch. There is only one flaw, although you can nest comments inside of one another, and you can have any manner of broken dtml inside, if you open another comment tag inside it, it must be properly balanced or you will get a parse error. Here are some examples:
<examples removed>
I am a bit concerned that <dtml-comment> should ever generate errors at all, but this is certainly an improvement. Anybody have any thoughts?
I'm very happy with the way you describe the patched tag works. I'll try it out when I return from the EuroZope meeting in Amsterdam. I don't think it is reasonable to try to catch unbalanced dtml-comment tags. In fact, I like the fact that it will raise an error if I leave them unbalanced. Thanks. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
participants (3)
-
Casey Duncan -
ender -
Steve Alexander