Re: [Zope-dev] ZPatterns design questions
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. ___ 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] ZPatterns design questions
Steve Spicklemire wrote: > > >> - How does this product (simple though it is) exemplify the > >> RIPP approach? > > pje> I'm not sure that you can say it *exemplifies* the RIPP > pje> approach, although it certainly goes along with that > pje> approach. My hesitation is mainly that it doesn't really > pje> show any of RIPP's major benefits, which are associated with > pje> framework re-use and integration. For that, you really need > pje> to have more than one kind of object, with some kind of > pje> collaboration taking place. > > Hmm.. can anyone thing of a good collaboration 'partner' for > a simple ToDo list? If it's not too complex.. I'd be happy to > add it. I've thought about this since yesterday, and the simplest kind of 'partner' that I can imagine for a 'ToDo', would be a 'Deliverable'. A deliverable would probably have a title, it's own 'Done' boolean property, and probably an optional DeliverableURL property. I'm not sure if it would need it's own 'Doer'. ToDo would need to be reworked so that it's 'Done' property could only be set if all associated Deliverables (if any) were also done (Steve McConnel (sp?) calls these 'binary milestones'). What do you think, is that simple enough? Michael Bernstein. ___ 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] ZPatterns design questions
"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. ___ 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] ZPatterns design questions
> "pje" == Phillip J Eby <[EMAIL PROTECTED]> writes: >> - Propertysheets: You don't expressly say that Shared needs to >> be a 'Common Instance Property Sheet'. pje> Actually, if it's intended to be shared across all instances, pje> there seems to me to be little reason to have it in the pje> ZClass; you might as well define the properties as constants pje> using SkinScript. However, if you want to have defaults that pje> an application integrator will be able to override without pje> actually subclassing, then you want Shared to be a DataSkin pje> Property Sheet, so that they will have the option of pje> overriding your defaults with SkinScript or another attribute pje> provider. Yeah.. now that I think about it a little more clearly, it makes sense to define this in the Specialist itself. This way all the instances in a ToDoManager would share the same set of 'doers', but different ToDoManagers could keep their own custom set. >> - 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? pje> In the ZClass: pje> index_html - presentation, because it displays things the pje> object knows pje> editInstanceForm - presentation, because it is strictly pje> display pje> editInstance - primarily domain, but mixes some presentation pje> in. If instead of displaying an OK button, it just did a pje> redirect, I'd consider it a pure domain. Note, by the way, pje> that it's not wrong to mix the two, it's just usually more pje> reusable to keep presentation code out of domain methods if pje> you want to be able to call them from code or XML-RPC and pje> such. Good! This is the kind of feedback I need! So I can pass in a redirection URL so that the domain code can work in different environments easily. pje> In the Specialist (btw, stric: pje> index_html: UI implementation, because it implements a pje> non-object specific UI (i.e. "display all to-do's"). pje> newToDoForm: UI implementation, because it's a non-specific pje> object UI. pje> addNewToDo: DM implementation, polluted by a bit of UI. :) pje> It implements the data management aspect of creating a new pje> instance. It calls the Specialist's newItem() method, but it pje> could have directly called a newItem() method on one of the pje> Specialist's Racks, or done something else to create the pje> instance. pje> deleteInstances: DM implementation, again with a touch of UI. pje> It implements the data management aspect of creating a new pje> instance. Instead of doing manage_delete on each item, this pje> could have been implemented as an SQLMethod that did a DELETE pje> WHERE operation using the id's that were given (if the data pje> store was an SQL database, of course). OK.. I'll go back and try to 'clean out' the UI pollution to illustrate that separation better. >> - How does this product (simple though it is) exemplify the >> RIPP approach? pje> I'm not sure that you can say it *exemplifies* the RIPP pje> approach, although it certainly goes along with that pje> approach. My hesitation is mainly that it doesn't really pje> show any of RIPP's major benefits, which are associated with pje> framework re-use and integration. For that, you really need pje> to have more than one kind of object, with some kind of pje> collaboration taking place. Hmm.. can anyone thing of a good collaboration 'partner' for a simple ToDo list? If it's not too complex.. I'd be happy to add it. thanks, -steve P.S. my first alpha of EMarket based on ZPatterns is just about ready. I'm sure it's full of similar pollution. This would be a great place for a design review. ;-) ___ 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] ZPatterns design questions
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. ___ 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] ZPatterns design questions
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 us
Re: [Zope-dev] ZPatterns design questions
Hi Michael, > "Michael" == Michael Bernstein <[EMAIL PROTECTED]> 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. ___ 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] ZPatterns design questions
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. ___ 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] ZPatterns design questions
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: NameDescriptionDoerDone? Done! Sorry.. no "to do"s! ___ 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] ZPatterns design questions
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. 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...: ... 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 ... 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 ___ 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] ZPatterns design questions
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. ___ 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] ZPatterns design questions
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: -- Name&dtml-id; Description&dtml-description; Doer&dtml-doer; Done?Done!&dtml-done; Last Modified&dtml-bobobase_modification_time; Edit this instance Back to list -- editInstanceForm so folks can edit its contents... (just like any ZClass) -- Edit ToDo Item Name&dtml-id; Description&dtml-description; DoerNobody selected>&dtml-sequence-item; Done?checked> -- a method that actually does the changing of the properties... (just like...) editInstance -- ToDo Changed. -- 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... : -- NameDescriptionDoerDone? Done! Sorry.. no "to do"s! -- We also need to be able to add and delete items from the rack: newToDoForm: -- Add New ToDo ToDo Name ToDo Description -- addNewToDo: -- Thanks for the new ToDo! deleteInstances: -- Deleting Instances -- That's it. I can't imagine anything simpler. ;-) Really! -steve > "Michael" == Michael Bernstein <[EMAIL PROTECTED]> 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. ___ 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] ZPatterns design questions
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. ___ 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] ZPatterns design questions
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 <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED] 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 ) ___ 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] ZPatterns design questions
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 ___ 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] ZPatterns design questions
"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. ___ 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] ZPatterns design questions
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
Re: [Zope-dev] ZPatterns design questions
"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. ___ 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] ZPatterns design questions
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 co
Re: [Zope-dev] ZPatterns design questions
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
[[EMAIL PROTECTED] - http://zhar.net]
__
"A society that will trade a little liberty for a little order
will deserve neither and lose both."
--B. Franklin
___
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] ZPatterns design questions
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. ___ 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 )
