[Zope-dev] ZPatterns design questions

[Phillip J. Eby]

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.