[Zope-dev] [RFClet]: What about the request method and the client side trojan?

[Jeffrey P Shell]

On 4/11/02 7:55 AM, "Toby Dickenson" <tdickenson@geminidataloggers.com>
wrote:

> 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 
www.cuemedia.com