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


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]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to