Dieter, Thanks for your reply. Direct Traversal is very limited - it works only for ZSQL method that returns one record. It is just a hack It returns a Record object, not even a Results: query/1 and query?ID=1 return diffent things. I could probably attach a Brain to a ZSQL method to merge data but I think that would be solving th problem from the wrong angle. The solution I am looking for would make data in the Zope Folder and data in the database (or other source) appear in the same way to ZMI and to scripts. Igor -----Original Message----- From: Dieter Maurer Sent: Tue 7/23/2002 5:46 PM To: Elbert, Igor Cc: zope@zope.org Subject: Re: [Zope] Data-Aware Folder Igor Elbert writes: > ... > Problem: > ... > Now let's say that some data is stored in DBMS or other place outside the > ZODB. We know how to get it (e.g. ZSQL) but Zope mechanics would not work > anymore. I would have to say http://localhost/Org/Address/get?org_id=ENRON > or http://localhost/Org/Contact/Address/get?org_id=ENRON&contact_id=Smith > since "ENRON" and "Smith" are now just the values in the database. Which is > not bad except I loose many of Zope's nice features: acquisition for once. Look at "Direct Traversal" (of ZSQL methods). I think, you find something in the Zope Book. If not, look at the "Advanced" tab of ZSQL methods. Dieter
Elbert, Igor writes:
... The solution I am looking for would make data in the Zope Folder and data in the database (or other source) appear in the same way to ZMI and to scripts. Maybe, you should look at ZPattern or better its successor (I think, it's called TransWarp).
Dieter
I looked at ZPatterns and TransWarp before and did not like them. ZPatterns seem too heavy for the outcome. IMHO, the concept is good - implementation is convoluted. TransWarp is not ready. If it is going to be anything like ZPatterns, by the time the Zope community groks it, the package creators will abandon it and move to something else. But that's the topic for another discussion. -----Original Message----- From: Dieter Maurer [mailto:dieter@handshake.de] Sent: Wednesday, July 24, 2002 4:03 PM To: Elbert, Igor Cc: zope@zope.org Subject: RE: [Zope] Data-Aware Folder Elbert, Igor writes:
... The solution I am looking for would make data in the Zope Folder and data in the database (or other source) appear in the same way to ZMI and to scripts. Maybe, you should look at ZPattern or better its successor (I think, it's called TransWarp).
Dieter
Igor Elbert wrote:
I looked at ZPatterns and TransWarp before and did not like them. ZPatterns seem too heavy for the outcome. IMHO, the concept is good - implementation is convoluted. TransWarp is not ready. If it is going to be anything like ZPatterns, by the time the Zope community groks it, the package creators will abandon it and move to something else.
Indeed ;-) Maybe check out: http://cvs.zope.org/Products/AdaptableStorage/ cheers, Chris
Chris, Thanks for the pointer - AdaptableStorage looks interesting. I wonder if Shane's OSCON presentation about it is available. Regards, Igor -----Original Message----- From: Chris Withers [mailto:chrisw@nipltd.com] Sent: Friday, July 26, 2002 4:47 AM To: Igor Elbert Cc: Dieter Maurer; zope@zope.org Subject: Re: [Zope] Data-Aware Folder Igor Elbert wrote:
I looked at ZPatterns and TransWarp before and did not like them. ZPatterns seem too heavy for the outcome. IMHO, the concept is good - implementation is convoluted. TransWarp is not ready. If it is going to be anything like ZPatterns, by the time the Zope community groks it, the package creators will abandon it and move to something else.
Indeed ;-) Maybe check out: http://cvs.zope.org/Products/AdaptableStorage/ cheers, Chris
Igor Elbert wrote:
I looked at ZPatterns and TransWarp before and did not like them. ZPatterns seem too heavy for the outcome. IMHO, the concept is good - implementation is convoluted. TransWarp is not ready. If it is going to be anything like ZPatterns, by the time the Zope community groks it, the package creators will abandon it and move to something else.
Before you give up on ZPatterns completely, look at Steve Spicklemire's examples: http://www.zope.org/Members/sspickle/DumbZPatternsExample http://www.zope.org/Members/sspickle/SQLZPatternsExample1 http://www.zope.org/Members/sspickle/SQLZPatternsExample2 We've been using ZPatterns extensively in a number of apps and it has given us a lot of joy. It is the best framework Zope _currently_ has for data abstraction and it is really not that complicated - it's just missing some documentation. In the available docs to much is said about what it can do for you and very little about how to do the simple things - one just have to know what pieces to wire together. (Maybe I need to write a howto if anybody is interested) We have extended ZPatterns in a number a ways to make life really really easy of which the two most interesting examples are: 1. We created a SQL DataManager (it's called a Rack in ZPatterns) that automatically creates all the SQL needed to store a object in a RDB and creates the binding code. 2. We made ZPatterns skinnable like the CMF, making it really easy for 3rd party developers to customize ZPatterns apps. This solved one major flaw in ZPatterns for us and has given us the best of both worlds. Just doing this immediately extended ZPatterns lifetime by a mile. We'll probably release the above in a week or two if there's any interest ;-) And of course, the undertones of Igor's message is as desperate as ours - we wan't to build on a framework that will last for at least a couple of years and we need it now. In the mean time we now our desires will change when Zope 3 comes along because we'll want to do things the Zope 3 way :-) -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za
-----Original Message----- From: Roché Compaan [mailto:roche@upfrontsystems.co.za] Sent: Saturday, July 27, 2002 8:59 AM To: Igor Elbert; Chris Withers Cc: zope@zope.org Subject: RE: [Zope] Data-Aware Folder Roché Compaan wrote:
Igor Elbert wrote:
I looked at ZPatterns and TransWarp before and did not like them. ZPatterns seem too heavy for the outcome. IMHO, the concept is good - implementation is convoluted. TransWarp is not ready. If it is going to be anything like ZPatterns, by the time the Zope community groks it, the package creators will abandon it and move to something else.
Before you give up on ZPatterns completely, look at Steve Spicklemire's examples:
http://www.zope.org/Members/sspickle/DumbZPatternsExample http://www.zope.org/Members/sspickle/SQLZPatternsExample1 http://www.zope.org/Members/sspickle/SQLZPatternsExample2
I have looked at them, in fact these examples turned me off from ZPatterns. I read their detailed description in Steve's book ("Zope: WAD&CM") and thought that I am missing something. Then I installed them and realized that I got it right. I just do not like the approach. In the introduction to ZPatterns Steve writes about aspects of a high-quality code: 1.simplicity 2.elegance 3.right choices of what to include into implementation 4.limited scope of object's responsibility I agree with all four but (in my eyes) ZPatterns do not fit any of the above criteria. It would be interesting to cleanly rewrite the DumbZPatternsExample without ZPatterns and compare. I also wonder if TransWarp/PEAK is mature enough to implement the intricate relationships between Doers, Deliverables, and ToDos. It should be - TransWarp mailing list is busy with selecting the package name and logo. ;)
We've been using ZPatterns extensively in a number of apps and it has given us a lot of joy. It is the best framework Zope _currently_ has for data abstraction and it is really not that complicated - it's just missing some documentation. In the available docs to much is said about what it can do for you and very little about how to do the simple things - one just have to know what pieces to wire together. (Maybe I need to write a howto if anybody is interested) We have extended ZPatterns in a number a ways to make life really really easy ............... We'll probably release the above in a week or two if there's any interest ;-)
I agree that ZPatterns is the "best framework Zope _currently_ has for data abstraction". As a new Zope user I think it's pretty sad. Maybe I am wrong - it would be great to see your add-ons (esp. skinnable solution) and maybe some better examples of ZPatterns usage. Best regards, Igor
Roché Compaan wrote:
Igor Elbert wrote:
I looked at ZPatterns and TransWarp before and did not like them. ZPatterns seem too heavy for the outcome. IMHO, the concept is good - implementation is convoluted. TransWarp is not ready. If it is going to be anything like ZPatterns, by the time the Zope community groks it, the package creators will abandon it and move to something else.
Before you give up on ZPatterns completely, look at Steve Spicklemire's examples:
http://www.zope.org/Members/sspickle/DumbZPatternsExample http://www.zope.org/Members/sspickle/SQLZPatternsExample1 http://www.zope.org/Members/sspickle/SQLZPatternsExample2
I have looked at them, in fact these examples turned me off from ZPatterns. I read their detailed description in Steve's book ("Zope: WAD&CM") and thought that I am missing something. Then I installed them and realized that I got it right. I just do not like the approach. In the introduction to ZPatterns Steve writes about aspects of a high-quality code: 1.simplicity 2.elegance 3.right choices of what to include into implementation 4.limited scope of object's responsibility
I agree with all four but (in my eyes) ZPatterns do not fit any of the above criteria. It would be interesting to cleanly rewrite the DumbZPatternsExample without ZPatterns and compare.
I had some reservations in mentioning the examples above - it again does to much to absorb when you are looking at it for the first time. I'm tempted to ask you why you think ZPatterns does not hold to the criteria above (because I still think it does) but I know how annoyed I was with the amount of time I had to spend to just get my head around my first ZPatterns app. With the help of mailing list I persisted. In hindsight, documentation could have solved this. In essence a ZPatterns app consists of your classes, Specialists that organises your app around object interfaces and class-level services and finally Racks which are the data managers that talk to your database. What is wrong with a design like this? I'm definately not a ZPatterns evangelist, but this is my grub: In the last month or so I noticed all kinds of Zope forum products seeing the light, mainly because people seem to have different storage requirements. If we had a Squisdot that incorporated a framework that proparly delegated storage decisions, plus CMF skins then more community effort could have been directed at the same product.
I also wonder if TransWarp/PEAK is mature enough to implement the intricate relationships between Doers, Deliverables, and ToDos. It should be - TransWarp mailing list is busy with selecting the package name and logo. ;)
Btw, PEAK incorporates a lot of the design ideas found in ZPatterns. PEAK storage depends on ZODB4 and python 2.2 metaclasses so it will probably only be usable with Zope 3.
We've been using ZPatterns extensively in a number of apps and it has given us a lot of joy. It is the best framework Zope _currently_ has for data abstraction and it is really not that complicated - it's just missing some documentation. In the available docs to much is said about what it can do for you and very little about how to do the simple things - one just have to know what pieces to wire together. (Maybe I need to write a howto if anybody is interested) We have extended ZPatterns in a number a ways to make life really really easy ............... We'll probably release the above in a week or two if there's any interest ;-)
I agree that ZPatterns is the "best framework Zope _currently_ has for data abstraction". As a new Zope user I think it's pretty sad. Maybe I am wrong - it would be great to see your add-ons (esp. skinnable solution) and maybe some better examples of ZPatterns usage.
If you keep an open mind for a little while longer I'll try to finish a howto with an example this week. If it still fails your immediate expectations, then we'll just have to wait ... -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za
Roché, I was re-writing zPatterns example without zPatterns when I saw your angry comment in zPatterns mail-list about people who dislike zPatterns without explaining why. So here is my zPatterns rant: We clearly need something to represent our [relational] data in Zope. Theoretically it should be something simple since the task is very common and is solved frequently. I was very excited when I found zPatterns. It looked like the solution. It was a little strange that judging by the noise on the Internet (mail-lists, including the one dedicated to zPatterns) few people use it. Well, dogs do not always eat the dog food. On the other hand it's usually a sign. So I did my reading on zPatterns: Racks, Sheets, PlugIns, SkinScript, Triggers and so on. Occam would break his razor... Then I looked at the examples. I was surprised that with so much work I get so little. On top of everything else the example implementation did not look very elegant. Let's go over the simple use case based on the ToDo example (http://www.zope.org/Members/sspickle/DumbZPatternsExample). Imagine we have a "concept" - Doer - the person with id and email. To deal with it zPatterns way I need first to create a Doer Specialist zClass. Now, I have a problem with it: why? From my point of view Products are for meta-classes and tools. Last week there was a discussion on this list and it turned out that many people put business logic into Products but I do not like it. I see Products as infrastructure. I think Folder makes a good Product, Doer does not. I have dozens of concepts like Doer that are all data sources (tables, services, etc), I do not want to create a zClass/Product for every new one. In the ToDo example ZClass-es have some methods inside. When a Specialist is instantiated some other methods are added so you have to jump back in forth to figure out how things work. Now I need to write some data access methods. Which ones? Well, any. OK, I write some zSQLs and put them within Specialist. If later I have another data source I will have to replace my zSQLs with some other methods. What did I get from zPatterns in return for my hard work? Not much. Back to our Doer. I just wrote the same ToDo example without zPatterns. http://www.zope.org/Members/ielbert/PoorMansZPatternsExample/PoorMansZPatter nsExample.zexp - it can be imported into any Zope Folder. It uses Gadfly but should work with any database. Please keep in mind that I am a newbie and had to learn DTML just for the purpose of this exercise - I wanted to keep my example similar to the original. In real life I would use ZPT and pyscripts but it's not important. Also, to make example simpler I did not use Transparent Folders that I usually use to cleanly separate UI from my data access methods. I am very curious how Zope gurus would solve the same task. I created a table in my database called Doer. Then I created a Folder in Zope called, naturally, Doer. This Folder will be my Specialist - it will know all there is to know about Doer. I wrote a generic "get" zSQL that relies on the fact that the Folder is named the same as the table. Folder can have its own get method but if it follows the naming convention it doesn't have to. Then I wrote generic Page Template that takes results of any zSQL methods and displays them as XML (not included with an example but can be found at http://www.zope.org/Members/ielbert/zsql2zpt) Now, for a new concept (e.g. ToDo) all I have to do is to create a regular empty Zope Folder and I can immediately query it. Assuming all my tables/data-sources/racks have an ID attribute of the same type I wrote a bunch of generic methods. Of course, each Folder (Specialist) can overwrite generic methods with it's own implementation but I enjoy the immediate gratification: I create an empty Folder and right away I get some basic functionality. No Products, no efforts, no hands. Later, basic methods can be generated the Znolk way but when proper framework is defined, writing zSQL is a pretty simple task. I can also generate a set of Folders based on my DB schema but I see not problem in creating Folders manually. What do zPatterns offer to implement one-to-many and many-to-many relationships? SkinScripts? I am big fan of Demeter's Principle, which is written all over zPatterns. That's why I was surprised when I saw in the example ToDo, Doer and Deliverable intermixed within Specialists. Let's connect Doer and ToDo. Within Doer Folder I created ToDo subfolder. I gave it property "join" to indicate that it's a Folder responsible for dealing with To-Dos in a Doer context. Of course there is a ToDo Folder that knows nothing about Doer and just a Specialist for ToDo. I think it's a pretty clear separation. In other words just by providing a set of requirements for the Folders, Methods, Racks, and Attribute naming we can easily build primitive "Data-Aware" Folders. What is the value added by zPatterns? I am not sure if I made myself clear. I hope your example and how-to will show me the better way to use zPatterns. Until then I am going to expand an approach used in my example. I appreciate any comments or suggestions. Thanks, Igor -----Original Message----- From: Roché Compaan [mailto:roche@upfrontsystems.co.za] Sent: Tuesday, July 30, 2002 1:56 AM To: Igor Elbert; Chris Withers Cc: zope@zope.org Subject: RE: [Zope] Data-Aware Folder
Roché Compaan wrote:
Igor Elbert wrote:
I looked at ZPatterns and TransWarp before and did not like them. ZPatterns seem too heavy for the outcome. IMHO, the concept is good - implementation is convoluted. TransWarp is not ready. If it is going to be anything like ZPatterns, by the time the Zope community groks it, the package creators will abandon it and move to something else.
Before you give up on ZPatterns completely, look at Steve Spicklemire's examples:
http://www.zope.org/Members/sspickle/DumbZPatternsExample http://www.zope.org/Members/sspickle/SQLZPatternsExample1 http://www.zope.org/Members/sspickle/SQLZPatternsExample2
I have looked at them, in fact these examples turned me off from ZPatterns. I read their detailed description in Steve's book ("Zope: WAD&CM") and thought that I am missing something. Then I installed them and realized that I got it right. I just do not like the approach. In the introduction to ZPatterns Steve writes about aspects of a high-quality code: 1.simplicity 2.elegance 3.right choices of what to include into implementation 4.limited scope of object's responsibility
I agree with all four but (in my eyes) ZPatterns do not fit any of the above criteria. It would be interesting to cleanly rewrite the DumbZPatternsExample without ZPatterns and compare.
I had some reservations in mentioning the examples above - it again does to much to absorb when you are looking at it for the first time. I'm tempted to ask you why you think ZPatterns does not hold to the criteria above (because I still think it does) but I know how annoyed I was with the amount of time I had to spend to just get my head around my first ZPatterns app. With the help of mailing list I persisted. In hindsight, documentation could have solved this. In essence a ZPatterns app consists of your classes, Specialists that organises your app around object interfaces and class-level services and finally Racks which are the data managers that talk to your database. What is wrong with a design like this? I'm definately not a ZPatterns evangelist, but this is my grub: In the last month or so I noticed all kinds of Zope forum products seeing the light, mainly because people seem to have different storage requirements. If we had a Squisdot that incorporated a framework that proparly delegated storage decisions, plus CMF skins then more community effort could have been directed at the same product.
I also wonder if TransWarp/PEAK is mature enough to implement the intricate relationships between Doers, Deliverables, and ToDos. It should be - TransWarp mailing list is busy with selecting the package name and logo. ;)
Btw, PEAK incorporates a lot of the design ideas found in ZPatterns. PEAK storage depends on ZODB4 and python 2.2 metaclasses so it will probably only be usable with Zope 3.
We've been using ZPatterns extensively in a number of apps and it has given us a lot of joy. It is the best framework Zope _currently_ has for data abstraction and it is really not that complicated - it's just missing some documentation. In the available docs to much is said about what it can do for you and very little about how to do the simple things - one just have to know what pieces to wire together. (Maybe I need to write a howto if anybody is interested) We have extended ZPatterns in a number a ways to make life really really easy ............... We'll probably release the above in a week or two if there's any interest ;-)
I agree that ZPatterns is the "best framework Zope _currently_ has for data abstraction". As a new Zope user I think it's pretty sad. Maybe I am wrong - it would be great to see your add-ons (esp. skinnable solution) and maybe some better examples of ZPatterns usage.
If you keep an open mind for a little while longer I'll try to finish a howto with an example this week. If it still fails your immediate expectations, then we'll just have to wait ... -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za
On Tue, 2002-08-13 at 21:05, Igor Elbert wrote:
Roché,
I was re-writing zPatterns example without zPatterns when I saw your angry comment in zPatterns mail-list about people who dislike zPatterns without explaining why. So here is my zPatterns rant:
My intent is simply that the people using ZPatterns should at least try to write up best practices and bring forth some documentation that can help a newcomer. With that one can at least make an informed choice without needing to bump your head against concepts that are not familiar to you. I stirred, because I wanted to know if I'll be wasting my time (which I don't have a lot of) - evidently there is enough interest.
We clearly need something to represent our [relational] data in Zope. Theoretically it should be something simple since the task is very common and is solved frequently. I was very excited when I found zPatterns. It looked like the solution. It was a little strange that judging by the noise on the Internet (mail-lists, including the one dedicated to zPatterns) few people use it. Well, dogs do not always eat the dog food. On the other hand it's usually a sign.
So I did my reading on zPatterns: Racks, Sheets, PlugIns, SkinScript, Triggers and so on. Occam would break his razor... Then I looked at the examples. I was surprised that with so much work I get so little. On top of everything else the example implementation did not look very elegant.
Let's go over the simple use case based on the ToDo example (http://www.zope.org/Members/sspickle/DumbZPatternsExample). Imagine we have a "concept" - Doer - the person with id and email.
The example is meant to illustrate how to wire different parts of a ZPatterns app together - not to be taken as literally the best way to write a task scheduling app.
To deal with it zPatterns way I need first to create a Doer Specialist zClass. Now, I have a problem with it: why? From my point of view Products are for meta-classes and tools. Last week there was a discussion on this list and it turned out that many people put business logic into Products but I do not like it. I see Products as infrastructure. I think Folder makes a good Product, Doer does not.
I think this point of view is fundamentally different from most Product developers, not only from the ZPatterns way of doing things. Product developers have users and 3rd party developers in mind and see the ZODB as a point of collaboration and customisation. I don't think that you can hope to easily maintain a product that is basically a export of a couple of folders and methods that people import and customise locally.
I have dozens of concepts like Doer that are all data sources (tables, services, etc), I do not want to create a zClass/Product for every new one. In the ToDo example ZClass-es have some methods inside. When a Specialist is instantiated some other methods are added so you have to jump back in forth to figure out how things work.
But once you've figured it out one stops jumping around ;-)
Now I need to write some data access methods.
I don't - I wrote some extensions that generate SQL based on the schema of my class and only customise them if needed. If your app has a lot of classes and you have to write select/insert/update/delete queries for all of them this saves a lot of time.
Which ones? Well, any. OK, I write some zSQLs and put them within Specialist. If later I have another data source I will have to replace my zSQLs with some other methods. What did I get from zPatterns in return for my hard work? Not much.
In ZPatterns the properties of a single class can be populated from multiple datasources (LDAP, SQL, XML), properties on one class can be computed from that of another class and you get fine grained event handling. The point of ZPatterns is not to replace your SQL methods but to keep the layer that talks to whatever storage you opt for, separate from your application logic and this is just one of the benefits. Some people use it only for its fine-grained event management and collaboration services. I hope to have some documentation ready soon, and if you still find it unsatisfactory then at least you made an informed choice. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za
participants (5)
-
Chris Withers -
Dieter Maurer -
Elbert, Igor -
Igor Elbert
-
Roché Compaan