Re: [Zope-dev] Racks and Specialists Simplified
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? > ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Racks and Specialists Simplified
In article <[EMAIL PROTECTED]>, Steve Alexander <[EMAIL PROTECTED]> 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! ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Racks and Specialists Simplified
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Racks and Specialists Simplified
"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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Racks and Specialists Simplified
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
[Zope-dev] Racks and Specialists Simplified
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
