Phillip J. Eby wrote:

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?

But how can this work? If I ask for the graphic in Product.addMeToOrderForm, an OrderLineItem object doesn't exist yet. So Product has to ask the OrderLineItems Specialist for the UI snippet, and OrderLineItems gets it from the Graphics Specialist. Then Product.addMeToOrder can create a new OrderLineItem and hand it the form fields for the graphic. Although, to make it cleaner, Product would add OrderLineItems.newLineItemSnippet to the form, and OrderLineItems would decide what needs to be included in the form - so Product doesn't have to explicitly ask for a Graphic upload form.

...

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.

This is probably the best way... but it wasn't my original plan. I need to ask for a quantity for every added product, so I was going to have Product.addMeToOrderForm ask for quantity and for a graphic. But instead, I can add a quantity field to the product display page, next to the "Add to Order" button. Then addMeToOrderForm isn't needed at all, Product.addMeToOrder will create a new OrderLineItem object, which will then ask for the graphic if it's needed.

...

...

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

This is confusing... because in all the E-com designs I've looked at, the order state machine covers everything up to 'order fulfilled'... you're suggesting stopping the order states at 'order authorized' and moving the fulfillment states to the fulfillment object? Also, what do you mean when you say 'state/status objects'? I can understand having OrderLineItem, FulfillmentLineItem and ShippingLineItem where each covers a different range of states, but are you suggesting having separate objects just for tracking the state? -- Itai Tavor "Je sautille, donc je suis." C3Works itai@c3works.com - Kermit the Frog "If you haven't got your health, you haven't got anything"