[Zope-dev] ZSQL methods lookup vars in REQUEST only (why?)

[Paul Zwarts]

I figured that I could be relatively safe by using heavy sessioning.
First I started with SQLSession, and now CST... 

Tips I do:

1) Create all formbased applications by folders. In otherwords
/folder/Support   is actually the folder and you always put the root
logic into index_html

2) The index_html is the control base, that will call in methods which
are your forms. (This way crawlers see a directory with only 1 page
(methods are hidden AFAIK)) I always split the application into a
minimum of 4 pieces (index_html, form, validation form, output). For
multi-stage forms like a shop, the number is sitting around 10. 

3) Split all forms OUT into theses methods, but DON'T put the form tags
in that method. Keep them in the index_html so you cannot go directly to
a single page other than index_html and be able to submit. It basically
fragments everything to be unuseable by itself.

4) I use CoreSessionTracking VERY heavily. Using a skin based concept,
every pageload executes a sessionlogic method, which does switching. For
instance, when any kind of form is submitted, I set a sessionvariable
called ACTION to a value like 'check'. Then the index_html is sensitive
to this change, and will process the form ONLY if the form was submitted
through the whole process properly. I also use this validation technique
to check forms and feedback incompletenesss. If youre carefull, the
session variables cannot be modified outside of the process flow so you
ensure nothing funky is going on.

5) For things like my shop, prices are always checked and modified in
the ZSQL method itself. In other words, I use dtml inside the ZSQL
method to enforce cascade SQL calls. Like when a customer requests the
price of a product and decides to buy it, the price is stored in hidden
fields on the html page, but  it doesn't make a differene, becausse at
runtime, the ZSQL ethod does a second redundant retrieve when adding the
record, so the price value ALWAYS is what it should be and cant be
changed by any hack (short mucking with the code)

Its totally obvious the pure python would be good instead, but I'm not
very good at it yet, and can crank out dmtl much faster. 

Just some tips if anyone's interested...

Paul Zwarts


-----Original Message-----
From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org] On Behalf
Of Toby Dickenson
Sent: Thursday, October 11, 2001 2:43 PM
To: tim@iterationzero.com
Cc: Paul Zwarts; zope-dev@zope.org
Subject: Re: [Zope-dev] ZSQL methods lookup vars in REQUEST only (why?)


>>> Anyway, I propose that ZSQLMethods change and do variable lookups in
the
>>> entire namespace, not just the REQUEST object.  It seems to be a
simple
>>> enough change (at least it looks it) and I can submit the patches,
but
>>> the harder thing is to get people to agree that it is a change for
the
>>> better.

>Paul Zwarts wrote:
>
>> Just to play devil's advocate; It seems this way, that methods
pulling
>> non-specifically from namespace could allow ways to modify the result
if
>> someone paid close attention to whats going on...

Exactly right.

Even the guys at Zope.com dont pay close enough attention...
Historically this has been the source of several security holes.

Tim wrote:

>I agree.  However, this is true of all DTML.

That is true, and is the reason why dtml is inappropriate for any use
except trivial document templating. In other uses it is either buggy
(for the reason Paul mentioned) or very very ugly (because the author
knows about the potential bugs, and in dtml it is cumbersome to work
round them).

It is a pity that the current zope-newbie documentation presents dtml
as more than it is; as an essential part of "the zope way". 

Anyway, there are plenty of alternatives to those non-trivial uses of
dtml; Python Scripts, python products, CMF skins, etc. None of them
are quite as slick, but at least they work.

I dont know of a good alternative to SQLMethods, so I would prefer
that they not be 'broken' in order to maintain consistency with a
feature that many people recommend you should avoid.


Tim also wrote:

>The only argument that I have heard against it is that variables will
be
>found mysteriously through the stack and that this is harder to
>understand.  However, that just makes it inconsistent with all other
>DTML and therefore mysterious in its own way.

You are right that the mechanism for calling SQLMethods from DTML is
different to calling DTML from DTML, but the odd one out is DTML
calling DTML!

DTML calling a SQLMethod current behaves the same as DTML calling
PythonScript, pure python functions, extension class functions,  or an
external method.


Toby Dickenson
tdickenson@geminidataloggers.com

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )