Re: Re: CCK fields

konsumer's picture
Offline
Joined: 03/06/2008
Juice: 6
Re: Re: CCK fields

What I mean is there is all this extra stuff. Like in order to not have shipping for a single content-type show up in the edit form, I have to make a hook_form_alter() and hide it. If I don't agree with the product model (I don't have 3 price fields for any products) and the client will be way overwhelmed by options that have nothing to do with their stock, then I have to do alot of tweaking. I think it would be awesome if it just added a content-type (using the default product fields as you say) and they were actually controllable in UI (CCK style) so I could remove fields I don't use. The ecommerce module uses "features" like this (which in my install of ubercart, there are no "features") to modularize the product model, but it's still not as cool as being able to just get rid of things that I really don't need, or change the labels in the UI, or make fields not required by clicking a checkbox.

Ubercart already has a CCK dependency (correction: it suggests it's use), so it wouldn't add anything. This would mean that I could use the muriad of other CCK modules to play with the values, too, like attributes are just tokens for SKU, and a computed field for price. This would mean that I could use the UI to make crazy price adjustments like "if they order a comb, a brush is %50 off". Autonodetitle or pathauto on things like product-attributes? To do things like this now, I am copying values from CCK fields, and manipulating built-in fields in hook_cart_item() and hook_form_alter(). I think it'd be great if I didn't have that extra step for advanced stuff (unless, of course, there wasn't already a CCK way of doing it, in which case I could write a much smaller custom module, that could be used in many applications.)

I mean, ubercart really great, don't get me wrong, but I have spent alot of time var_dump()'ing $form, and $item, and playing around with things, in order to change the way the product edit forms are displayed (the API reference is awesome, by the way.) I think it would save time, at least for me, if the product-classes were just content-type dumps to be used as defaults, but everything was manipulatable, and mapped to things the cart needs (like price, weight, and stock.)

I guess I imagine my perfect shopping cart acting more like views (and alot of the functionality could actually be handled by views, as it is in ubercart) in that you can override frontpage and taxonomy_term in UI, to do whatever you want to it. I think if it were all built with sensible defaults (just like ubercart) it wouldn't be any harder to get going for new people, but it would be super-easy to customize (and have tons of cool features, out of the box) for anyone who has worked on a views/cck site. If the cart was just a node holder, or some sort of view, and shipping and payment was just a node-processor (all 3 using using mapping to the CCK fields that represent things like weight, price, and stock) then I wouldn't have write as much code.

Maybe I'm just not understanding how ubercart works, so forgive me if I am missing something, but I am really addicted to the amount of cool stuff you can do with just CCK/Views, and this has been my only real frustration with ubercart. Other then that, I think it's perfect, and it's definitely more cohesive and easier to work with, for me, then the ecommerce module.

Sorry for the rant...

Adding extra fields to the product By: sajt (27 replies) Sun, 02/17/2008 - 12:22