Re: [Zope] Traversable DTML methods
Ian Sparks writes:
It seems strange to me that SQLMethods are traversable out of the box and "normal" DTML methods are not.
It seems to me that traversable DTML methods would be useful (to me this means DTML Methods with parameters). Your DTML Methods have (keyword) parameters.
From DTML: "<method>(_.None,_,param1=value1, param2=value2, ....)" From HTML: "<URL to method>?param1=value1¶m2=value2&...." everything after "?" is URL(plus)encoded.
Dieter
Kevin Said :
Hmm... what does it mean, exactly, to "traverse a DTML method"? DTML Methods don't have subobjects, so it seems like you're basically trying to look up other objects or information via information passed in the URL. That seems like the kind of program logic that is much cleaner in python and that people are trying to keep out of DTML. DTML really does start getting ugly and hairy when you try to put complex logic in it. <<
Dieter Said :
Your DTML Methods have (keyword) parameters.
From DTML: "<method>(_.None,_,param1=value1, param2=value2, ....)" From HTML: "<URL to method>?param1=value1¶m2=value2&...." everything after "?" is URL(plus)encoded. <<
Dieter is right, DTML methods can get parameters from the URL but they don't do it in the same way as SQLMethods and that, to answer Kevins question, is what I mean by making DTML Methods "traversable" (apologies if my terminology is off). I'd like to be able to pass a parameter to a "members" DTML method with a syntax like : www.mysite.com/members/ian which is much nicer than : www.mysite.com/members?user=ian which is what Dieter suggests.
From my Zope-newbie perspective I don't see that allowing parameters to DTMLMethods, framed as part of the URL is any more complex than what goes on with SQLMethods but I admit this may be because I have not grasped the Zen of Zope.
- Ian Sparks. ----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Ian Sparks" <isparks@wmute.u-net.com> Cc: <zope@zope.org> Sent: Sunday, June 11, 2000 7:03 PM Subject: Re: [Zope] Traversable DTML methods Ian Sparks writes:
It seems strange to me that SQLMethods are traversable out of the box and "normal" DTML methods are not.
It seems to me that traversable DTML methods would be useful (to me this means DTML Methods with parameters). Your DTML Methods have (keyword) parameters.
From DTML: "<method>(_.None,_,param1=value1, param2=value2, ....)" From HTML: "<URL to method>?param1=value1¶m2=value2&...." everything after "?" is URL(plus)encoded.
Dieter _______________________________________________ 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 )
----- Original Message ----- From: "Ian Sparks" <isparks@wmute.u-net.com> To: "Dieter Maurer" <dieter@handshake.de>; "Kevin Dangoor" <kid@kendermedia.com> Cc: <zope@zope.org> Sent: Sunday, June 11, 2000 6:05 PM Subject: Re: [Zope] Traversable DTML methods
Dieter is right, DTML methods can get parameters from the URL but they don't do it in the same way as SQLMethods and that, to answer Kevins question, is what I mean by making DTML Methods "traversable" (apologies if my terminology is off).
I'd like to be able to pass a parameter to a "members" DTML method with a syntax like :
Ahh... Your terminology was correct. I was thinking more in terms of the traversing functionality offered by PythonMethods. If it's doing nothing more than passing parameters, that seems fine to me. I was thinking more of getting into these ugly scenarios where you do things like: <dtml-call "REQUEST.set('params', _.string.split('/', url_remainder))"> <dtml-if "params[0] == 'foo'"> ...do something </dtml-if> etc. That would get evil fast. The one reason that may still exist for not making DTML Methods traversable as you're suggesting would be if you want to call a DTML Method within the acquisition context of another... something that some people may want to do (I never have though). If a DTML Method chops off everything that follows in the URL, then that remaining part of the URL can't be used for acquiring other methods. Kevin
<< The one reason that may still exist for not making DTML Methods traversable as you're suggesting would be if you want to call a DTML Method within the acquisition context of another... something that some people may want to do (I never have though). If a DTML Method chops off everything that follows in the URL, then that remaining part of the URL can't be used for acquiring other methods. << I don't see DTML Methods as "chopping off" the URL so much as "consuming" parts of it. SQL Methods have this behaviour now : www.mysite.com/flavor/cherry/showme Where "flavor" is a SQL Method which takes a single parameter "cherry" and "showme" is a DTML Document which makes some use of the flavor SQL Method. In this instance "flavor" consumes the next part of the url because it is looking for a parameter and when it is finished hands on control to the next, unconsumed part of the URL "showme". Notice though that I have to have the "showme" DTML Method to actually display the results. If "flavor" was a parmeterized DTML Method my URL could become : www.mysite.com/flavor/cherry which makes more sense to me. In this case the "flavor" DTML Method would consume the "cherry" parameter, perhaps call some SQL Method to get the data for the "cherry" display and then display itself. If the parameters could have defaults then I could have URL's like : www.mysite.com/members/ian/ www.mysite.com/members/ian/home www.mysite.com/members/ian/preferences www.mysite.com/members/ian/todo Where "members" is a DTML method which takes parameters <username>,<subsite> (default : "home") and decides what to display based on the parameters passed. This allows my "users" to become virtual (by which I mean DB-based). I can do the last 3 URL's now with SQL Methods ("home", "preferences" and "todo" become DTML documents or methods which are aquired) but I can't do the first URL because SQLMethods don't do any rendering for display. Well, that got rambling but it lays my argument out in full I think. - Ian.
Hi all I just created a 'Traversable DTML Document' product. You can get it here: http://www.zope.org/Members/shalabh/TraversableDTMLDoc/ It is a ZClass product based on the TraversableMixin (which you'll have to install anyway) to be found here: http://www.zope.org/Members/shalabh/TraversableMixin/ And yes, you can use the mixin to create any ZClass that is 'traversable'. For example create a new ZClass with DTMLMethod and the TraversableMixin as bases and you have a 'Traversable DTML Method' (that's how I created the Traversable DTML Document). Mail me for any problems. Many thanks to Itamar for pointing me in the right direction, and to Ian for initiating this mindwave. Enjoy! Shalabh Ian Sparks wrote:
I don't see DTML Methods as "chopping off" the URL so much as "consuming" parts of it. SQL Methods have this behaviour now :
www.mysite.com/flavor/cherry/showme
Where "flavor" is a SQL Method which takes a single parameter "cherry" and "showme" is a DTML Document which makes some use of the flavor SQL Method. In this instance "flavor" consumes the next part of the url because it is looking for a parameter and when it is finished hands on control to the next, unconsumed part of the URL "showme".
Notice though that I have to have the "showme" DTML Method to actually display the results. If "flavor" was a parmeterized DTML Method my URL could become :
www.mysite.com/flavor/cherry
which makes more sense to me. In this case the "flavor" DTML Method would consume the "cherry" parameter, perhaps call some SQL Method to get the data for the "cherry" display and then display itself.
If the parameters could have defaults then I could have URL's like :
www.mysite.com/members/ian/ www.mysite.com/members/ian/home www.mysite.com/members/ian/preferences www.mysite.com/members/ian/todo
Where "members" is a DTML method which takes parameters <username>,<subsite> (default : "home") and decides what to display based on the parameters passed.
This allows my "users" to become virtual (by which I mean DB-based). I can do the last 3 URL's now with SQL Methods ("home", "preferences" and "todo" become DTML documents or methods which are aquired) but I can't do the first URL because SQLMethods don't do any rendering for display.
Well, that got rambling but it lays my argument out in full I think.
- Ian.
_______________________________________________ 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 )
Shalabh Chaturvedi wrote:
I just created a 'Traversable DTML Document' product. You can get it here: http://www.zope.org/Members/shalabh/TraversableDTMLDoc/
It is a ZClass product based on the TraversableMixin (which you'll have to install anyway) to be found here: http://www.zope.org/Members/shalabh/TraversableMixin/
And yes, you can use the mixin to create any ZClass that is 'traversable'. For example create a new ZClass with DTMLMethod and the TraversableMixin as bases and you have a 'Traversable DTML Method' (that's how I created the Traversable DTML Document).
Mail me for any problems.
I downloaded TraversableMixin. Comments: 1) You used Windows path names (backslashes) in the tar file. It does not unpack cleanly on Unix variants. 2) You forgot to include TraversableDocument.py, but did include TraversableDocument.pyc. 3) You may be interested in using OFS.Traversable, checked in to the tree just a few minutes ago. (Note that TraversableMixin and Traversable.py perform non-overlapping functions.) Shane
Shane Hathaway wrote:
I downloaded TraversableMixin. Comments:
1) You used Windows path names (backslashes) in the tar file. It does not unpack cleanly on Unix variants.
2) You forgot to include TraversableDocument.py, but did include TraversableDocument.pyc.
Hmm.. the TraversableDocument.pyc shouldn't be there either. It is the remnant of some experimentation I was doing prior to creating the mixin. Yuck! Ugly packaging - my bad. I have fixed both the above problems and uploaded it again.
3) You may be interested in using OFS.Traversable, checked in to the tree just a few minutes ago. (Note that TraversableMixin and Traversable.py perform non-overlapping functions.)
I looked at it online only. I'll spend some time in the code and the interfaces wiki to grok this new traversal stuff. It seems like if the TraversableMixin is also made an OFS.Traversable, it will be traversable not only just through the url but also through other mechanisms that OFS.Traversable makes possible. For example, calling a TraversableMixinZClass with parameters foo and bar might be possible like this: <dtml-var "MyTraversableMixinObject/foo/bar">
Shane
Thanks for your comments, Shalabh PS: 'Traversable' doesn't seem like a very good name for what the mixin does, especially after the new OFS.Traversable also has the same name. Anyone have any good ideas?
participants (5)
-
Dieter Maurer -
Ian Sparks -
Kevin Dangoor -
Shalabh Chaturvedi -
Shane Hathaway