...

...

...

...

"pje" == Phillip J Eby <pje@telecommunity.com> 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. ;-)