Custom Product - Saving New Fields to Cart

[Lagg]

Thanks to help from the group, I was able to get a custom product
created, added to the admin, and show up in the store. (I followed
the method described here : http://thisismedium.com/tech/satchmo-diaries-part-one/
)

The product (MultiColorProduct) I created only differs only from the
default Product in that it has a (one) ManyToManyField( called
'colors' ) so that it can have multiple colors selected (Think tie dye
tshirt).

class MultiColorProduct(Product):
objects = ProductManager()

colors = models.ManyToManyField(Color)

def __unicode__(self):
return u'%s' % self.name


Now comes actually adding my MultiColorProducts to the cart.

Question 1)
How would be the best way to display a multiselect box with the
MultiColorProducts.colors as the options?
I did this in product/product.html

<select multiple="multiple" name="colors" id="id_colors">
{% for c in product.multicolorproduct.colors.all %}
<option value="1">{{c.name}}</option>
{% endfor %}
</select>

Obviously "option value" needs to change for each product (I just
threw the code in there for proof of concept), but isn't there a more
django-esk way of getting that data displayed? A form class or model
form class of some sorts? If so, how would I get that class
instantiated since I'm taking Bob Waycott's advice and not messing
with any views.

Question 2)
How should I go about getting the custom product data saved to the
cart? Should I try to get the cart to recognize custom data as
CartDetail data? Should I extend Cart into a custom Cart model? Should
I do something completely different?

Thanks in advance!

[Lagg]

I was reading (*gasp*) more of http://thisismedium.com/tech/satchmo-diaries-part-one/
- Part 2 and part 3 seem to describe what I want to do. (Part 3
specifically with the modification of the cart details). I think this
might be one solution to Question 2.

So, for Question 1, I'm going to assume that I need to hijack a signal
from Product, and write a listener function to add a form object to
the response, and then call that object in the template?

I'm not going to mark this as "Solved my own problem" because I'm
still open to any ideas.

Thanks in advance!

[Bob Waycott]

Do something like this?

<form action="{% url satchmo_smart_add %}" method="post">
<input type="hidden" name="quantity" id="quantity" value="1" />
<input type="hidden" name="productname" id="productname"
value="{{product.slug}}" />
<input type="submit" class="button submit" id="submit" name="addcart"
value="Order Product"/>
</form>

Passing a product.slug & quantity to satchmo_smart_add should be all you
need to get an item in the cart.

As for adding details to the cart, you are right on the money as far as
using a listener. It is the cleanest & most maintainable way to take
care of that need, and exactly what signals are for -- which is why I
documented it in that blog post.

Really, you shouldn't have to do much of anything special to get an item
into the Cart.

As for your need on the multicolor options, your select box looks fine
to me. You don't have to create a form for every element. If you do want
to create a Django form, you may wind up having to create a custom view
(note, I said custom view, not modify Satchmo's views).

Customizing Satchmo for your needs is always going to lead you down the
path of writing code. The more you want to customize, the more you will
be coding.

Happy coding!

[Lagg]

Just a follow-up:

Yes, a listener on "satchmo_cart_details_query" did exactly what I
needed (pretty much just like part 2 & 3 of the above mentioned
article)

I hunted around for a signal for loading product, but there wasn't
one, I didn't feel like adding one, and I decided that what I had from
before would work if I just fleshed it out some more (and It did
work!)

Side Question:

How come I have to do "product.multicolorproduct.colors.all" to get
the color list? Shouldn't it just be "product.colors.all" ( I would
think that product would be an instance of MultiColorProduct )? I
could only get the former to work, so I'm curious to wither that is a
satchmo thing, or a python thing I just haven't seen before?

On Aug 26, 8:35 am, Bob Waycott <bobwayc...@gmail.com> wrote:
> Lagg wrote:

> > I was reading (*gasp*) more ofhttp://thisismedium.com/tech/satchmo-diaries-part-one/

[Bob Waycott]

Lagg,

The reason you have to use product.multicolorproduct.colors.all() is that the view is returning a Product instance. It is not returning a MultiColorProduct instance. If the view were modified so that `product` was a MultiColorProduct instance, then you could use product.colors.all(), as well as directly access all Product model fields, such as product.sku, product.slug, product.name, etc.

So, the gist is that unless you start writing your own views to supersede Satchmo's, Satchmo views always return Product instances. Django is great in that you don't even have to perform the MultiColorProduct lookup because the ORM returns it as a reverse lookup on the basis of it being an inherited model.

Bob

[Lagg]

Ah okay, I looked at the view and I see where it's getting that
information from now. I thought that maybe it was sprouting some
magical class inheritance property that I haven't seen before (which
wouldn't surprise me. I don't know as much about python as I think I
do. My mind almost melted when I first saw decorators)

On Aug 28, 8:37 am, Bob Waycott <bobwayc...@gmail.com> wrote:
> Lagg,
>
> The reason you have to use product.multicolorproduct.colors.all() is
> that the view is returning a Product instance. It is not returning a
> MultiColorProduct instance. If the view were modified so that `product`
> was a MultiColorProduct instance, then you could use
> product.colors.all(), as well as directly access all Product model
> fields, such as product.sku, product.slug, product.name, etc.
>
> So, the gist is that unless you start writing your own views to
> supersede Satchmo's, Satchmo views always return Product instances.
> Django is great in that you don't even have to perform the
> MultiColorProduct lookup because the ORM returns it as a reverse lookup
> on the basis of it being an inherited model.
>
> Bob
>
> Lagg wrote:
> > Just a follow-up:
>
> > Yes, a listener on "satchmo_cart_details_query" did exactly what I

> > needed (pretty much just like part 2&  3 of the above mentioned

> >> Passing a product.slug&  quantity to satchmo_smart_add should be all you

> >> need to get an item in the cart.
>
> >> As for adding details to the cart, you are right on the money as far as

> >> using a listener. It is the cleanest&  most maintainable way to take