On 4/11/02 7:55 AM, "Toby Dickenson" <[EMAIL PROTECTED]>

> On Thursday 11 April 2002 4:39 pm, Casey Duncan wrote:
>> Toby Dickenson wrote:
>> [snip]
>>> 4. Change dtml to not allow <dtml-var someNonIdempotentMethod>, although
>>> it should still allow <dtml-var "someNonIdempotentMethod()">
>> Ahhh!
>> How do you propose to do that? I see a lot of bruised foreheads
>> resulting from this...
> Really? <dtml-var someNonIdempotentMethod> only works with methods that take
> zero parameters (excluding self). The question is: how many zero parameter
> non-idempotent methods are there?
> I have only been able to find one such method in the current Zope cvs, and I
> get similarly optimistic results in my products.

Then you're lucky.  Usually, any time I see <dtml-var
"someNonIdempotentMethod()">, I immediately change it to the name lookup
call.  Don't blame me, I've been following this paradigm for years (since
before there were expr's in DTML).  I would hate to have to special case
those methods (which I use a lot, usually as accessors, ie:

def Summary(self):
    return self.title + self._description

A powerful feature of classic (pre-expr) DTML was the fact that you could
just use a name, and you didn't have to worry about whether <!--#var
Summary--> was a method or an attribute.  For people who have lots of DTML
and Python code based upon these assumptions, mass-breakage upon upgrading
would be a huge detractor against upgrading.  It's hard enough to move some
of our sites from Zope 2.3.3 to 2.5 or even 2.4.x.

Jeffrey P Shell 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to