Hello, I am trying to reference an object within the following hierarchy: ..../links/19991108205246/amethod amethod: <dtml-with links> <dtml-with _['19991108205246']> <dtml-var title> </dtml-with> </dtml-with> I have tried several permutations on the "19991108205246" thing without success .. could anyone explain the semantics of the various DTML constructs like .. foo _[foo] "_[foo]" "_['foo']" I think I read through most of the docs but there is no extensive description of the exact syntax (not even in the DTML ref).. Please correct me if I am wrong .. thanks Oliver
Oliver Frommel wrote:
could anyone explain the semantics of the various DTML constructs like ..
foo _[foo] "_[foo]" "_['foo']"
First of all, we have the difference between this: <dtml-var foo> and this: <dtml-var "foo"> These things actually mean: <dtml-var name="foo"> and <dtml-var expr="foo"> which makes things somewhat clearer. <dtml-var foo> tries to show the object *named* foo. Showing an object means translating it to HTML representation; in case of a property this simply means the value of the property, in case of a DTML method this means executing the DTML statements and returning the HTML result. <dtml-var "foo"> does something else; it tries to evaluate the python expression 'foo'. So you could say "foo + bar" or whatever. Now, we'll get to _. Some ids in Zope which are valid in Zope are not valid variable names in Python. Basically, Python variable names must start with an underscore or a letter, and may contain letters, underscores and numbers. Python variables may not contain '-' or '.', however, as they have special meanings in Python. As an aside, I sometimes wonder if it hadn't been a better design decision to disallow any non-Python name as a Zope id. The advantage of the current scheme is that you can make objects with ids with 'foo.pdf' which will result in a nice download, but perhaps a separate 'alias' name for objects like that would've been a better idea. I don't know. Maybe in Zope 3. ;) So, sometimes you'd still like to access variables which contain special characters. 'sequence-item' is such a weird freak; I seriously don't know what possessed whomever came up with it not to call it 'sequence_item' as it'd make a lot of DTML look a *lot* cleaner. Luckily, '_' comes to the rescue. '_' is a special magic variable which is always accessible in DTML, and it contains in a dictionary all the variables in the current 'namespace' (and thus it would contain 'foo' and also 'sequence-item'. You get to the elements of the dictionary in the normal Python way, with the [] subscript: <dtml-var "_['sequence-item']"> Note that we want the variable with the name 'sequence-item', so we have to put quotes around it (we use single quotes as we used double quotes around the whole expression). If we *hadn't* put quotes around sequence-item, it would've looked for the variable with a name equal to the *contents* of 'sequence-item', whatever that may be. We can exploit this in some cases. Imagine that it depends on certain conditions whether we want to show variable 'foo' or 'bar'. In fact, we've set the variable 'hoi' with the name of the variable we want to display: <dtml-call "REQUEST.set('hoi', 'bar')"> Alternatively we could've used the 'let' tag around it all: <dtml-let hoi="'bar'"> .. </dtml-let> (we need to put extra quotes around 'bar' here because the let tag expects an expression, and this expression is a string). Now, when we want to display any variable that's currently in 'hoi', we use the _ trick: <dtml-var "_[hoi]"> This will evaluate to: <dtml-var "_['bar']"> which is the same as: <dtml-var "bar"> so that accomplishes our trick.
I think I read through most of the docs but there is no extensive description of the exact syntax (not even in the DTML ref).. Please correct me if I am wrong
Though there is documentation, there are plenty of sections of DTML which remain rather dark and mysterious. More documentation needs to be written. :) I hope this helped! Regards, Martijn
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> --Oliver
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
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 (I think i read that somewhere else in the docs, similar to the DTML ref: "title_or_id and title_and_id methods are applied to the folder containing the document. The example illustrates the use of var tags to insert the results of method calls. The variables document_id and document_title simply return the id and title of the document.") but then, when I use this piece of code I get only the title of folder A: <dtml-with A> <dtml-var title><br> <dtml-with B> <dtml-var document_title> </dtml-with> </dtml-with> --Oliver
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
Martijn Faassen wrote: [DTML ranting]
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. :)
Okay, I found out that the feedback is appearing, but on zope-dev, which probably is the right place for it given the way this thread is going. So look there! 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:
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()">
My wish for Zope 2.1 - add sequence_item as an alias of sequence-item. -- Itamar - itamars@ibm.net
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
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. Cheers, Evan @ 4-am
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
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 am 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
Paul Everitt wrote:
I've been following this thread with interest, albeit from within the air raid bunker. Martijn seems to have touched a nerve. :^)
I must be in touch with the Zope community, or something. :)
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.
Hm, not me, probably. No time, no time.. Good idea though.
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.
Right, to look at anything from a newbie's perspective can be very enlightening.
Though I agree with Andrew that the problem isn't just DTML, that seems to be a locus.
Yes. I think Zope's design as a whole is elegant and *does* use unifying concepts everywhere (such as acquisition). The system has conceptual integrity and generally this is respected during development. I believe however that in some places, especially the DTML area, this conceptual integrity is currently being harmed. With me this tends to raise the 'Redesign' flag, but it tends to get raised rather quickly with me anyway.
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'm glad you can recognize that. Open source rulzez! :)
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...
Yes, definitely understood. Luck and hard thought would definitely be necessary. In the mean while other fixes will be necessary, as any ngDTML project will need a lot of time.
I *really* hope we get some traction on what to do here.
Me too. Regards, Martijn
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
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. 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 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. 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. 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? My grump pill should be wearing off soon... -- | Don Porter dgporter@erols.com | | "Some days you just can't get rid of a bomb!" | | -- Adam West as BATMAN | |______________________________________________________________________|
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
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
Don Porter 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. -Michel
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
Stuart 'Zen' Bishop wrote:
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().
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? -Michel
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
participants (9)
-
Bruce Elrick -
Don Porter -
Evan Simpson -
Itamar Shtull-Trauring -
Martijn Faassen -
Michel Pelletier -
Oliver Frommel -
Paul Everitt -
Stuart 'Zen' Bishop