Oliver Frommel wrote:

Hi,

so why do these two pieces of code produce different results? (I thought they should print the same, according to the with-tag howto) (the second one prints the title of folder A twice)

<dtml-with A> <dtml-var title><br> <dtml-var "B.title"> </dtml-with>

<dtml-with A> <dtml-var title><br> <dtml-with B> <dtml-var title> </dtml-with> </dtml-with>

Hm, I actually don't know. Some parts of Zope semantics are too obscure in my opinion.. Anyway, it seems to matter if B is a Folder or a DTML Method/DTML Document. If it's a Folder, the second works as you'd expect, and you do get the same result as in the first. If it's not a folder, you get the acquired title from folder A instead (this explains the printing of the same title twice). What I don't understand is why this occurs; perhaps this is because the with tag only works with ObjectManagers (folders) and not with other objects? But this isn't documented anywhere. The bizarre thing is that this hack does give the expected (by you and me) result with DTML Documents: <dtml-with A> <dtml-in "(B,)"> <dtml-var title> </dtml-in> </dtml-with> What the 'in' tag does there is loop through a list containing just B. Now it does display B's title. What also gives the same result is this: <dtml-with A> <dtml-with "_.getitem('B')"> <dtml-var title> </dtml-with> </dtml-with> This may give us a clue on what's going on. The getitem() function looks up a name in the namespace, but does not call it. If B is called, we get the HTML result, which does not have any 'title' property. I think. You can verify this by checking what happens if you do: <dtml-with "'some test string'"> </dtml-with> I don't think it does anything; it just passes silently. If B however is looked up using getitem(), we *do* have a reference to the object, and the with tag does work as expected. I think this explains it, though I wonder why *folders* don't get 'called' and return strings. Some input on this from people more knowledgable than I am would be appreciated. It reflects badly on DTML that something so basic takes me such a long time figuring it out. After all I've been using DTML for almost a year now.. And I'm not stupid. :) Philosophical end rant: If I ever get the time I'd be tempted to work on a DTML 'cleanup' project. DTML is currently *far* too much like Perl and not enough like Python. *some* easy things are very easy, but as a consequence some other easy things become far too hard, or at least look far too complicated. You can spell the same thing in too many ways. The community encourages and praises additions for convenience (like the 'default' option, or the new extended &entity; syntax) but as a result DTML loses its conceptual integrity. It becomes too big and not easy to understand. I understand the argument that DTML shouldn't be used for complicated purposes, and that you should use Python. This is fine and good, but in practice people *do* use DTML for complicated purposes. ZClasses in fact encourage this. DTML should be more like Python. Luckily the Zope framework does allow new objects to be plugged in using something else than DTML, so not all hope is lost. :) Feedback on this rant would be appreciated. First-thing-I'd-get-rid-of-is-the-'_'-ly yours, Martijn

Oliver Frommel wrote:

...

What I don't understand is why this occurs; perhaps this is because the with tag only works with ObjectManagers (folders) and not with other objects? But this isn't documented anywhere.

I thought that (maybe) it has to do with the use of the title methods

Title properties are special in the case of DTML Methods for instance (which don't have any properties themselves), but I tested this with other properties and the same happened. :) In case people haven't seen it, I'd like to point people to my rant earlier in this thread. I'd like some feedback on this. :) Regards, Martijn

On Wed, 10 Nov 1999, Martijn Faassen wrote:

If I ever get the time I'd be tempted to work on a DTML 'cleanup' project. DTML is currently *far* too much like Perl and not enough like Python. *some* easy things are very easy, but as a consequence some other easy things become far too hard, or at least look far too complicated. You can spell the same thing in too many ways. The community encourages and praises additions for convenience (like the 'default' option, or the new extended &entity; syntax) but as a result DTML loses its conceptual integrity. It becomes too big and not easy to understand.

I understand the argument that DTML shouldn't be used for complicated purposes, and that you should use Python. This is fine and good, but in practice people *do* use DTML for complicated purposes. ZClasses in fact encourage this.

DTML should be more like Python. Luckily the Zope framework does allow new objects to be plugged in using something else than DTML, so not all hope is lost. :)

Feedback on this rant would be appreciated.

I'm with you 100%. It makes me feel like I'm programming a reverse polish calculator sometimes :-) A low-level user (one not confidant in writing external methods) shouldn't have use magic constructs like <dtml-var "_['sequence-item'].title_or_id()"> dtml-in is the main culprit - a synonyms for the magic variables that conform to python naming standards need to be created and the old ones depricated. Is there any reason why I should fix this and submit the patch for 2.1? (or 2.2?) Possibly REQUEST needs to be available through aquisition rather than having to be passed to everything. How about <dtml-python> print "<p>" print html_quote('''The <dtml-ver2> tag is executed, the code contained between the tags simply writing to standard out to produce the rendered version.''') print '''<p>This could be done either through stealing from the existing PythonMethods code if it can be proven to be as secure as DTML''' if untrusted_pythonmethods: print '''<p>An alternative approach would be to run the code using r_eval. A BastionClass wrapper would be used to protect access to objects - the code would initially only have access to the bastionised _ object, and all the getattr and getitem methods would aquire objects as normal, but return another bastion wrapper instead of the real object. <p>Of course, this may be how PythonMethods already works for all I know....''' print ''' <p>Currently, calling python functions needs to be done through the current namespace, with calls like _.string.split(...). This seems arse over tit - wouldn't it conceptually be better to use a prefix for aquisition? _.standard_html_header() for example - this makes it much clearer IMHO what is going on and easier to grasp. It might be too late in the day to change this however.''' </dtml-python> Is existing DTML good enough for 'simple' scripting? I think the current confusion threshold occurs when people start needing to pass parameters to methods (and the whole quoted and unquoted thing kicks in, and suddenly they have to understand about the _ namespace, and the magic variables to pass a DTML method to make it work). - Zen, who is still a bit grumpy today. ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen

Stuart 'Zen' Bishop wrote:

On Wed, 10 Nov 1999, Martijn Faassen wrote:

...

[deleted] I'm with you 100%. It makes me feel like I'm programming a reverse polish calculator sometimes :-)

A low-level user (one not confidant in writing external methods) shouldn't have use magic constructs like <dtml-var "_['sequence-item'].title_or_id()"> dtml-in is the main culprit - a synonyms for the magic variables that conform to python naming standards need to be created and the old ones depricated. Is there any reason why I should fix this and submit the patch for 2.1? (or 2.2?)

I thought, "What would it take to change sequence-item to sequence_item in Zope?" I did the following in my zope directory: # find . -name '*.py' -exec grep sequence-item {} \; -print 'sequence-item' -- The element. if sort=='sequence-item': self.sort='' ./lib/python/DocumentTemplate/DT_In.py <!--#in sequence-item--> <!--#var sequence-item--> <!--#/in sequence-item--> <!--#in sequence-item--> <!--#var sequence-item--> <!--#/in sequence-item--> ./lib/python/DocumentTemplate/DTtest.py <!--#var sequence-item--> value="<!--#in %s--><!--#var sequence-item--> <!--#endin-->">''' --><!--#var sequence-item-->\n<!--#/in--></textarea>''' <!--#if "_['sequence-item']=='%(id)s'"--> ><!--#var sequence-item--></option> ./lib/python/ZClasses/Property.py And then looked at the three files. I also used 'nm' in a simlary fashion on the .so files. I can't for the life of me figure out how the sequence-XXX variable are defined. The DT_In.py file certainly documents the variables, but I can't figure out how they are implemented. Maybe my lack of understanding of Python is the problem. Apologies if this belongs in zope-dev, but I'm not normally a developer type... Cheers... Bruce -- Bruce Elrick, Ph.D. Saltus Technology Consulting Group Personal: belrick@home.com IBM Certified Specialist Business: belrick@saltus.ab.ca ADSM, AIX Support, RS/6000 SP, HACMP

Evan Simpson wrote:

Bruce Elrick wrote:

...

