Phillip, I believe I have come to understand the basics of ZPatterns and would like to be sure I understand correctly, as well as help others understand also. I like to think of a specialist as a filing clerk. A manager comes to the clerk asking for an employee's dental records. Because of the way the company filing system was set up, however, the dental records aren't kept on a single slip of paper. The clerk has to compile the information from the employee's medical and insurance information. The manager doesn't care where the information is coming from, but needs the information on a standard dental record form. So the clerk compiles it and gives the manager the information on the correct form. In this example, the manager is the "application framework", the file cabinets are "racks", and once again the clerk is the "specialist". An application framework generally looks in database tables for objects of a specific type. The types of objects may include users, invoices, grades, etc. A rack is an abstract database table. The data can be stored in ZODB or in some other way, but the point is that a rack is a container for a list of objects of the same type. The basic functionality of a rack can be duplicated by creating a folder and populating it with methods that access a database table, then calling the methods of that folder rather than accessing the database directly. A specialist essentially provides views, or "sheets", of data from one or more racks. The information on a sheet is compiled from one or more sources and contains the precise information required of the application framework. If used correctly, the RIPP model makes integration of multiple Zope-based application frameworks relatively straightforward. This means that, for example, a Zope calendar product could gather date information from a Zope logging product, which of course knows nothing about calendars. Now, the above is what ZPatterns has been claiming all along. But what does it really mean? Well, if you think about it for a moment, the place where people usually want to integrate applications is at the database tables. For example, a database of users contains nothing more than name, login, and password. But what if we want to integrate a user authentication application with a billing application? The billing application looks for a different set of fields, such as account balance, payment due date, etc. and is not interested in the user's password. The obvious approach is to add more fields to the database table or create another table and join the two. A more flexible approach, however, is to abstract out the database table access, making the storage details irrelevant to the application. This has always been possible, but ZPatterns makes it easier. The other concepts in ZPatterns expand upon this model. I am still working on grasping them. ZPatterns also provides the "Plugins" architecture. Racks and specialists are derived from the plugins classes. I see plugins as being a concept that could be used by product authors who don't have a use for racks and specialists. I wonder whether plugins ought to be made a part of standard Zope. Shane
At 02:33 PM 6/11/00 -0600, Shane Hathaway wrote:
I believe I have come to understand the basics of ZPatterns and would like to be sure I understand correctly, as well as help others understand also.
[a lot of good stuff snipped]
The other concepts in ZPatterns expand upon this model. I am still working on grasping them.
Bravo! An exquisite introduction to the purpose of ZPatterns. May I post an edited version of your message to the ZPatterns Wiki, and make it or subsequently edited versions a part of the ZPatterns documentation? (With attribution, of course.)
ZPatterns also provides the "Plugins" architecture. Racks and specialists are derived from the plugins classes. I see plugins as being a concept that could be used by product authors who don't have a
use for racks and specialists. I wonder whether plugins ought to be made a part of standard Zope.
It certainly might be reasonable for them to be a package of their own, or to be a part of "standard" Zope, since PlugIns.py and its associated DTML files do not make use of any other part of ZPatterns. It is mostly a question of whether DC has an interest in making it a part of the library. I think it should probably wait, however, until it is a bit better documented and the few API bits that are still fluctuating settle down completely. I would also be interested in figuring out a way to register ZClasses as PlugIns; right now they have to be registered from Python.
"Phillip J. Eby" wrote:
At 02:33 PM 6/11/00 -0600, Shane Hathaway wrote:
I believe I have come to understand the basics of ZPatterns and would like to be sure I understand correctly, as well as help others understand also.
Bravo! An exquisite introduction to the purpose of ZPatterns. May I post an edited version of your message to the ZPatterns Wiki, and make it or subsequently edited versions a part of the ZPatterns documentation? (With attribution, of course.)
By all means! Thank you. The truth is that several of us at DC have had trouble making sense of it all, so I wrote it not only for the community, but DC and myself as well. :-)
It certainly might be reasonable for them to be a package of their own, or to be a part of "standard" Zope, since PlugIns.py and its associated DTML files do not make use of any other part of ZPatterns. It is mostly a question of whether DC has an interest in making it a part of the library. I think it should probably wait, however, until it is a bit better documented and the few API bits that are still fluctuating settle down completely. I would also be interested in figuring out a way to register ZClasses as PlugIns; right now they have to be registered from Python.
Ah, good point--I was planning on diving into ZClass machinery soon anyway. There must be a way to get ZClasses to behave better with mount points, and now plugins. Shane
Shane Hathaway wrote:
"Phillip J. Eby" wrote:
At 02:33 PM 6/11/00 -0600, Shane Hathaway wrote:
I believe I have come to understand the basics of ZPatterns and would like to be sure I understand correctly, as well as help others understand also.
Bravo! An exquisite introduction to the purpose of ZPatterns. May I post an edited version of your message to the ZPatterns Wiki, and make it or subsequently edited versions a part of the ZPatterns documentation? (With attribution, of course.)
By all means! Thank you. The truth is that several of us at DC have had trouble making sense of it all, so I wrote it not only for the community, but DC and myself as well. :-)
I just looked over the ZPatterns Wiki for Shane's explanation, but I can't find it. If it isn't there (hiding somewhere), perhaps I can add it from Shane's original email? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
"Phillip J. Eby" wrote:
At 02:33 PM 6/11/00 -0600, Shane Hathaway wrote:
I believe I have come to understand the basics of ZPatterns and would like to be sure I understand correctly, as well as help others understand also.
Feel free to flame me if I've got this wrong, but: I've read all the ZPatterns Wiki and I'm just taking tentative steps to playing with LoginManager. I think the concepts are very cool but I see two problems: 1. Too much jargon... by far... Lots of complicated words that are meanlingless to the layman and don't help to convey the concepts. This is compounded by the standard Zope problem of minimal documentation aimed at the advanced developer. Can someone who understadns this all take the time to write a ZPatterns guide to compliment the Wiki and maybe simplify or explain in great detail all the terms (especially the new ones that have popped up in the last few weeks)? 2. Feature runaway. It seems every day something new (and more confusing) has been added to ZPatterns. I think ZPatterns will only work if it is kept as simple and functional as possible. My view (bearing in mind my limited understanding ;-) would be to concentrate on Containers, Container Groups and Plugins on the one front and Racks, Specialists and the various providers and agents on the other. Comments always welcome, cheers, Chris PS: The main reason I'm writing this is because I think ZPatterns are very very cool but may well get ignored because no-one understands them and they're too buggy and complicated to get working :/
In article <395A0742.4BDD8599@nipltd.com>, Chris Withers <chrisw@nipltd.com> wrote:
1. Too much jargon... by far... Lots of complicated words that are meanlingless to the layman and don't help to convey the concepts. This
Can you point out some examples of which ones you think are especially bad?
is compounded by the standard Zope problem of minimal documentation aimed at the advanced developer. Can someone who understadns this all take the time to write a ZPatterns guide to compliment the Wiki and maybe simplify or explain in great detail all the terms (especially the new ones that have popped up in the last few weeks)?
Naming has been a struggle. It's hard to come up with descriptive names for these things. Part of the confusion is that some things have been renamed in an effort to make the meanings clearer in the long term. But short term, it's confusing and it seems like there are lots of new concepts, when in fact there are just several names for the same concept (Implementor -> Specialist, Rack-mountable -> DataSkin, etc). I'll also admit that Rack-mountable was a clearer name, but it was no longer accurate. We tend to err on the side of a name that doesn't clearly describe something instead of a name that clearly describes something, but describes it *wrong* so that you think you understand something and really don't. ("Well, at least the name tells you that you don't know what it is!", as I've said :-)
2. Feature runaway. It seems every day something new (and more confusing) has been added to ZPatterns. I think ZPatterns will only work if it is kept as simple and functional as possible. My view (bearing in
You mention in another post that you feel lots of unnecessary features have been added -- can you give some examples of which ones you feel are extraneous? There has been only one major feature added in ZPatterns 0.4.0, which is the ability to have Rack-mountable-like things that don't live in racks. This is important for PTK-like applications where you don't want to lump everything into one container, but would instead like to have it distributed between member's folders, for example. I think it was worth it. Part of the percieved feature runnaway I think is due to the renaming issue described above. Also, a lot of what looks like adding of features is actually reorganization and simplification of features that were already there. There's no need now for SQL Racks vs. LDAP Racks vs. ZODB Racks, for example. New features were added, but mainly to avoid the need for other features to even exist. In a lot of ways, the code keeps getting simpler and shrinking (as an example, look at the early LoginManager releases vs what's there now -- the code shrank considerably and got much clearer!) Future versions will follow this trend. For example, we're probably going to introduce a simple language to replace Generic Attribute Providers, Generic Triggers, and such. This actually will end up eliminating stuff from ZPatterns and making it clearer, as there will be less types of objects. It should also help the "I have to visit 4 different menus to set up one simple thing" problem. It will keep more of the configuration together so you can see exactly what is going on. I think it will be easier to explain and document as well.
mind my limited understanding ;-) would be to concentrate on Containers, Container Groups and Plugins on the one front and Racks, Specialists and the various providers and agents on the other.
The PlugIns stuff is indeed separate, and is not really a part of ZPatterns as much as it's stuff that we wrote to make ZPatterns and other Zope products easier to write. You can pretty much ignore it if you won't be writing python products or working in ZPatterns internals.
PS: The main reason I'm writing this is because I think ZPatterns are very very cool but may well get ignored because no-one understands them and they're too buggy and complicated to get working :/
0.3.0 is pretty stable, I think. 0.4.0 alphas have been buggy. But they *are* alphas, after all. You were warned :^)
From the unattributed mail you posted from someone else:
P.S. ABout ZPatterns: everyone I spoke to was thought the basic idea behind ZPattern was good and sound and nice and so on. But _everyone_ complained about it being too pretentious (with all the computer science claims and theory behind it)
What, you want something that's *not* based on any theory, just random ideas? :^)
and introducing too many unnecessary new concepts (racks, specialist and what have you). All this is very
Racks and Specialists are key concepts. Saying that they're unecessary and should be eliminated is like saying OO programming would be simpler if they got rid of all the extra ideas like classes and objects. Probably so, but what would be left??? ZPatterns is new, and it can be confusing, and there is not enough good documentation (or working examples -- I'm surpised this is one thing there hasn't been much complaint about). But, it is a lot like Zope in this respect. As someone who used Zope for quite a while before it was even called that, and spent much time banging my head against the wall, I'm guessing I have a pretty good idea of how you feel. I've gained a new sympathy for DC. A lot of these complaints and comments look suspiciously familiar to me... It took time to figure it all out and for Zope to improve. So, please be patient... we (Phillip especially) are doing a lot of this on our "spare" time. More and better documentation would be nice, but at the moment we have a LOT of high-priority work projects to finish (two major rollouts on two continents in two weeks -- fun!) , and it's hard to find time right now to work on things in ZPatterns that don't directly affect our paid work. (Much the same situation DC is in a lot of the time, I suspect). So, in summary, please bear with us. We're working on improving the situation. And if you have criticism of weak areas, please be as specific as possible so we have a better idea of what we need to work on communicating better or changing in the software to make clearer. Thanks!
Ty Sarna wrote:
In article <395A0742.4BDD8599@nipltd.com>, Chris Withers <chrisw@nipltd.com> wrote:
1. Too much jargon... by far... Lots of complicated words that are meanlingless to the layman and don't help to convey the concepts. This
Can you point out some examples of which ones you think are especially bad?
Just everything in general... ;-) The Glossary Wiki I mentioned would help lots... ...also, can you send the list a copy of your recommended books in this area?
Naming has been a struggle. It's hard to come up with descriptive names for these things. Part of the confusion is that some things have been renamed in an effort to make the meanings clearer in the long term. But short term, it's confusing and it seems like there are lots of new concepts, when in fact there are just several names for the same concept (Implementor -> Specialist, Rack-mountable -> DataSkin, etc).
I know, hence the glossary suggestion :-)
I'll also admit that Rack-mountable was a clearer name, but it was no longer accurate. We tend to err on the side of a name that doesn't clearly describe something instead of a name that clearly describes something, but describes it *wrong* so that you think you understand something and really don't. ("Well, at least the name tells you that you don't know what it is!", as I've said :-)
Fair enough, but then they really need to be explained for us mortals...
You mention in another post that you feel lots of unnecessary features have been added -- can you give some examples of which ones you feel are extraneous?
Probably me just misreadign the new terms popping up all the time :-)
There has been only one major feature added in ZPatterns 0.4.0, which is the ability to have Rack-mountable-like things that don't live in racks. This is important for PTK-like applications where you don't want to lump everything into one container, but would instead like to have it distributed between member's folders, for example. I think it was worth it.
So do I, I just didn't understand it ;-)
The PlugIns stuff is indeed separate, and is not really a part of ZPatterns as much as it's stuff that we wrote to make ZPatterns and other Zope products easier to write.
Maybe split it into a seperate product then? It might make learning ZPatterns easier since this area won't get dragged into it...
You can pretty much ignore it if you won't be writing python products or working in ZPatterns internals.
I will on the first count, hence the interest. Squishdot PTK is looming ever closer now...
0.3.0 is pretty stable, I think. 0.4.0 alphas have been buggy. But they *are* alphas, after all. You were warned :^)
Any idea on a beta or final release schedule?
What, you want something that's *not* based on any theory, just random ideas? :^)
No, but maybe the percieved pretentiousness upsets some people?
As someone who used Zope for quite a while before it was even called that, and spent much time banging my head against the wall, I'm guessing I have a pretty good idea of how you feel. I've gained a new sympathy for DC.
heh ;-)
and it's hard to find time right now to work on things in ZPatterns that don't directly affect our paid work. (Much the same situation DC is in a lot of the time, I suspect).
Maybe try and leverage the community liek DC too? How about a ZPatterns fishbowl? *grin*
So, in summary, please bear with us.
...will do, keep up the great work, we may bitch now but will probably aprpeciate it in the long run :-) cheers, Chris
At 03:10 PM 6/28/00 +0100, Chris Withers wrote:
1. Too much jargon... by far... Lots of complicated words that are meanlingless to the layman and don't help to convey the concepts.
Yep, like "Acquisition" and "object publishing". :) Seriously, that is very much the level we're talking about here. ZPatterns is an evolution to Zope's revolution, in the area of web-based application development models. Zope says the answer is publishing objects in an environment supporting acquisition. The ZPatterns design approach is an attempt to answer to the question, "So what objects should I publish, and what are the appropriate uses of acquisition?" As with Zope itself, it is both a design approach *and* an implementation toolkit for the approach, which certainly doesn't help the confusion. :) Also, as in the early days of Zope, terminology evolves and changes as the developers of the concepts seek better ways to explain them to other people. As an example, "Specialist" was originally called "Interface" by Ty and I back around September or so. It evolved to "Implementation Provider" in the later part of the year, and "Implementor" by the time of our conference presentation. After using that name on the lists a while, and in developing the ZPatterns code, it became clear that the name still really sucked and we needed one that made more sense on initially encountering it. After considerable brainstorming, the term "Specialist" was born, and on the whole we're happy with it. Other terms are still in flux, and many I hope we can do away with by replacing them with simpler, more powerful ideas (such as replacing all of the different Trigger and Provider plugins with a simple declarative scripting syntax that lets you specify the aspect weaving for your objects).
2. Feature runaway. It seems every day something new (and more confusing) has been added to ZPatterns. I think ZPatterns will only work if it is kept as simple and functional as possible. My view (bearing in mind my limited understanding ;-) would be to concentrate on Containers, Container Groups and Plugins on the one front and Racks, Specialists and the various providers and agents on the other.
Been there, done that, actually. There really hasn't been much change in ZPatterns from 0.3 to 0.4 in that regard. Most of the upheaval has been due to making it possible for the capabilities of "Rackmountables" to be used in non-rack settings. This forced some significant generalization of the model and some extension to the "theory" in the area of the internal event model (which was previously incomplete and too hardwired). Believe it or not, in 0.4 I have actually *removed* some previously existing data management plug-ins. The acquired attribute provider and acquired sheet provider classes were replaced with a generic "link to parent data plug-ins" class, for example. As Ty mentioned in his post on this subject, we will be trying to do away with other such features later, replacing them with general-purpose tools. Unfortunately, all this evolution makes ZPatterns a moving target for comprehension at the moment. In spite of this, my reading of the lists seems to indicate that there are a few people besides Ty and myself who are actually achieving results with the framework. I hope that they can help to provide more accessible how-to materials, because I'm still very focused on *finishing* ZPatterns to the level that my "paying job" requires. And it's likely going to be a few months before my "paying job" requires that I have introductory docs available for the tools (although I'd personally really like to have some available before then).
"Phillip J. Eby" wrote:
Yep, like "Acquisition" and "object publishing". :) Seriously, that is very much the level we're talking about here.
I know, there are docs explaining acquisition and object publishing has an implicit meaning. Things like 'Specialist' and 'DataSkin' don't have implicit enough meaning unless you're on the 'inside' of ZPatterns...
Also, as in the early days of Zope, terminology evolves and changes as the developers of the concepts seek better ways to explain them to other people.
Hmm, unlike the early days of Zope, would you mind documenting these changes so we have more to 'grab hold of'? ;-) <snip where 'specialist' came from> Perhaps a set of 'glossary' wiki pages? These would have the name of the object/class/type/word/whatever with links to what it used to be called as well as to documentation abotu what it currently is and if it's been outdated, what it's called now (and why its name changed). I might take a hack at this for you to fill in but I doubt I have the time or understanding to make much headway... SteveA, you seem to get all this stuff? could you knock something up for Ty and Phil to 'fill in'? <snip things are becoming simpler> I think I see that now, but if the wiki was kept up to date by the people who understand it best, Ty & Phil ;-), then the rest of us might have a chance of keeping up :-)
Unfortunately, all this evolution makes ZPatterns a moving target for comprehension at the moment. In spite of this, my reading of the lists seems to indicate that there are a few people besides Ty and myself who are actually achieving results with the framework.
I've noticed this too, and it's very cool :-))
I hope that they can help to provide more accessible how-to materials,
Someone must have money for this? (sadly not me... CoSource time?)
because I'm still very focused on *finishing* ZPatterns to the level that my "paying job" requires. And it's likely going to be a few months before my "paying job" requires that I have introductory docs available for the tools (although I'd personally really like to have some available before then).
Ah well, hopefully I won't need it till then... :S Good luck in the meantime, Chris
In article <3959FD9C.4FBE8847@cat-box.net>, Steve Alexander <steve@cat-box.net> wrote:
If it isn't there (hiding somewhere), perhaps I can add it from Shane's original email?
If it isn't there already, by all means, please add it!
By all means, feel welcome. I've been on vacation a while. At 02:29 PM 6/28/00 +0100, Steve Alexander wrote:
I just looked over the ZPatterns Wiki for Shane's explanation, but I can't find it.
If it isn't there (hiding somewhere), perhaps I can add it from Shane's original email?
participants (6)
-
Chris Withers -
Phillip J. Eby -
Shane Hathaway -
Shane Hathaway -
Steve Alexander -
tsarna＠endicor.com