Hi,

I'm working with a shop which needs to extend CartItem and OrderItem
instances with additional data. I mean it adds *ItemDetails and also
external models which have OneToOne relation to *Item objects. To make
it working without refactoring Satchmo models to my own needs, I tried
to find a flexible solution which could help others create similar
extensions in future.

The result is an extended signals set for Satchmo and changed CartItem
stacking:

1. satchmo_cart_details_query signal, which is launched just before a
new CartItem is created.

#satchmo_cart_details_query.send(cart, product, quantity, details,
request, formdata)

The key item here is details={} dict, which can be filled by listeners
with additional item details.

Please notice that the signal provides listeners with a request object
which has been passed to satchmo_cart_add view. This means additional
parameters for item can be passed to external applications without the
need to override satchmo_cart_add with own custom view.

2. Here comes the CartItems stacking patch which I submitted (http://
www.satchmoproject.com/trac/ticket/484). In simple words, only the
same products with exactly equal set of details can be stacked in a
cart as one CartItem. This allows us to preserve details set by
external applications.

3. satchmo_post_copy_item_to_order signal, which is launched just
after all Product and detail data has been copied from CartItem to
OrderItem.

#satchmo_post_copy_item_to_order.send(cart, cartitem, order,
orderitem)

Both Items are passed as arguments to the listeners. External
applications can copy their model instances.

I think that such changes are completely neutral for existing
applications. The only doubts are expressed in already submitted #484
description, but these are minor issues.

At the moment I cannot provide a complete patch, because after Django
signals refactoring it's already obsolete :)

@Bruce: I know you're working on multi-shop branch and the signals
have been updated there. Can you estimate the date of merging it into
trunk? If it's not going to happen soon, maybe I could switch to
branch and submit my patch there?

--
michał

2008/8/8 michal salaban <michal.sala...@gmail.com>

This is very similar to the solution I've adopted (on the multi-shop branch)
for
allowing the user profile to be extended by apps such as the newsletter app.

Your proposed solution sounds good at first reading.

At the moment I cannot provide a complete patch, because after Django

Also, I've completely removed all the order objects from the Contact model,
where they fit very poorly anyway, and which set up a very tricky to resolve
circular app dependency.  So a patch to any of those objects would be
awkward to merge anyway.

I really do like the modified signals system, by the way.  The syntax is
better
and now I don't always have to go look up the proper imports and such to
send
or connect to signals.

@Bruce: I know you're working on multi-shop branch and the signals

Merge to trunk is still a couple days out, but I hope to release a beta
commit
of the branch today or tomorrow.  The branch is working with multiple shops
but I need to do more testing & tweaking, especially in the admin area.

--
Bruce Kroeze
http://solidsitesolutions.com
Dynamic Designs, Optimized

Hi,

Well, the code of signals extension is already available here:
http://www.satchmoproject.com/trac/ticket/496

Also, I added new patch for #484, which is required for #496 to work:
http://www.satchmoproject.com/trac/ticket/484

Please note, that both patches are made against multi-shop branch.

--
mihau