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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to