And then looked at the three files. I also used 'nm' in a simlary fashion on the .so files. I can't for the life of me figure out how the sequence-XXX variable are defined. The DT_In.py file certainly documents the variables, but I can't figure out how they are implemented. Maybe my lack of understanding of Python is the problem.

DT_InSV.py defines 'sequence-item' and all of its dynamic friends and relatives (the ones which care about the current position within the sequence). The more static variants such as 'sequence-step-size' live in DT_In.py; each place in that file where you see "kw['sequence-something']=", one of these variables is being stuffed into the namespace.

Okay...but DT_InSV.py does not contain the string 'sequence-item'. In DT_In.py the only time that string exists in code is in this code snippet: if has_key('sort'): self.sort=sort=args['sort'] if sort=='sequence-item': self.sort='' I don't know much python but that bit of code does not seem to me to define that bit of DTML. Maybe 'sequence-item' is a special case... Anyway...I willing to leave it at that because I don't know my way around the source code. I was just curious. Strange voodoo magic :-) Thanks for your time, though... Bruce -- Bruce Elrick, Ph.D. Saltus Technology Consulting Group Personal: belrick@home.com IBM Certified Specialist Business: belrick@saltus.ab.ca ADSM, AIX Support, RS/6000 SP, HACMP

I've been following this thread with interest, albeit from within the air raid bunker. Martijn seems to have touched a nerve. :^) Here's what I'd like to see. Could someone post a recap of the discussion? I did this recently for the "Zope Front Door" thread and found it to be an invaluable exercise. Zope's usability needs to improve a LOT. I got a good dose of this when I taught a three day Zope course several months back. When you have to explain it to people, you really find out how baroque Zope can be. Though I agree with Andrew that the problem isn't just DTML, that seems to be a locus. DTML *is* being used in a way that violates its design (separation of presentation and logic). But at the same time we at DC lead the way on this violation, and aren't actively promoting viable alternatives. I'll say this about an ngDTML effort: good luck. The current quandry exists for a reason: there are a lot of tough design choices. That which is clear to the Python hacker is obtuse to the HTML newbie. That which is clear to the DTML developer is inefficient to the parser/renderer. That which is... I *really* hope we get some traction on what to do here. --Paul

Stuart 'Zen' Bishop wrote:

On Wed, 10 Nov 1999, Martijn Faassen wrote:

[snip my rant on DTML]

I'm with you 100%. It makes me feel like I'm programming a reverse polish calculator sometimes :-)

It makes me feel like I'm programming in Perl sometimes, and I don't want to know Perl. :) Perl's fine, great and dandy for other people I'm sure, it's just that *my* poor brain can't understand it and doesn't want to understand it.

A low-level user (one not confidant in writing external methods) shouldn't have use magic constructs like <dtml-var "_['sequence-item'].title_or_id()"> dtml-in is the main culprit - a synonyms for the magic variables that conform to python naming standards need to be created and the old ones depricated. Is there any reason why I should fix this and submit the patch for 2.1? (or 2.2?)

Is there any reason why not, you're asking? I don't see any reason why not to change them, but there just has to be one, otherwise it'd been done a long time ago, right?

Possibly REQUEST needs to be available through aquisition rather than having to be passed to everything.

Hm, I don't know if this would clear up the picture, as opposed to obfuscate things even more. It's true that even after a year I'm still vague on how to express the equivalent of <dtml-var name=foo> in a <dtml-var expr="what do I put here?">... I think I have accomplished it a couple of times, but forgot again. There should be a HOWTO or something..

How about <dtml-python>

In general something like this would make you lose the split between layout/templating issues (DTML) and more sophisticated programming issues (Python). Zope's idea is to keep them separate. I'm inclined to agree with this philosophy. Not that a system like this (PythonMethods that can behave a lot like DTML) wouldn't be nice by itself. I haven't kept track of PythonMethods recently so I don't know what it can do already right now. The problem is that DTML can become almost *more* difficult than the equivalent Python right now. Perhaps this is unavoidable due to the limited nature of DTML, but I think it can be improved in several areas still.

print "<p>" print html_quote('''The <dtml-ver2> tag is executed, the code

dtml-python tag, you mean? [snip example of Python DTML]

Is existing DTML good enough for 'simple' scripting? I think the current confusion threshold occurs when people start needing to pass parameters to methods (and the whole quoted and unquoted thing kicks in, and suddenly they have to understand about the _ namespace, and the magic variables to pass a DTML method to make it work).

I think this part of DTML could be cleaned up, or at least avoided in ngDTML. Regards, Martijn

Don Porter wrote:

On 11 Nov, Martijn Faassen wrote:

...

In general something like this would make you lose the split between layout/templating issues (DTML) and more sophisticated programming issues (Python). Zope's idea is to keep them separate.

If that is the case, then I think some of the introductory material describing Zope ought to make that clear.

I do think there *is* documentation that states this. Now where was it again..

When first examining Zope, I received the impression that knowledge of Python really wasn't necessary to use Zope. One document which gave me that idea was

http://www.zope.org/Resources/QA

But Zope users without lots of Python knowledge *can* use Zope for quite powerful things. Just with acquisition, HTML, and properties, and some limited DTML can get quite far. Especially if you use powerful products like Squishdot.

It seems to me though, that trying to make powerful use of Zope without learning and using Python is what takes us into the dark corners of DTML which are so difficult to use.

To do even *more* powerful things with Zope, you can use Python. And using Python is far far nicer than the dark corners of DTML, too. Unfortunately it is very tempting for everybody to press DTML into service it isn't intended for. That is why DTML has been developing in ways that make even its 'simple' subset have dark corners. That is what I was ranting about. It should be easier to use Python with Zope. PythonMethods promise a lot there. It should also be clearer when *not* to use DTML.

As someone trying to use Zope, I feel as if I've been misled. I may not be justified in feeling this way, but if the Zope creators want to hear voices from a frustrated newbie perspective, this is one of them.

I don't think you have been misled. Zope with DTML only is quite powerful.

While I'm on the soapbox, another thing about Zope which irks me is its gratuitous inconsistencies. I can't apply what I learn in one part of Zope to another part. In Folders, I can use "objectValues" to get a list of the objects contained in the folder. When I want to iterate over the Users in a User Folder, though, "objectValues" doesn't work. You have to go searching through the ZQR to see that you must use "getUserNames" instead. What's up with that?

Good question. I don't know about this one. I must say that in many cases the inconsistencies are absent and things do behave according to nice protocols in Zope. But Zope is obviously a work in progress. Perhaps you can list the inconsistencies you encounter and work with others to eliminate them, or at least document them?

My grump pill should be wearing off soon...

I hope so. :) Zope can be frustrating, but also tremendously rewarding. The rewards outweigh the frustrations manyfold in my opinion. But frustrations are frustrations, and so we'll work to get rid of them. Regards, Martijn

On Thu, 11 Nov 1999, Michel Pelletier wrote:

...

While I'm on the soapbox, another thing about Zope which irks me is its gratuitous inconsistencies. I can't apply what I learn in one part of Zope to another part. In Folders, I can use "objectValues" to get a list of the objects contained in the folder. When I want to iterate over the Users in a User Folder, though, "objectValues" doesn't work. You have to go searching through the ZQR to see that you must use "getUserNames" instead. What's up with that?

User Folders aren't Object Managers, so they don't contain any of the same object manager code as other foldoids.

Having User Folders look vaguely like and be named like other folders is just a simple error. Inconsistent, you are correct. But it's just a naming issue, they should have been called something else.

In particular, I believe LDAPAdaptor isn't folderish at all and GenericUserFolder will return quite different things if you call objectValues() rather than getUserNames(). ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen

On Fri, 12 Nov 1999, Michel Pelletier wrote:

...

In particular, I believe LDAPAdaptor isn't folderish at all and GenericUserFolder will return quite different things if you call objectValues() rather than getUserNames().

Yep. I think what we're really dealing with here are Authenticator objects. For historical (hysterical) reasons they'll probably allways be called User Folders.

How's that GenericUserFolder coming along?

I finished ZRadius yesterday, so my sites authentication is running happily. I have a few requests to add and a bit of tidying, and GenericUserFolder will be released (looks like today). ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen