ZSQL methods lookup vars in REQUEST only (why?)
I've been asked too many times now by developers what is wrong when they call ZSQL Methods without passing parameters because their parameters are in the namespace. This seems to make sense to all new Zopers (and some older ones like myself) because all other DTML lookups are in the entire namespace. 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. 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. Consistency is much better for learning and for remembering, and DTML in ZSQL should work the same as DTML in DTML Methods, etc. Please consider this and abuse me as appropriate ;) Regards, Tim -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233
Hi Tim, 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... i.e The total price of your shopping cart before its sent to the transaction broker. It requires the programmer to keep even more close care that all variables generated at runtime are first cleaned and wiped so that this same REQUEST couldn't just be anticipated by someone who's interested. Or can you suggest a way around this? Thanks, Paul Zwarts -----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org] On Behalf Of Tim McLaughlin Sent: Thursday, October 11, 2001 1:30 PM To: zope-dev@zope.org Cc: Micah Martin Subject: [Zope-dev] ZSQL methods lookup vars in REQUEST only (why?) I've been asked too many times now by developers what is wrong when they call ZSQL Methods without passing parameters because their parameters are in the namespace. This seems to make sense to all new Zopers (and some older ones like myself) because all other DTML lookups are in the entire namespace. 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. 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. Consistency is much better for learning and for remembering, and DTML in ZSQL should work the same as DTML in DTML Methods, etc. Please consider this and abuse me as appropriate ;) Regards, Tim -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233 _______________________________________________ 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 )
I agree. However, this is true of all DTML. I mean, its just as true in DTML methods that might REQUEST.set the args to the ZSQLMethod. ie. they could be tricked into REQUEST.set(ing) a false total etc. because they lookup all of their variables in the namespace. Cheers, Tim Paul Zwarts wrote:
Hi Tim,
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... i.e The total price of your shopping cart before its sent to the transaction broker. It requires the programmer to keep even more close care that all variables generated at runtime are first cleaned and wiped so that this same REQUEST couldn't just be anticipated by someone who's interested.
Or can you suggest a way around this?
Thanks, Paul Zwarts
-----Original Message----- From: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org] On Behalf Of Tim McLaughlin Sent: Thursday, October 11, 2001 1:30 PM To: zope-dev@zope.org Cc: Micah Martin Subject: [Zope-dev] ZSQL methods lookup vars in REQUEST only (why?)
I've been asked too many times now by developers what is wrong when they call ZSQL Methods without passing parameters because their parameters are in the namespace. This seems to make sense to all new Zopers (and some older ones like myself) because all other DTML lookups are in the entire namespace.
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.
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.
Consistency is much better for learning and for remembering, and DTML in ZSQL should work the same as DTML in DTML Methods, etc. Please consider this and abuse me as appropriate ;)
Regards, Tim -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233
_______________________________________________ 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 )
-- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233
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
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 )
On Thursday 11 October 2001 07:29 am, you wrote:
I've been asked too many times now by developers what is wrong when they call ZSQL Methods without passing parameters because their parameters are in the namespace. This seems to make sense to all new Zopers (and some older ones like myself) because all other DTML lookups are in the entire namespace.
You can do this now by passing the namespace as an argument to the ZSQL method: <dtml-call expr="ZSQLMethod(_)"> Which works because ZSQL methods expect their first positionak argument to be a mapping object. If it is omitted, it uses REQUEST. Granted this is not the prettiest, but DTML isn't known for it asthetics 8^)
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.
Yes this would be a simple change. And it would break nearly every existing Zope application that uses ZSQL methods. Think of how many people use "id" as a field name in their tables...
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.
Actually this behavior has a parallel. ZCatalogs work the same way. By default they only check the REQUEST object for search arguments. That's not to say I like it. It makes necessary one of the most lothesome DTML statements: <dtml-call expr="REQUEST.set('foo',bar)">
Consistency is much better for learning and for remembering, and DTML in ZSQL should work the same as DTML in DTML Methods, etc. Please consider this and abuse me as appropriate ;)
Regards, Tim
I agree with you in principle, but I think that calling stuff from DTML will never be made intuitive. I do think much of the time (although certainly not all) ZSQL arguments are coming from REQUEST. So, assuming this is patched, it would necessitate things like: <dtml-with name="REQUEST"><dtml-call name="ZSQLMethod"></dtml-with> or <dtml-call expr="ZSQLMethod(REQUEST)"> for the majority of cases to make sure things come from REQUEST. This I think just trades one work-around for another... Actually I think calling DTML from DTML sucks rocks <dtml-call expr="DTMLMethod(_.None,_)"> anyone? /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
Going by the general rule that explicit is good and implicit is bad. I would disagree with this. ZSQL Methods do have some oddities in the lookup that seem strange, but making it more "magical" is a path to ruin. Cheers. -- Andy McKay.
participants (5)
-
Andy McKay -
Casey Duncan -
Paul Zwarts -
Tim McLaughlin -
Toby Dickenson