Re: [mezzanine-users] SHOP_OPTION_TYPE_CHOICES out of settings

102 views

Skip to first unread message

Stephen McDonald

unread,

Nov 11, 2012, 3:11:42 PM11/11/12

to mezzani...@googlegroups.com

There's an existing thread where we discussed this in greater detail:

https://groups.google.com/group/mezzanine-users/browse_thread/thread/b20aa16ec1ad6465

TLDR is that the hard-coded option types and everything that stems from it (generated option columns in the DB) could use some architectural refactoring. I'm not sure if putting the option types into the DB would go towards or even further against the problems described in that thread.

On Mon, Nov 12, 2012 at 1:56 AM, Emile <em...@tindie.com> wrote:

Because of how I'm using Cartridge, it's a bit inconvenient for the SHOP_OPTION_TYPE_CHOICES to be in settings. I'm guessing there is some rational I'm not thinking of for hardcoding this in settings vs making it an object. If anyone knows why, that would be great.

I'm thinking of taking it out of settings and letting it be a stand alone model like Category. The benefits being you can create new options within admin instead of having to change the settings file. What do you guys think? If so, I can do a pull request with this update in the next few weeks. Just wanted to get some feedback on it now...

Thanks

emile

--
Stephen McDonald
http://jupo.org

Brian Schott

unread,

Nov 12, 2012, 10:49:27 AM11/12/12

to mezzani...@googlegroups.com

Emile,

Could you give a pseudocode example? There were some concrete examples of two alternatives using Product and ProductVariation subclasses.

https://groups.google.com/d/topic/mezzanine-users/XPIUkII3Bkc/discussion

It would be helpful to support custom product models, because several of us are using this and hope to merge it upstream.

https://github.com/stephenmcd/cartridge/pull/57

I could see an alternative approach with a ProductVariations model that was similar to how Mezzanine Forms works. Let staff build the product forms custom and associate to a product. The only tricks is how to allow custom pricing based on form inputs. Also, we should agree on some sort of denormalized JSON dictionary passed through the cart. The 200 character description field isn't sufficient.