[Zope-dev] ZPatterns design questions

[Steve Spicklemire]

>>>>> "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. ;-)