ZPatterns design questions
First, some context... I'm working on a new data storage system for a related set of (primarily) Zope sites. The data will be kept in ZODB and mirrored out to a RDB (MySQL) to provide read-only access to some non-zope stuff. One other thing to note, all of this will be done via python code (no zclasses). Now say that I want to keep data about a company. I have a specialist, rack and dataskin already created. I currently can store data on the skin via AttributeProviders, but this was mainly done to get something working to mess around with. What I think I want is several SheetProviders. Two for each block of data (a block basically reflect the breakdown of tables in the MySQL DB). Why 2 for each block, one for the ZODB store and one for mirroring the data out to the RDB. So, the breakdown for the company would look like this: Company Rack - Company Information (name, url, etc). . SheetProvider (ZODB) - read/write . SheetProvider (SQL) - write only - Address Information (city, state, zip, etc) . SheetProvider (ZODB) - read/write . SheetProvider (SQL) - write only Does this sound reasonable? I thought about writing a mix-in class to add the SQL stuff to the SheetProvider, eliminating the need for 2 entries for each block of data. But I liked the idea of each being its own plugin, seemed cleaner. The specific question I have about this design is where does the _properties() attribute go? They need to be associated with their appropriate SheetProviders, so that seems the most likely place, but that would require a SheetProvider subclass for each data block which bothers me. It also just doesn't seem to fit in with the design pattern, but my understanding of it is still fairly limited. Next Topic... Adding to the above design, we add a second entity; People. I need to express relationships between the people and the companies. These relationships can be of various sorts; eg. technical contact, marketing contact, company admin, etc. My idea is to create another specialist/rack/dataskin to contain the information about these relationships and associated data (type of relationship, corresponding roles, references to the related entities, etc). I don't have any code for this aspect of the design yet, so I'm only fishing for general criticisms/thoughts at this point. Is there a better way to do this? BTW, there are going to be many more types of entities and relationships that these examples, so it needs to scale. It also needs to perform well, as the authentication mechanism will be fetching the roles off the relationships and, possibly, their related objects. Thanks in advance for any advice. -- John Eikenberry [jae@zhar.net - http://zhar.net] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin
At 01:49 PM 10/3/00 -0700, John Eikenberry wrote:
First, some context... I'm working on a new data storage system for a related set of (primarily) Zope sites. The data will be kept in ZODB and mirrored out to a RDB (MySQL) to provide read-only access to some non-zope stuff. One other thing to note, all of this will be done via python code (no zclasses).
Now say that I want to keep data about a company. I have a specialist, rack and dataskin already created. I currently can store data on the skin via AttributeProviders, but this was mainly done to get something working to mess around with.
What I think I want is several SheetProviders. Two for each block of data (a block basically reflect the breakdown of tables in the MySQL DB). Why 2 for each block, one for the ZODB store and one for mirroring the data out to the RDB. So, the breakdown for the company would look like this:
Company Rack - Company Information (name, url, etc). . SheetProvider (ZODB) - read/write . SheetProvider (SQL) - write only - Address Information (city, state, zip, etc) . SheetProvider (ZODB) - read/write . SheetProvider (SQL) - write only
Does this sound reasonable? I thought about writing a mix-in class to add the SQL stuff to the SheetProvider, eliminating the need for 2 entries for each block of data. But I liked the idea of each being its own plugin, seemed cleaner.
If I can offer a suggestion... It sounds to me like you don't need SheetProviders at all, if you effectively define the property sheets as part of your class, and make the attributes direct attributes on the DataSkin. You then need only set up a single trigger that checks whether any of the attributes you want to mirror have changed, and then fires that off to the SQL db. It would actually be a bit easier to set up if you were using a ZClass, since you could create the property sheets there by just adding "DataSkin Property Sheet" objects to the ZClass. But the basic principle would still apply.
Phillip J. Eby wrote:
If I can offer a suggestion...
Please...
It sounds to me like you don't need SheetProviders at all, if you effectively define the property sheets as part of your class, and make the attributes direct attributes on the DataSkin. You then need only set
Ok, I'm feeling pretty stupid right now but I have to ask what you mean by "define the property sheets as part of your class"? Do you mean using something like this in the DataSkin subclass: def __init__(self,id): self.DataSkin.__init__(self,id) ps = self.propertysheets ps.manage_addPropertySheet('CompanyData','CompanyData') ps.get('CompanyData')._properties = ( {'id':'name', 'type':'string', 'mode':'w'}, ... )
up a single trigger that checks whether any of the attributes you want to mirror have changed, and then fires that off to the SQL db. It would
By 'trigger' you are referring to a RuleAgent plugin? Hmm... I had briefly thought about this, but most of the discussions relating to interfacing to an external RDB seemed to indicate subclassing a SheetProvider was the best course of action. I'll have look into this (hadn't spent much time figuring out RuleAgents yet).
actually be a bit easier to set up if you were using a ZClass, since you could create the property sheets there by just adding "DataSkin Property Sheet" objects to the ZClass. But the basic principle would still apply.
We've come to the conclusion that ZClasses really are more a hinderance than a help, trading functionality for shorter learning curve. With straight python code you get much more control and the ability to use conventional editors and tools (cvs), without losing anything besides a bit of time figuring things out (which is better in the long run anyways). -- John Eikenberry [jae@zhar.net - http://zhar.net] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin
At 03:46 PM 10/3/00 -0700, John Eikenberry wrote:
Ok, I'm feeling pretty stupid right now but I have to ask what you mean by "define the property sheets as part of your class"? Do you mean using something like this in the DataSkin subclass:
def __init__(self,id): self.DataSkin.__init__(self,id) ps = self.propertysheets ps.manage_addPropertySheet('CompanyData','CompanyData') ps.get('CompanyData')._properties = ( {'id':'name', 'type':'string', 'mode':'w'}, ... )
That'd be one way to do it, although it's not compatible with what I had in mind. (i.e., you'd have to write SheetProviders rather than using AttributeProviders.) I was actually suggesting that you create pseudo-propertysheets by just providing methods that change a set of related attributes on the object. Such methods are a lot easier to use than actual propertysheets.
up a single trigger that checks whether any of the attributes you want to mirror have changed, and then fires that off to the SQL db. It would
By 'trigger' you are referring to a RuleAgent plugin? Hmm... I had briefly thought about this, but most of the discussions relating to interfacing to an external RDB seemed to indicate subclassing a SheetProvider was the best course of action. I'll have look into this (hadn't spent much time figuring out RuleAgents yet).
At one time, it was the best course of action because RuleAgents didn't exist and couldn't be written. Now, Generic providers and triggers (or their SkinScript equivalents) are available and more convenient than writing a SheetProvider from scratch. I am actually becoming somewhat disillusioned with the original propertysheets extensibility setup, in that as I've been designing and building real apps with ZPatterns I've not as yet found them to be a useful route to take. Anything that you can do with a propertysheet can be as easily done by providing an attribute that actually returns another DataSkin representing that "sheet", and seems much more natural as an interaction model at the application design level. Instead of "foo.propertysheets.get('CustomerProperties').whatever", you can say "foo.asCustomer.whatever". IMHO it would appear that the shortcut route to property set integration in ZPatterns is not to design custom property sheets, but instead to define interface names for your integration points. And this is only in circumstances where you can't simply make a whitebox specialist map things with virtual objects (per my recent post to Steve about framework integration). What's happened is that ever since the advent of the Generic providers/triggers, and especially of SkinScript, things have gotten a lot easier. In my original envisioning of ZPatterns, I thought that AttributeProviders and SheetProviders would end up being written for LDAP, SQL, etc., and would be relatively specialized. Under those circumstances, the best way to do this would have been a propertysheet. Now, I'm beginning to wonder if I shouldn't go back and deprecate all those references to sheet providers and such, leaving them in place purely for WebDAV support. Actually, what I should probably do is add a new declaration to SkinScript that lets you declare a mapping from a propertysheet name or namespace to an attribute on the base DataSkin. Then, you could use the attribute mapping facilities to create propertysheet objects of your own devising. I'd probably also have to provide a suitable base class for those propertysheet objects, based on DataSkin and providing all the Zope standard methods for a property sheet. I'll consider this for 0.4.3 (coming in a couple weeks or so) but more likely it'll be an 0.4.4 or later.
actually be a bit easier to set up if you were using a ZClass, since you could create the property sheets there by just adding "DataSkin Property Sheet" objects to the ZClass. But the basic principle would still apply.
We've come to the conclusion that ZClasses really are more a hinderance than a help, trading functionality for shorter learning curve. With straight python code you get much more control and the ability to use conventional editors and tools (cvs), without losing anything besides a bit of time figuring things out (which is better in the long run anyways).
Ty and I use ZClasses because you can see your changes much more quickly than if you have to restart Zope. Basing your ZClasses on DataSkin makes the limitations pretty much disappear, from our point of view, because we never put any actual "implementation" code in our ZClasses: just domain logic, property sheets and UI (DTML) methods. All the actual mapping to/from data storage is carried out in the appropriate Rack or Specialist, neatly seperated. Occasionally we need an ExternalMethod in either the ZClass or the Specialist, but these are getting rarer as we find ways to create method-like helper objects that can be added through the Zope UI to accomplish common tasks. In general, we prefer that Python written outside of PythonMethods be re-usable for a variety of projects rather than a one-up for a specific application. YMMV. :)
"Phillip J. Eby" wrote:
Ty and I use ZClasses because you can see your changes much more quickly than if you have to restart Zope. Basing your ZClasses on DataSkin makes the limitations pretty much disappear, from our point of view, because we never put any actual "implementation" code in our ZClasses: just domain logic, property sheets and UI (DTML) methods. All the actual mapping to/from data storage is carried out in the appropriate Rack or Specialist, neatly seperated. Occasionally we need an ExternalMethod in either the ZClass or the Specialist, but these are getting rarer as we find ways to create method-like helper objects that can be added through the Zope UI to accomplish common tasks. In general, we prefer that Python written outside of PythonMethods be re-usable for a variety of projects rather than a one-up for a specific application. YMMV. :)
While I wouldn't say that there has been an actual 'paradigm shift' between the original RIPP presentation and ZPatterns, I'm sufficiently confused at this point to ask for an explanation (with definitions and a *simple* example) of your current thoughts on separating 'domain code' from 'implementation code', both of which still need to be separated from 'presentation code' (DTML interfaces), unless I'm mistaken. Please assume I'm asking a lot of 'why' questions along the way. I'm familiar with the convention of separating 'data' from 'business logic' from 'presentation logic', but this new four-way separation (storage, domain, implementation, UI) is confusing the heck out of me. I know that both of you (Phillip and Ty) are very busy right now, but could you perhaps give us a few short installments? Starting at the beginning (wherever that is), of course. Thanks, Michael Bernstein.
At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote:
While I wouldn't say that there has been an actual 'paradigm shift' between the original RIPP presentation and ZPatterns,
What's happened is that there's been a lot of "implementation shift". The goals of RIPP have never changed, but they are far from being all available in convenient form in the ZPatterns implementation of that model. That's why ZPatterns' version number is so low - we've implemented less than half of RIPP at this point. Meanwhile, along the way we came up with better ways to do things than we had in our first round of ideas. For example, before we thought of Attribute Providers, we assumed that PropertyHandlers were necessary to implement RIPP designs successfully. And before we thought of SkinScript, we assumed that AttributeProviders would be custom written for different types of databases. And so on. This has caused a lot of shifts in the details of our recommended implementation practices, even though the design philosophy for RIPP applications has not actually changed in the slightest. All that's happened is that implementing such applications is now far easier than Ty or I would have dreamed possible a year ago when we began to formulate the RIPP concepts. (Even though we still haven't got all of RIPP available and occasionally suffer for the lack of some bits like PropertyHandlers.)
I'm sufficiently confused at this point to ask for an explanation (with definitions and a *simple* example) of your current thoughts on separating 'domain code' from 'implementation code', both of which still need to be separated from 'presentation code' (DTML interfaces), unless I'm mistaken. Please assume I'm asking a lot of 'why'
questions along the way.
Domain logic: methods which implement the basic behavior of an object, by manipulating its attributes and by calling methods on itself or other objects. (Including delegation to a Specialist, its own or another.) Presentation logic: "view" methods which implement user interface by displaying object attributes and/or the results of either presentation or domain methods, and "controller/view" methods which call domain logic methods and display results. Implementation logic: All of the code and objects contained in a Specialist which map between the domain model of an object and its physical storage implementation(s). This category can be further subdivided into data management implementation, and UI implementation. DM implementation deals with storing and retrieving objects and associated data, and firing off of implementation rules (e.g. ensure that all objects which meet such-and-such criteria are cataloged in catalog Foo). UI implementation deals with providing snippets suitable for use by collaborating classes and/or specialists. For example, in the DropZone example, the billing sub-application would probably delegate the user interface for presenting a "find customer" form to the Customers specialist, which would contain an appropriate HTML snippet. "Out of the box", that specialist would contain a default find-customer form provided by the creator of the billing framework, and it would be the job of the application integrator to override it to fit the overall application. Our current practice is to place both domain and presentation logic in ZClasses, dropping down to ExternalMethods or Python bases for the ZClasses when domain logic requires things you can't do in DTML or PythonMethods. Domain and presentation logic are kept to seperate methods, so that domain logic methods can be re-used for XML-RPC or other programmatic interfaces. Presentation is usually done in a flexible way, relying upon UI implementation hooks where sensible. (Since objects under a specialist acquire from the specialist, it's easy to hook to a specialist-level utility method.) We have not yet released any actual frameworks based on ZPatterns, but if we were to do so, we would probably also define many UI methods as "class_default_for_X" so that end users could override them with a Class Extender in their Rack or Specialist, without having to subclass our classes. We do not have any "best practice" recommendations in this area as yet, since we haven't had to tackle a project of this nature so far.
I'm familiar with the convention of separating 'data' from 'business logic' from 'presentation logic', but this new four-way separation (storage, domain, implementation, UI) is confusing the heck out of me.
There's really only three: Presentation, Domain, and Implementation. These largely correspond to Coad's UI, PD, and DM/SI, although we're also mixing UI snippets into the DM/SI part, simply because that's the locale for customization/integration. (In general, we do not assume that placing more than one kind of thing together as neighbors in the same place is a problem. It's what things *reference* that makes their implementation clean or dirty, not necessarily who their neighbors are in the Zope object tree.)
I know that both of you (Phillip and Ty) are very busy right now, but could you perhaps give us a few short installments? Starting at the beginning (wherever that is), of course.
How's the above for a beginning?
"Phillip J. Eby" wrote:
At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote:
While I wouldn't say that there has been an actual 'paradigm shift' between the original RIPP presentation and ZPatterns,
What's happened is that there's been a lot of "implementation shift". The goals of RIPP have never changed, but they are far from being all available in convenient form in the ZPatterns implementation of that model. [snip] - we've implemented less than half of RIPP at this point.
Ok, That's what's been confusing me. I was thinking that at least some of the missing functionality was due to a change of goals.
I'm sufficiently confused at this point to ask for an explanation (with definitions and a *simple* example) of your current thoughts on separating 'domain code' from 'implementation code', both of which still need to be separated from 'presentation code' (DTML interfaces), unless I'm mistaken. Please assume I'm asking a lot of 'why' questions along the way.
Domain logic: methods which implement the basic behavior of an object, by manipulating its attributes and by calling methods on itself or other objects. (Including delegation to a Specialist, its own or another.)
Presentation logic: "view" methods which implement user interface by displaying object attributes and/or the results of either presentation or domain methods, and "controller/view" methods which call domain logic methods and display results.
Implementation logic: All of the code and objects contained in a Specialist which map between the domain model of an object and its physical storage implementation(s). This category can be further subdivided into data management implementation, and UI implementation.
DM implementation deals with storing and retrieving objects and associated data, and firing off of implementation rules (e.g. ensure that all objects which meet such-and-such criteria are cataloged in catalog Foo).
UI implementation deals with providing snippets suitable for use by collaborating classes and/or specialists. For example, [snip]
How (and why) do you distinguish between UI implementation and presentation logic?
Our current practice is to place both domain and presentation logic in ZClasses, [snip]
Do domain and presentation logic methods go into the *same* ZClass, or separate ones (I realize that this may be a stupid question)?
dropping down to ExternalMethods or Python bases for the ZClasses when domain logic requires things you can't do in DTML or PythonMethods. Domain and presentation logic are kept to seperate methods, so that domain logic methods can be re-used for XML-RPC or other programmatic interfaces. Presentation is usually done in a flexible way, relying upon UI implementation hooks where sensible. (Since objects under a specialist acquire from the specialist, it's easy to hook to a specialist-level utility method.)
I understood what you were saying until the parentheses. Could you repeat that part in a different way?
We have not yet released any actual frameworks based on ZPatterns, [snip]
Isn't LoginManager a framework?
I'm familiar with the convention of separating 'data' from 'business logic' from 'presentation logic', but this new four-way separation (storage, domain, implementation, UI) is confusing the heck out of me.
There's really only three: Presentation, Domain, and Implementation. These largely correspond to Coad's UI, PD, and DM/SI, although we're also mixing UI snippets into the DM/SI part, simply because that's the locale for customization/integration. (In general, we do not assume that placing more than one kind of thing together as neighbors in the same place is a problem. It's what things *reference* that makes their implementation clean or dirty, not necessarily who their neighbors are in the Zope object tree.)
Ok. That makes some more sense. (still working on the Zen, though)
I know that both of you (Phillip and Ty) are very busy right now, but could you perhaps give us a few short installments? Starting at the beginning (wherever that is), of course.
How's the above for a beginning?
Great! Now I need a really stupid-simple example. Something that could have been implemented trivially by using Zope's built in objects, maybe a ZClass, and a bit of DTML, like a list of press releases, or a FAQ, or a company directory. Something *really* simple, so I can see how it's done with ZPatterns. Thanks, Michael Bernstein.
OK.. here's the dumbest example I could cook up. It was my first experiment with ZPatterns in July of last summer. It was based on a really early release, I don't remember which, but it seems to work with the latest.. (I just barely testted it... ) Load the Product ToDoProducts.zexp into the products folder first, then the ToDoManager into a folder in Zope. http://www.zope.org/Members/sspickle/DumbZPatternsExample -steve
Ack.. of course I forgot to test creating new instances.... there was a snippet of code for editing and creating that didn't work with the new propertysheet stuff. I fixed it just now... so it really works. ;-) -steve
"Steve" == Steve Spicklemire <steve@spvi.com> writes:
Steve> OK.. here's the dumbest example I could cook up. It was my Steve> first experiment with ZPatterns in July of last summer. It Steve> was based on a really early release, I don't remember Steve> which, but it seems to work with the latest.. (I just Steve> barely testted it... ) Load the Product ToDoProducts.zexp Steve> into the products folder first, then the ToDoManager into a Steve> folder in Zope. Steve> http://www.zope.org/Members/sspickle/DumbZPatternsExample Steve> -steve Steve> _______________________________________________ Zope-Dev Steve> maillist - Zope-Dev@zope.org Steve> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross Steve> posts or HTML encoding! ** (Related lists - Steve> http://lists.zope.org/mailman/listinfo/zope-announce Steve> http://lists.zope.org/mailman/listinfo/zope )
Steve Spicklemire wrote:
Ack.. of course I forgot to test creating new instances.... there was a snippet of code for editing and creating that didn't work with the new propertysheet stuff. I fixed it just now... so it really works. ;-)
I didn't get a chance to play with this today, but I'll make time to do so tomorow. How easy would it be for you to write a step-by-step HowTo/WalkThrough of creating the example? I can edit it and flesh it out if you can write a bare-bones version. Thanks, Michael Bernstein.
Again.. this is an embarrassingly trivial example.. but here it goes: First of all there is a ZClass.... 'ToDoClass'. It needs to have a base class of ZPatterns:DataSkin. You don't need constructor methods, but I don't think they hurt anything if you leave them in. The ToDo needs methods: index_html to render itself like any ZClass: ---------------------------------------------------------------------- <dtml-var standard_html_header> <center> <table> <tr><th>Name</th><td>&dtml-id;</td></tr> <tr><th>Description</th><td>&dtml-description;</td></tr> <tr><th>Doer</th><td>&dtml-doer; </td></tr> <tr><th>Done?</th><td><dtml-if done>Done!</dtml-if>&dtml-done; </td></tr> <tr><th>Last Modified</th><td>&dtml-bobobase_modification_time;</td></tr> </table> <a href="editInstanceForm">Edit this instance</a> <a href="&dtml-URL2;">Back to list</a> <center> <dtml-var standard_html_footer> ---------------------------------------------------------------------- editInstanceForm so folks can edit its contents... (just like any ZClass) ---------------------------------------------------------------------- <dtml-var standard_html_header> <center> <h2>Edit ToDo Item</h2> <form action="editInstance" method="post"> <table cellspacing=3 cellpadding=3> <tr><th>Name</th><td>&dtml-id;</td></tr> <tr><th>Description</th><td><textarea name="description" wrap=soft cols=60 rows=15>&dtml-description;</textarea></td></tr> <tr><th>Doer</th><td><select name="doer"><option value="">Nobody <dtml-in doers sort> <option value="&dtml-sequence-item;" <dtml-if "doer==_['sequence-item']">selected</dtml-if>>&dtml-sequence-item; </dtml-in> </select> </td></tr> <tr><th>Done?</th><td><input type=checkbox name="done" <dtml-if done>checked</dtml-if>></td></tr> <tr><td colspan=2 align=center><input type=submit value="Edit ToDo"></td></tr> </table> </form> </center> <dtml-var standard_html_footer> ---------------------------------------------------------------------- a method that actually does the changing of the properties... (just like...) editInstance ---------------------------------------------------------------------- <dtml-var standard_html_header> <center> <dtml-if "REQUEST.form.has_key('done')"> <!-- booleans can be tricky.. --> <dtml-call "REQUEST.set('done',1)"> <dtml-else> <dtml-call "REQUEST.set('done',0)"> </dtml-if> <dtml-call "propertysheets.Basic.manage_changeProperties(REQUEST=REQUEST)"> ToDo Changed.<br> <form action="&dtml-URL2;"> <input type=submit value="OK"> </form> </center> <dtml-var standard_html_footer> ---------------------------------------------------------------------- That's it for the methods of the ZClass...we can view/edit instances TTW. Now.. we need propertysheets: Basic: (Now it's a "Data Skin Attribute Property Sheet"). properties: description (text) doer (string) done (boolean) Shared: (This is a propertysheet that's meant to be shared by all the instances. If you update this... update it in the ZClass, not an instance.....) doers (lines) Finally... we need methods for the ToDoManager (Specialist): We'll set the defaultRack of the ToDoManager up to store its objects persistently, using the ToDoClass we just created as the storage type. We can just leave the default data plugins installed since they work fine with persistent storage. If later you want to experiment with other storage methods, you can do it making almost no changes to any other code (with the possible exception of defaultRack.getPersistentItemIds() which might not be appropriate if you're not using persistent ZODB storage....) Here is the default method of the ToDoManager... basically, pull out the objects and view a brief list of ids, descriptions doers, and doneness... : ---------------------------------------------------------------------- <dtml-var standard_html_header> <center> <br> <h2><dtml-var title></h2> <p> <dtml-in "defaultRack.getPersistentItemIDs()" sort> <dtml-if sequence-start> <form action="." method="post"> <table cellspacing=3 cellpadding=3 border=1> <tr><td> </td><th>Name</th><th>Description</th><th>Doer</th><th>Done?</th></tr> </dtml-if> <dtml-let currID="_['sequence-item']"> <dtml-with "getItem(currID)"> <tr> <td><input type=checkbox name="ids:list" value="&dtml-currID;"></td> <td><a href="<dtml-var currID url_quote>/editInstanceForm"><dtml-var currID></a></td> <td><dtml-var description> </td> <td><dtml-var doer> </td> <td><dtml-if done>Done!<dtml-else> </dtml-if></td> </dtml-with> </dtml-let> <dtml-if sequence-end> <tr><td colspan=5 align=center><input type=submit name="newToDoForm:method" value="Add New ToDo"><input type=submit name="deleteInstances:method" value="Delete selected ToDos"></td></tr> </table> </dtml-if> <dtml-else> Sorry.. no "to do"s! <br> <form action="."> <input type=submit name="newToDoForm:method" value="Add New ToDo"> </form> </dtml-in> </p> </center> <dtml-var standard_html_footer> ---------------------------------------------------------------------- We also need to be able to add and delete items from the rack: newToDoForm: ---------------------------------------------------------------------- <dtml-var standard_html_header> <center> <form action="addNewToDo" method="post"> <table> <tr><td align=center colspan=2><h2>Add New ToDo</h2></td></tr> <tr><th>ToDo Name</th><td><input name="name" size=40></td></tr> <tr><th>ToDo Description</th><td><textarea rows=10 cols=40 name="description"></textarea></td></tr> <tr><td align=center colspan=2><input type=submit value="OK"></td></tr> </table> </form> </center> <p> </p> <dtml-var standard_html_footer> ---------------------------------------------------------------------- addNewToDo: ---------------------------------------------------------------------- <dtml-var standard_html_header> <center> <h2> Thanks for the new ToDo!</h2> <dtml-let ni="newItem(name)"> <dtml-call "ni.propertysheets.Basic.manage_changeProperties(description=description)"> </dtml-let> <form action=index_html> <input type=submit value="OK"> </form> </center> <dtml-var standard_html_footer> deleteInstances: ---------------------------------------------------------------------- <dtml-var standard_html_header> <h2>Deleting Instances</h2> <p> <dtml-in ids> <dtml-let ni="getItem(_['sequence-item'])"> <dtml-call "ni.manage_delete()"> </dtml-let> </dtml-in> <form action="&dtml-URL1;"> <input type=submit value="OK"> </form> </p> <dtml-var standard_html_footer> ---------------------------------------------------------------------- That's it. I can't imagine anything simpler. ;-) Really! -steve
"Michael" == Michael Bernstein <webmaven@lvcm.com> writes:
Michael> Steve Spicklemire wrote: >> Ack.. of course I forgot to test creating new >> instances.... there was a snippet of code for editing and >> creating that didn't work with the new propertysheet stuff. I >> fixed it just now... so it really works. ;-) Michael> I didn't get a chance to play with this today, but I'll Michael> make time to do so tomorow. How easy would it be for you Michael> to write a step-by-step HowTo/WalkThrough of creating the Michael> example? I can edit it and flesh it out if you can write Michael> a bare-bones version. Michael> Thanks, Michael> Michael Bernstein.
Steve Spicklemire wrote:
Again.. this is an embarrassingly trivial example.. but here it goes: [snip details] That's it. I can't imagine anything simpler. ;-) Really!
Thanks, I'll be trying this out at work tomorrow. Michael Bernstein.
I should point out a couple of things that might not be obvious (that I noticed only on a second 'read' of the explaination): 1) getPersistentItemIds() can be a pain. <dtml-in "defaultRack.getPersistentItemIDs()" sort> is straightforward enough... but what if I don't care if they are sorted, or I want to sort on some other property? One would think that you could do something like...: <dtml-let foo="[]"> <dtml-in "defaultRack.getPersistentItemIDs()"> <dtml-call "foo.append(defaultRack.getItem(_['sequence-item']))"> </dtml-in> <dtml-in foo sort=description> ... </dtml-in> </dtml-let> But it doesn't work! You get 'Authorization Failed'. There was a bit of email on the list when I found this problem.... but it doesn't seem to bother anyone too much.... it turns out that getPersistentItemIds() actually returns a BTree object, which is not covered by the Zope security system as an allowed 'simple' subobject. However, when you 'sort' the list in the 'in' tag.. a side effect is that it it copied to a plain old Zope list..... so it's OK. ;-) So... you *can* do <dtml-let foo="[]"> <dtml-in "defaultRack.getPersistentItemIDs()" sort> <dtml-call "foo.append(defaultRack.getItem(_['sequence-item']))"> </dtml-in> <dtml-in foo sort=description> ... </dtml-in> </dtml-let> Soo.. the moral of that story is... if you're not allowed to see something... just sort it! :-) !! ;-( 2) This simple/dumb example using a Specialist/Rack combination. There is another approach (that Steve Alexander has used a lot I gather) which is to use the Folder with customizer support. I've never tried that since I went down this road and wanted to sort it out before 'branching' to other methods. To be fair I should probably try to implement this same example with that approach. -steve
Ack.. sorry... I was making little changes last night to make sure the ZClass was completely consistent with my explaination, and to make sure I could start 'from scratch'. I created a 'new' ZClass, and a 'new' rack. This confused the 'old' Rack. (I didn't update the ToDoManager.zexp, so if you downloaded the new Product, but the old ToDoManager you got the _setRack error. Anyway... I've now uploaded both the ToDoManager and the ToDoProducts at 0.0.2. I also changed the index_html of the ToDoManager to illustrated the getPersistentItemIds() issue I wrote about earlier.... good luck! -steve here's the new index_html: <dtml-var standard_html_header> <center> <br> <h2><dtml-var title></h2> <p> <dtml-let idList="[]"> <dtml-in "defaultRack.getPersistentItemIDs()" sort> <dtml-call "idList.append(getItem(_['sequence-item']))"> </dtml-in> <dtml-in idList sort=description> <dtml-if sequence-start> <form action="." method="post"> <table cellspacing=3 cellpadding=3 border=1> <tr><td> </td><th>Name</th><th>Description</th><th>Doer</th><th>Done?</th></tr> </dtml-if> <tr> <td><input type=checkbox name="ids:list" value="&dtml-id;"></td> <td><a href="<dtml-var id url_quote>/editInstanceForm"><dtml-var id></a></td> <td><dtml-var description> </td> <td><dtml-var doer> </td> <td><dtml-if done>Done!<dtml-else> </dtml-if></td> <dtml-if sequence-end> <tr><td colspan=5 align=center><input type=submit name="newToDoForm:method" value="Add New ToDo"><input type=submit name="deleteInstances:method" value="Delete selected ToDos"></td></tr> </table> </dtml-if> <dtml-else> Sorry.. no "to do"s! <br> <form action="."> <input type=submit name="newToDoForm:method" value="Add New ToDo"> </form> </dtml-in> </p> </dtml-let> </center> <dtml-var standard_html_footer>
Steve Spicklemire wrote:
Ack.. sorry... I was making little changes last night to make sure the ZClass was completely consistent with my explaination, and to make sure I could start 'from scratch'.
Ok, I just got through stepping through the walkthrough. Thanks! That *was* a really simple example. Perfect! I had a few comments: - You skipped over creating the Product in the Products folder. - Propertysheets: You don't expressly say that Shared needs to be a 'Common Instance Property Sheet'. - ToDoManager: I was initially confused as to where this needed to be created. I tried placing it directly in the Product as well as in the ZCLass before I tried placing it in a normal folder. Ok, moving forward, I had some questions about this approach to building applications: - What do I need to do to let users add ToDoManagers to their own folders without creating them from scratch? In other words, How do I turn ToDoManager into a product? - The term 'Specialist' implies (at least to me) that this object is overiding/replacing a 'Generalist' somewhere, but this does not seem to be the case here. Am I missing something? - I'm trying to reconcile PJE's methodology of Domain Logic, Presentation Logic, Data Management Implementation Logic, and User Interface Implementation Logic. Can you (or Phillip) label each of the DTML methods as to which category they fall into? And state why, even if it seems obvious? - How does this product (simple though it is) exemplify the RIPP approach? In other words, assume I'm asking annoying whiny two-year-old 'why?' questions after every declarative statement in the tutorial. Anyway, I'll try to synthesize all of the replies I get (if any) into a beginners 'Zen of ZPatterns' tutorial. Thanks again for such a simple example! Michael Bernstein.
Hi Michael,
"Michael" == Michael Bernstein <mbernstein@profitscape.com> writes:
Michael> - You skipped over creating the Product in the Products Michael> folder. Ooops! Sorry... I guess I assumed that the reader would be familiar with ZClasses etc.... this should probably be stated up front, with a reference to ZClass docs.. Michael> - Propertysheets: You don't expressly say that Shared Michael> needs to be a 'Common Instance Property Sheet'. I don't think it does... it could probably be either depending on how you want to manage it.... in fact, for this example, all the properties could really be in one propertysheet, and it really wouldn't change much.. it was really a 'conceptual difference' between those properties that were meant to be class 'globals' and those intended to be different in each instance. Michael> - ToDoManager: I was initially confused as to where this Michael> needed to be created. I tried placing it directly in the Michael> Product as well as in the ZCLass before I tried placing Michael> it in a normal folder. Sorry.. any normal folder works.. Michael> Ok, moving forward, I had some questions about this Michael> approach to building applications: Michael> - What do I need to do to let users add ToDoManagers to Michael> their own folders without creating them from scratch? In Michael> other words, How do I turn ToDoManager into a product? Hmmm.. well.. I suppose you could keep ToDoManager.zexp in the import folder and programmatically 'import' them. ;-) Seriously I've never hit that... I do programmatically create specialist in my Python Product.. but it's not TTW. You might be able to keep a 'template' Specialist in the ZClass and then make a method to 'copy' and 'paste' it. Michael> - The term 'Specialist' implies (at least to me) that Michael> this object is overiding/replacing a 'Generalist' Michael> somewhere, but this does not seem to be the case here. Am Michael> I missing something? No. Specialist just means he specializes in handling a class of objects for an application.... Michael> - I'm trying to reconcile PJE's methodology of Domain Michael> Logic, Presentation Logic, Data Management Implementation Michael> Logic, and User Interface Implementation Logic. Can you Michael> (or Phillip) label each of the DTML methods as to which Michael> category they fall into? And state why, even if it seems Michael> obvious? I'll have to get back to you on that... no time now. Michael> - How does this product (simple though it is) exemplify Michael> the RIPP approach? In other words, assume I'm asking Michael> annoying whiny two-year-old 'why?' questions after every Michael> declarative statement in the tutorial. Good question.. I dunno. ;-) Maybe it doesn't. Michael> Anyway, I'll try to synthesize all of the replies I get Michael> (if any) into a beginners 'Zen of ZPatterns' tutorial. Michael> Thanks again for such a simple example! No trouble. 'Simple' is my middle name. ;-) -steve Michael> Michael Bernstein.
At 03:44 PM 10/6/00 -0500, Michael Bernstein wrote:
Steve Spicklemire wrote:
Ack.. sorry... I was making little changes last night to make sure the ZClass was completely consistent with my explaination, and to make sure I could start 'from scratch'.
Ok, I just got through stepping through the walkthrough. Thanks! That *was* a really simple example. Perfect!
I had a few comments:
- You skipped over creating the Product in the Products folder.
Yep, gotta do that.
- Propertysheets: You don't expressly say that Shared needs to be a 'Common Instance Property Sheet'.
Actually, if it's intended to be shared across all instances, there seems to me to be little reason to have it in the ZClass; you might as well define the properties as constants using SkinScript. However, if you want to have defaults that an application integrator will be able to override without actually subclassing, then you want Shared to be a DataSkin Property Sheet, so that they will have the option of overriding your defaults with SkinScript or another attribute provider.
- ToDoManager: I was initially confused as to where this needed to be created. I tried placing it directly in the Product as well as in the ZCLass before I tried placing it in a normal folder.
Yes, Specialists go in the application space, as they are part of the application. A product developer may want to create one in the product, but only so that it can be copied into application space by a factory. Btw, in strict RIPP convention, ToDoManager would be named "ToDos", as the plural form of the role the objects play in the framework.
Ok, moving forward, I had some questions about this approach to building
applications:
- What do I need to do to let users add ToDoManagers to their own folders without creating them from scratch? In other words, How do I turn ToDoManager into a product?
You can put it in the product, then create two methods - a constructor form and a constructor method, along with a Permission. Last, create a Zope Factory that calls the constructor form. The constructor method would copy the specialist and paste it into the chosen destination.
- The term 'Specialist' implies (at least to me) that this object is overiding/replacing a 'Generalist' somewhere, but this does not seem to be the case here. Am I missing something?
Specialist means "one who specializes", not "thing which is specialized". :) There are no Generalists, unless you consider the application/Zope site as a whole to be one. :)
- I'm trying to reconcile PJE's methodology of Domain Logic, Presentation Logic, Data Management Implementation Logic, and User Interface Implementation Logic. Can you (or Phillip) label each of the DTML methods as to which category they fall into? And state why, even if it seems obvious?
In the ZClass: index_html - presentation, because it displays things the object knows editInstanceForm - presentation, because it is strictly display editInstance - primarily domain, but mixes some presentation in. If instead of displaying an OK button, it just did a redirect, I'd consider it a pure domain. Note, by the way, that it's not wrong to mix the two, it's just usually more reusable to keep presentation code out of domain methods if you want to be able to call them from code or XML-RPC and such. In the Specialist (btw, stric: index_html: UI implementation, because it implements a non-object specific UI (i.e. "display all to-do's"). newToDoForm: UI implementation, because it's a non-specific object UI. addNewToDo: DM implementation, polluted by a bit of UI. :) It implements the data management aspect of creating a new instance. It calls the Specialist's newItem() method, but it could have directly called a newItem() method on one of the Specialist's Racks, or done something else to create the instance. deleteInstances: DM implementation, again with a touch of UI. It implements the data management aspect of creating a new instance. Instead of doing manage_delete on each item, this could have been implemented as an SQLMethod that did a DELETE WHERE operation using the id's that were given (if the data store was an SQL database, of course).
- How does this product (simple though it is) exemplify the RIPP approach?
I'm not sure that you can say it *exemplifies* the RIPP approach, although it certainly goes along with that approach. My hesitation is mainly that it doesn't really show any of RIPP's major benefits, which are associated with framework re-use and integration. For that, you really need to have more than one kind of object, with some kind of collaboration taking place.
At 07:59 AM 10/5/00 -0700, Michael Bernstein wrote:
"Phillip J. Eby" wrote:
Domain logic: methods which implement the basic behavior of an object, by manipulating its attributes and by calling methods on itself or other objects. (Including delegation to a Specialist, its own or another.)
Presentation logic: "view" methods which implement user interface by displaying object attributes and/or the results of either presentation or domain methods, and "controller/view" methods which call domain logic methods and display results.
Implementation logic: All of the code and objects contained in a Specialist which map between the domain model of an object and its physical storage implementation(s). This category can be further subdivided into data management implementation, and UI implementation.
DM implementation deals with storing and retrieving objects and associated data, and firing off of implementation rules (e.g. ensure that all objects which meet such-and-such criteria are cataloged in catalog Foo).
UI implementation deals with providing snippets suitable for use by collaborating classes and/or specialists. For example, [snip]
How (and why) do you distinguish between UI implementation and presentation logic?
Presentation logic lives with an object's class, and deals with what that object knows about presenting itself. UI implementation is "glue" presentation that lives in a Specialist for use by any object that needs to present UI related to objects of the kind the Specialist handles. The terms used here are "official" terminology with precise definitions, btw. I am just trying to answer your questions as best I know how. An example of presentation logic would be a method which displays a form to perform some action on the object. E.g., let's say we have a "Task" object with an "Assign To" form. Tasks are assigned to Assignees, but in a given application, there could be many possible kinds of Assignees and the means of selecting an Assignee is context-dependent. Thus, a Task's presentation logic cannot implement such a thing directly; it must ask the Assignees specialist for a code snippet (UI implementation) that displays an assignee selection sub-form within its "Assign To" form. As a counter-example to the above, consider Zope's local roles UI. When you assign local roles, Zope goes to the specialist "acl_users" and asks it for all possible users, then displays them in a dropdown list. While we could do the same thing in our Task/Assignees example (i.e. have Task just display a dropdown list of all Assignees), this is bad because it does not scale well. What if our Task object is used for a company intranet where there are 10,000 employees? What if assignees can be either employees or outside vendors, and they are looked up differently? The Assignees specialist is responsible for providing an appropriate UI implementation (hence the name) for this operation. It could provide a dropdown list, a type-in box with a button to pop up a search window that lets you search the employee directory, or any number of other possible implementations that would get the necessary data back to the assignment method once the form was submitted. We could include a simple implementation with our task management framework, and the application integrator would override it if needed for their situation. This is what UI implementation logic is for, and it's an important part of the rationale for the existence of Specialists (formerly known as Implementors).
Our current practice is to place both domain and presentation logic in ZClasses, [snip]
Do domain and presentation logic methods go into the *same* ZClass, or separate ones (I realize that this may be a stupid question)?
Same one. We assume that it is more useful/important for a framework to offer ready-to-use classes than lots of mixins.
dropping down to ExternalMethods or Python bases for the ZClasses when domain logic requires things you can't do in DTML or PythonMethods. Domain and presentation logic are kept to seperate methods, so that domain logic methods can be re-used for XML-RPC or other programmatic interfaces. Presentation is usually done in a flexible way, relying upon UI implementation hooks where sensible. (Since objects under a specialist acquire from the specialist, it's easy to hook to a specialist-level utility method.)
I understood what you were saying until the parentheses. Could you repeat that part in a different way?
Objects retrieved from a Specialist (in general) have the Specialist as their aq_parent. This means that if an object wants to use UI implementation snippets from its own Specialist, it can do so without having to explicitly name the specialist. This is useful for two kinds of snippets: 1) lookup snippets as described earlier, and 2) configuration snippets, ala standard_html_header, which can be used to customize the look of the presentation logic.
We have not yet released any actual frameworks based on ZPatterns, [snip]
Isn't LoginManager a framework?
Okay, you've got me there. I tend not to think of it that way, if only because there are many things less than satisfactory about its current state of implementation. For example, if we had it to do over again, I would re-work the internal API so that roles, domains, authentication, etc., could be controlled by plug-ins on the user sources. At that point there would be no need for different kinds of user sources, as they would all be fully generic. But anyway, I digress.
Great! Now I need a really stupid-simple example. Something that could have been implemented trivially by using Zope's built in objects, maybe a ZClass, and a bit of DTML, like a list of press releases, or a FAQ, or a company directory. Something *really* simple, so I can see how it's done with ZPatterns.
I think Steve Spicklemire's tackling this one. I'll have a look at what he's done and see if I have any nits to pick before trying to do one of my own. :)
"Phillip J. Eby" wrote:
How (and why) do you distinguish between UI implementation and presentation logic?
Presentation logic lives with an object's class, and deals with what that object knows about presenting itself. UI implementation is "glue" presentation that lives in a Specialist for use by any object that needs to present UI related to objects of the kind the Specialist handles. The terms used here are "official" terminology with precise definitions, btw. I am just trying to answer your questions as best I know how.
I'm not sure, but did you mean 'are not' in that last sentence?
An example of presentation logic would be a method which displays a form to perform some action on the object. E.g., let's say we have a "Task" object with an "Assign To" form. Tasks are assigned to Assignees, but in a given application, there could be many possible kinds of Assignees and the means of selecting an Assignee is context-dependent. Thus, a Task's presentation logic cannot implement such a thing directly; it must ask the Assignees specialist for a code snippet (UI implementation) that displays an assignee selection sub-form within its "Assign To" form. [snip] The Assignees specialist is responsible for providing an appropriate UI implementation (hence the name) for this operation. It could provide a dropdown list, a type-in box with a button to pop up a search window that lets you search the employee directory, or any number of other possible implementations that would get the necessary data back to the assignment method once the form was submitted. We could include a simple implementation with our task management framework, and the application integrator would override it if needed for their situation.
Thanks, this is starting to make a lot of sense WRT reusable frameworks. Here is where my 'Specialist/Generalist' confusion came from. It seems to me, that the simple implementation (you might also call it the default implementation) for the selector UI in your example should be contained in a 'Generalist' object that could be overridden by a 'Specialist'. This would help make crystal clear the line between Presentation Logic and Implementation UI, and would also serve as a useful starting point for creating the overriding methods in the 'Specialist' by the framework customizer.
We have not yet released any actual frameworks based on ZPatterns, [snip]
Isn't LoginManager a framework?
Okay, you've got me there. I tend not to think of it that way, if only because there are many things less than satisfactory about its current state of implementation. For example, if we had it to do over again, I would re-work the internal API so that roles, domains, authentication, etc., could be controlled by plug-ins on the user sources. At that point there would be no need for different kinds of user sources, as they would all be fully generic. But anyway, I digress.
In light of my own dificulties in adding SMB authentication to PersistentUserSouce.py, and Bill Andersons dificulties with password encryption on some Unices, I think that this would be a *very* worthwhile effort. Such a project might also give you the mandate to get DC to fix the Zope internal acl_users interfaces that were getting in your way. How large of a project would this be? Thanks for your patience in answering my questions. I think I'm getting a good understanding of this approach, but I'm still working on internalizing it. Michael Bernstein.
At 12:50 PM 10/7/00 -0700, Michael Bernstein wrote:
"Phillip J. Eby" wrote:
Presentation logic lives with an object's class, and deals with what that object knows about presenting itself. UI implementation is "glue" presentation that lives in a Specialist for use by any object that needs to present UI related to objects of the kind the Specialist handles. The terms used here are "official" terminology with precise definitions, btw. I am just trying to answer your questions as best I know how.
I'm not sure, but did you mean 'are not' in that last sentence?
Whoops. :( Yes, you're correct, I lost the 'not' somewhere along the way there.
Here is where my 'Specialist/Generalist' confusion came from. It seems to me, that the simple implementation (you might also call it the default implementation) for the selector UI in your example should be contained in a 'Generalist' object that could be overridden by a 'Specialist'. This would help make crystal clear the line between Presentation Logic and Implementation UI, and would also serve as a useful starting point for creating the overriding methods in the 'Specialist' by the framework customizer.
Hm. It seems to me to add too many entities without any real advantages. It's straightforward to have overrideable default implementations in a Specialist - note LoginManager's login, logout, and forbidden pages, which are UI snippets of this sort.
Okay, you've got me there. I tend not to think of it that way, if only because there are many things less than satisfactory about its current state of implementation. For example, if we had it to do over again, I would re-work the internal API so that roles, domains, authentication, etc., could be controlled by plug-ins on the user sources. At that point there would be no need for different kinds of user sources, as they would all be fully generic. But anyway, I digress.
In light of my own dificulties in adding SMB authentication to PersistentUserSouce.py, and Bill Andersons dificulties with password encryption on some Unices, I think that this would be a *very* worthwhile effort. Such a project might also give you the mandate to get DC to fix the Zope internal acl_users interfaces that were getting in your way.
How large of a project would this be?
Not very hard, I think. Basically I think we'd warp the "Data Plug-Ins" plug-in group on UserSource to allow what I'll call "authorization plug-ins" to be included. And, we'd complement that with some of the work Ty's already done on mapping roles, domains, etc. back onto plain object attributes so that you can just use regular attribute providers or SkinScript to compute them. I'm not sure, but I think I recall that we even came up with a way to securely manage a password attribute, which we needed for one of our own applications a month or two ago.
participants (5)
-
John Eikenberry -
Michael Bernstein -
Michael Bernstein -
Phillip J. Eby -
Steve Spicklemire