Now that Andrew Kuchling has open pandora's box by describing in explicit detail how to "roll your own" dtml tags, it might be a good time to discuss how to protect "tagspace". Otherwise, Digital Creations may produce future dtml tags that will stomp user-defined tag names, if this becomes a popular pastime. A simple convention for tag names prefixed by <whatever> could be reserved for user designation. This kind of convention would also be a documentation aid in reading .dtml files. Comments from the Z guys? For information on AMK's tag hack, see: http://starship.skyport.net/crew/amk/zope/new-tag.html I mention this as a disinterested 3rd party, because I'm not sure if a proliferation of dtml tags is desired. of-course-my-<BlinkSixTimesPerSecond>-tag-is-pretty-essential- and-should-really-be-included-in-the-standard-distribution-ly yr's, Jeff Bauer Rubicon, Inc.
Jeff Bauer writes:
Now that Andrew Kuchling has open pandora's box by describing in explicit detail how to "roll your own" dtml tags, it might be a good time to discuss how to protect "tagspace". Otherwise, Digital Creations may produce future dtml tags that will stomp user-defined tag names, if this becomes a popular pastime. A simple convention for tag names prefixed by <whatever> could be reserved for user designation.
It would be worth figuring out if adding tags is the way to go, though; perhaps it's better to simply create objects and call methods on them. But I'm paralyzed by the fact that I don't really know how to do that: if document A is being processed, and object B is in the same folder, how do I call one of B's methods through DTML? -- A.M. Kuchling http://starship.skyport.net/crew/amk/ But in our enthusiasm, we could not resist a radical overhaul of the system, in which all of its major weaknesses have been exposed, analyzed, and replaced with new weaknesses. -- Bruce Leverett, "Register Allocation in Optimizing Compilers"
Andrew M. Kuchling wrote:
methods on them. But I'm paralyzed by the fact that I don't really know how to do that: if document A is being processed, and object B is in the same folder, how do I call one of B's methods through DTML?
Use an expr-type #var: <!--#var "B.method()"-->
"Andrew M. Kuchling" wrote:
Jeff Bauer writes:
Now that Andrew Kuchling has open pandora's box by describing in explicit detail how to "roll your own" dtml tags, it might be a good time to discuss how to protect "tagspace". Otherwise, Digital Creations may produce future dtml tags that will stomp user-defined tag names, if this becomes a popular pastime. A simple convention for tag names prefixed by <whatever> could be reserved for user designation.
It would be worth figuring out if adding tags is the way to go, though;
There are many cases where they are a good way to go. The acid test is whether adding a new tag would significantly reduce the amount of DTML code needed for a common task.
perhaps it's better to simply create objects and call methods on them.
I certainly wouldn't invent a tag just to do that.
But I'm paralyzed by the fact that I don't really know how to do that: if document A is being processed, and object B is in the same folder, how do I call one of B's methods through DTML?
<!--#var "B.some_method()"--> Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Jeff Bauer wrote:
Now that Andrew Kuchling has open pandora's box by describing in explicit detail how to "roll your own" dtml tags,
BTW Andrew, thanks for getting started on this. I owe you a detailed review. It's on my to-do list!
it might be a good time to discuss how to protect "tagspace". Otherwise, Digital Creations may produce future dtml tags that will stomp user-defined tag names, if this becomes a popular pastime. A simple convention for tag names prefixed by <whatever> could be reserved for user designation.
This kind of convention would also be a documentation aid in reading .dtml files.
Comments from the Z guys?
Here are a number of somewhat random comments: - I don't think that there will be *so* many new tags written that there is a large danger of a conflict. There *is* some danger, so your point is certainly worth raising. - New tags need not be put in the global DTML tag-space. There are basically two ways to register tags: - Add an entry to DocumentTemplate.String.commands (Andrew described this) - Subclass String (or some other DTML class like HTML) and provide a commands registry that combines the base commands with your custom ones. The second approach doesn't affect the global tag registry. We used the second approach in Z SQL Methods (formerly known as Aqueduct). SQL methods use a subclass of DocumentTemplate.HTML to render SQL. This subclass adds several tags that are specifically designed to make generation of SQL simpler. See http://www.digicool.com/site/Aqueduct/Aqueduct.html#pgfId=930928 - It's likely that people will come up with cool new tags that should be made globally available. If you feel especially paranoid, then it wouldn't hurt to use a naming convention: <!--#jim.var ......--> - There may someday be a way to define new tags and make them available through acquisition. For example, maybe someday you'll be able to define a new tag object and insert it in a folder. Templates used in the folder or sub-folders would be able to use the new tag. This is just speculation. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (5)
-
Andrew M. Kuchling -
Jeff Bauer -
Jim Fulton -
Jim Fulton -
Ty Sarna