Re: [Zope-dev] ZPatterns, ZClasses, Specialists: Assigningresponsibilities

2001-01-10 Thread Itai Tavor

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

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[EMAIL PROTECTED]  - Kermit the Frog

"If you haven't got your health, you haven't got anything"

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

Re: [Zope-dev] ZPatterns, ZClasses, Specialists: Assigningresponsibilities

2000-12-17 Thread Itai Tavor

Itai Tavor wrote:

I have the following ZClasses, with matching Specialists: Product, 
Graphic, Order, OrderLineItem. When a customer adds a product to 
their order, they have to provide a graphic file which will be 
printed on the product (imagine buying a lunch box with your cat's 
photo on it). The Graphics Specialist can provide a 
addGraphicSnippet form. But who's responsible for asking for this 
graphic when adding the product to the order? Is it still the 
Product object? But a Product turns into a Product-with-Graphic 
only when it's a part of an order, so is it correct for the Product 
to even know about Graphics? the alternative is to move the 
addToOrder methods to either Order or OrderLineItems, but this 
doesn't make any more sense because these would then have to know a 
lot more about a Product than is good for them. Any ideas?

Sounds to me like you have a new type of Product.

You have your basic products (of which there are many kinds), and 
you have ProductWithGraphic products. A ProductWithGraphic is a 
"calculated product": it is composed of a basic product and a 
graphic. Its cost, delivery time, packing charge, and so forth, are 
calculated based on the combination of the basic product and the 

To the rest of the application, a ProductWithGraphic is just another 
kind of product.

Thanks, this is an interesting suggestion... but I'm not sure how it 
would work. It gets very complicated when I try to think of 
implementing it.

The application accesses products using a Products Specialist, with a 
Rack for each type of product. The contents of these Racks make up 
the Product catalog of the store. The Products Specialist implements 
the role of 'things that can be added to an order'.

On the other hand, ProductWithGraphic is not part of the store's 
catalog. A new instance of it is created every time a shopper adds a 
product to their cart. So it does not fill the role 'thing that can 
be added to an order'. rather, its role is of something that has been 
ordered and is being fabricated.

So treating ProductWithGraphic as another kind of Product doesn't 
seem to make sense... I do realize I need a new kind of product - 
CustomizableProduct. But, looking at the role of a 
ProductWithGraphic, it looks a lot more like an OrderLineItem than a 
Product. It's part of an order. It's state changes are part of the 
order handling process. So wouldn't it make sense to have a 
lineItemWithGraphic object in the OrderLineItems Specialist? That 
seems much simpler to me... except that the responsibilities question 
in it is still open. Back to square 1.

This is how I see it:

- Products Specialist

- OrderLineItem Specialist

- product.addMeToOrder():
 order.addLineItem(product_id=id, add='lineItem')

- custimazable_product.addMeToOrder():
 order.addLineItem(product_id=id, add='lineItemWithGraphic')

I imagine, then, that the UI for uploading the graphic would be 
included in product.addMeToOrderForm, using a UI snippet from the 
OrderLineItemsWithGraphic Specialist. Then I could pass REQUEST on to 
order.addLineItem and to OrderLineItemsWithGraphic.add, which would 
then upload the file?

Woof... so long. I'd appreciate any comments on this - especially on 
the question on whether it's better to have a specialized type of 
OrderLineItem, or to link the standard OrderLineItem to a Product 
object in case of a standard product, or, in the case of a 
customizable product, to a new object which stores the graphic and 
tracks the fabrication of the customized item.


Itai Tavor"Je sautille, donc je suis."
C3Works[EMAIL PROTECTED]  - Kermit the Frog

"If you haven't got your health, you haven't got anything"

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