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
I don't see DTML Methods as "chopping off" the URL so much as "consuming"
parts of it. SQL Methods have this behaviour now :
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
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 :
Where "members" is a DTML method which takes parameters <username>,<subsite>
(default : "home") and decides what to display based on the parameters
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.
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -