December 1999 - Zope-Dev

__cmp__ methods being ignored?
by Benno Rice 13 Dec '99

13 Dec '99

Hi, I posted about this to -dev a little while ago but received no response. I've got a Python class that I'm using in Zope, which defines it's own __cmp__ method. However this method doesn't appear to be being called when Zope tests for equality. Is this a bug or a feature? Is there some way I can get around this? The situation is that I have some of these objects in an array attribute of another object. If I try and compare an object that I Acquired to one that's in the list, it fails as I'm comparing an object of my type to one of ImplicitAcquirerWrapper. However, if my __cmp__ method were being used in the equality test, they'd match (I checked this). I also tried setting __repr__. This worked as I'd expect it to but didn't affect the equality test. Any help would be most appreciated, I really need to get this working. Many thanks. -- Benno Rice "No, no. We're *sweet* and XNFP Aries Dark Subculture- *innocent* evil bastards." friendly Internet Geek benno(a)netizen.com.au "Defend your joy"

1 0

Re: [Zope-dev] local/set
by Anthony Baxter 12 Dec '99

12 Dec '99

>>> "Phillip J. Eby" wrote > Let: allows read-only variables to be computed whose values are usable > within a DTML nesting scope. > > Local: allows writable variables to be computed, whose values are usable > and changeable within a DTML nesting scope. > > Set: singleton tag that changes the value of a "local" variable, as long as > it was defined in the innermost surrounding "local" block. Given the ongoing discussions over the difficulty of learning DTML, the general ugliness of DTML, and the discussion over what DTML is actually good for, isn't adding local/set just taking us further and further down the path of horror? It's already _way_ too easy to start with a simple DTML page, and then extend it and extend it beyond any sane limits until you end up with a perl-like morass of code. Utterly unmaintainable. Surely using PythonMethods or ExternalMethods is a much much better approach here, rather than bolting yet another bag onto the side of DTML. dtml-let solves a problem: it's a much nicer way to spell _.namespace() I'm not convinced that _.namespace is such a great idea in the first place. I've seen too much DTML that makes me cry when I have to go and maintain it - I'd actually like to see it made a bit more obvious when you should stop doing things in DTML. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

3 2

RE: I have a dream
by Sin Hang Kin 12 Dec '99

12 Dec '99

Thank you for pointing out PIA. I love its syntax (a little bit too lengthly). I have another idea, right now, zope is target html-oriented output. However, it shoudl be much easier if it just publish the oodb into xml and let the xsl and javascript to do the actual job for html presentation. for example, the tree tag could be much easier if it just export the tree in a xml segment. We could develope a set of convention and tools to render the tree into html. The respond would be much faster. What can be best is zope can be more structural oriented instead of layout oriented. Rgs, kentsin

1 0

RE: I have a dream
by Sin Hang Kin 12 Dec '99

12 Dec '99

Thank you for pointing out PIA. I love its syntax (a little bit too lengthly). I have another idea, right now, zope is target html-oriented output. However, it shoudl be much easier if it just publish the oodb into xml and let the xsl and javascript to do the actual job for html presentation. for example, the tree tag could be much easier if it just export the tree in a xml segment. We could develope a set of convention and tools to render the tree into html. The respond would be much faster. What can be best is zope can be more structural oriented instead of layout oriented. Rgs, kentsin

1 0

RE: I have a dream
by Sin Hang Kin 12 Dec '99

12 Dec '99

Thank you for pointing out PIA. I love its syntax (a little bit too lengthly). I have another idea, right now, zope is target html-oriented output. However, it shoudl be much easier if it just publish the oodb into xml and let the xsl and javascript to do the actual job for html presentation. for example, the tree tag could be much easier if it just export the tree in a xml segment. We could develope a set of convention and tools to render the tree into html. The respond would be much faster. What can be best is zope can be more structural oriented instead of layout oriented. Rgs, kentsin

1 0

RE: I have a dream
by Sin Hang Kin 12 Dec '99

12 Dec '99

Thank you for pointing out PIA. I love its syntax (a little bit too lengthly). I have another idea, right now, zope is target html-oriented output. However, it shoudl be much easier if it just publish the oodb into xml and let the xsl and javascript to do the actual job for html presentation. for example, the tree tag could be much easier if it just export the tree in a xml segment. We could develope a set of convention and tools to render the tree into html. The respond would be much faster. What can be best is zope can be more structural oriented instead of layout oriented. Rgs, kentsin

1 0

OFSP/Help problems
by Robin Becker 11 Dec '99

11 Dec '99

After some futzing around with CVS I managed to get the OFSP/Help directory to download. So I now see the help product in the Products Folder, but when I press on any of the help buttons I get an attribute error Help is unknown. -- Robin Becker

2 1

A simply question for help?
by Victor.Zhai＠ogilvy.com 11 Dec '99

11 Dec '99

Hi,all I want to display a new sub windows when click the following hyper link: <a href="#" onClick="window.open('<dtml-var absolute_url>/viewInfo>','','scrollbars=yes,width=640,height=430')"><dtml-var jobtitle></a> But you know that <dtml-var absolute_url> is like http://www.mydomain.com/object... ,And it is not a physical web page. How can I realize this? Give me some advice. Thanks in advance. "WorldSecure Server <ogilvy.com>" made the following annotations on 12/11/99 03:00:07 ------------------------------------------------------------------------------ Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of the Ogilvy Group shall be understood as neither given nor endorsed by it. ==============================================================================

2 1

Re: [Zope-dev] local/set
by Anthony Baxter 11 Dec '99

11 Dec '99

>>> Lalo Martins wrote > > dtml-let solves a problem: it's a much nicer way to spell _.namespace() > > You answer yourself. Hm, I should have made it clear that the post I made wasn't necessarily advocating one thing over another, but was more pointing out some things that I see as issues. > dtml-local is IMHO wrong. But dtml-set should be added, it fits > naturally. Or, in your words, is a much nicer way to spell > REQUEST.set. Is it? Not according to Phillip's original post - set is for changing values in the current local namespace. REQUEST.set is a different thing altogether. It doesn't worry me that REQUEST.set has to be spelled out explicitly, as this highlights quite clearly what's going on... (Aside: It seems to me that one of the more common uses of REQUEST.set that I've seen is as a sort-of global namespace that's useful for stuffing temporary values into. It's the reason I did the session code - (ab)using REQUEST in this way seemed bad. Ok, so the sessions also suffer from this a bit, but they're a nice fit for so many problems.) local/set seem like they need to both be in, or neither. Allowing set to modify any namespace strikes me as dangerous. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Re: local/set
by Stefan Langerman 11 Dec '99

11 Dec '99

Evan Simpson <evan(a)4-am.com> wrote: > "Phillip J. Eby" wrote: > > > Let: allows read-only variables to be computed whose values are usable > > within a DTML nesting scope. > > > > Local: allows writable variables to be computed, whose values are usable > > and changeable within a DTML nesting scope. > > > > Set: singleton tag that changes the value of a "local" variable, as long as > > it was defined in the innermost surrounding "local" block. > > Given these use-cases, consider the following variant of Let: > > <dtml-let x="1+1" person: firstname=" 'fred' " weight="180"> > <dtml-var x>, <dtml-var firstname>, <dtml-var "person.weight"> > <dtml-call "person.set('weight', 185)"> > <dtml-var weight> > </dtml-let> > > That is, every variable set after a colon-terminated singleton 'foo:' is also > a mutable (through .set()) attribute of 'foo'. > > Cheers, > > Evan @ 4-am I agree that Let and Local would be redundant. Just set would be enough: <dtml-let x="hello"> <dtml-var x> <dtml-set x="world"> <dtml-var x> </dtml-let x> Also note the argument in the </dtml-let x> which might make things more readable if there are nested lets. If you just want to declare a variable (without a value), you could also say <dtml-let x>. And maybe we could even live without set if we extend the use of Let: <dtml-let x="hello"> <dtml-var x> <dtml-let x="world"> <dtml-var x> </dtml-let x> Personally, I prefer the first solution, but if we really want to avoid introducing new tags, just say that <dtml-let> sets the value of a local var, </dtml-let> unsets it... Another thing I would love to see is a clean way to pass parameters to dtml methods, instead of putting them in REQUEST. like: <dtml-var some_method args="arg1:val1,arg2:val2"> instead of: <dtml-call "REQUEST.set('arg1',val1)"> <dtml-call "REQUEST.set('arg2',val2)"> <dtml-var some_method>

1 0