[Zope-dev] ZPatterns, ZClasses, Specialists: Assigning
responsibilities
Phillip J. Eby
pje@telecommunity.com
Thu, 21 Dec 2000 08:32:06 -0500
At 05:13 PM 12/21/00 +1100, Itai Tavor wrote:
>>
>>I think you're right about this being an OrderLineItem. A couple of fine
>>points, however... First, I don't think there needs to be an
>>"OrderLineItemsWithGraphic" specialist, since there is nothing else that
>>would talk to it. It's fine in this case to have the line item classes
>>(either with graphic or without) handle their own UI snippets. UI
>>delegation is for when an object needs to display UI for some *other*
>>object than itself, since you can always use class extenders and other
>>techniques to reshape the apparent class of an object retrieved from a
>>specialist. The interface which other objects deal with is
>>"OrderLineItem", and they simply expect a portion of the form to be
>>rendered, and it's okay for the class to handle that.
>
>I got a bit confused here... the UI snippet for uploading a graphic
>actually comes from the Graphics Specialist.
That's fine, but it should be by way of an object that's filling the
OrderLineItem role, yes?
>Or I could
>eliminate the problem by uploading the graphic from a form displayed
>by the order line item after it has been added.
That's actually what I thought you were doing/intending.
>>Here's the question... how many behaviors are different in the order line
>>item itself? Are you also using fulfillment line items? If the only
>>difference to the order line item is that it references some additional
>>data, then I'd say a single class would be fine. Most of the behavior
>>probably comes in on the fulfillment line item, yes? Again, you can ask
>>your FulfillmentLineItems specialist to create
>>"newLineItemFor(orderLineItem)" and let it decide what kind of
>>implementation to hand back. In this case, it probably will be a different
>>class, while for the order line items, it may or may not buy you anything.
>
>I haven't thought of using fulfillment line items... not sure what
>they are for? An order is considered fulfilled once all items have
>been shipped, so order line items are responsible for tracking
>everything that happens until a ShipmentLineItem is created. The
>order line item for a customizable product tracks the product using
>state values like 'sent to factory', 'received from factory', etc. So
>it needs a new set of state values, as well as methods like
>'sendManufacturingOrderToFactory'.
>
>What exactly does the fulfillment role you're referring to do? Does
>it do more than a shipment role?
Fulfillment would be between ordering and shipping, covering such things as
pulling items from the warehouse to customizing them with the graphic. I
assumed that an order line item was only meaningful until you have a
completed order. You may not need the complexity, but to me it seems like
a seperate phase with a very different set of behaviors than what I would
think of as an order line item. If I were doing an app like this, I'd at
least have some sort of state/status objects to delegate these different
behaviors to. But I'd say this could be left to the taste of the chef. :)
P.S. By the way, I'm off on vacation later today, and won't be active on
the list again for a little over a week.