Hi Ian,
Ian Bicking wrote:
As for ZSQL methods, well they're hard work to get up to speed with, but they are fabulous - as much as anything a template driven SQL generation system, which can be very powerful, and which suits my approach to development much more than would an ORM system.
I never had a problem getting up to speed with them, but I have found them hard to maintain, especially when maintaining other people's code.
I do make a point of keeping things simple, and using a relatively small number of tried and tested patterns. Reading your Blog, it's clear you are doing things "downstream" of the database which are more complex than I am. I try to address as much complexity as possible in the RDBMS itself, and keep the complexity of what I need to do in Zope under control in doing so.
It's way to easy to Just Add Another Method, and soon you have an impossible number of SQL Methods laying about with little way to figure out what's what. And then there's a bunch of little things, but I've ranged on those parts before (http://blog.ianbicking.org/z-sql-rant). It has a lot to do with a combination of through-the-web development, DTML, and Acquisition that makes it very difficult for me to work in. Good practices help, but even then I find the result frustrating.
I've never used DTML outside of ZSQL methods - I was lucky enough to learn ZPT first, so perhaps that's why I found them harder to get up to speed with.
I do agree about the risk of "Just Add Another Method", but consciously sitting down and refactoring several methods into one (I find my rapidly multiplying methods tend to be variations on a theme) reduces the count quite quickly. In the process, I generally also find I am doing work in ZSQL which would be better done in the RDBMS, which also tends to make things simpler.
WRT Acquisition, the risk of picking up a value in error concerns me, so I'm as methodical as possible about using an expression rather than just a name - I use Formulator to validate my forms, and a validation script which writes the parameters for ZSQL to a named dictionary in the request. The ZSQL methods read from that dictionary, and I make it all as explicit as possible.
I'm not in a position (yet!) to have either the time or the skill to write many of the building blocks of my applications from scratch - I come at the problem from the business end of the spectrum, and all my technical efforts so far have gone into developing a simple(-ish!) methodology which allows me to glue together the building blocks that Zope gives me in a reliable and intelligible way.
However, I am gong to hit a wall soon in that not enough of the logic for my taste is driven by the logic of the dB schema (I guess this is what you refer to as a lack of database introspection?) - but Zope / ZSQL are hardly alone in that. My options seem to be to work much more extensively in Python (which is inevitable as my skills and style develop), or to create something which can spit ZSQL methods out based on reading the schema, and highlight/propose changes to them as the schema is updated (which may be less than ideal, but could solve my immediate problems). Looking much more closely at ORMs will be part of finding my direction on that front, but I'm not sure how appropriate they are for me.
Given that the various flavours of SQL do such a poor job of implementing the relational model articulated by Codd & co. over 30 years ago (I'm with Fabian Pascal - http://www.dbdebunk.com/ - on this), we are stuck working with much more grievous limitations than any ZSQL methods impose! Yes, there is plenty of room for improvement - but ZSQL remains a powerful tool in it's proper context, I think. FWIW, given that vintage of the code in ZSQL methods, I think they have aged pretty well.
I'll be interested to see what, if anything, shows up in later versions of Zope - but for now (for me) it's a solid foundation to build on as it is.
--
Regards,
PhilK
Email: [EMAIL PROTECTED] / Voicemail & Facsimile: 07092 070518
"it's very hard to talk quantum using a language originally designed to tell other monkeys where the ripe fruit is" - Lu-Tze
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
