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