[ic] How do I get choice fields like "color" working?

[Mike Heins]

Quoting Marisa Giancarla (mgiancarla@macromedia.com):
> I'm trying to get choice fields working on an item by item basis, and can't
> figure out how it is supposed to be done. Under Tallyman I had matrixes, and
> could create (for example) 2 sets of choices for a given type of item. In my
> case of creating a "jewel case" item I would have one set called "graphics"
> and another called "episodes", and when the user ordered one of the items
> they could choose from a set of background graphics for the jewel case and
> choose which set of episodes they wished the jewel case labeled for. Neither
> choice was dependant on the other.
> 
> I'd like to do the same thing in Interchange, but I can't figure out how I
> would do this other than creating a distinct separate item for each of the
> possible combinations which isn't practical or aesthetically pleasing. Plus
> I'd really like it to all get credited to the same SKU since technically
> they are ordering the same item (ie depleting the same item from my stock)
> nomatter what combination they choose as they get printed specifically for
> each order.
> 
> I assume that the existing "color" field works this way, where a set of
> available "colors" for that item can be entered and the user can choose, but
> I don't know how I would set up the new fields I added to work in the same
> way, or if it is safe to just rename the "color" and "size" fields and just
> use them.

You are pretty much on target -- there is no UI-oriented way to make the
options malleable. Up to a reasonable limit (like 16 options per product)
you can add them as you desire. It is even possible (with difficulty, as
you need to specify the source table in the [item-accessories ...] call)
to maintain them in a separate table.

> 
> Could someone give me some quick pointers?

Basically, it is a question of finding the places in the templates
(including etc/log_transaction, etc/report, and etc/receipt) that
reference [item-modifier size], [item-modifier color], [item-modifier
accessories], etc. You can either rename them or add additional
instances.

You will also have to adjust the catalog.cfg directive "UseModifier".
If you add a field to the products database called "o_graphics" and
"o_episodes" (I am recommending the o_ prefix to prevent collision)
then you can put

	UseModifier  o_graphics o_episodes

and change all of the "color" and "size" settings to that.

Help will be on the way in 4.8. We will be introducing a new option-setting
mechanism more like Tallyman's matrix editor.

One of the problems I have wrestled with in that regard is the balance
between general database compatibility and the auto-handling of options.

  * If you build the option stuff into the database structure with
    foreign key constraints (like Tallyman did) you make the base
    product information only reasonably maintainable by the UI, as
    there are multiple records in multiple tables even for the
    simplest product. You also make customization of option display
    structure very difficult if the need doesn't fit the model (i.e.
    textbox or text-field options for monogramming).

  * If you simplify it, (like Minivend did) you cannot get the
    relationship tree automatically modifiable, and it is difficult
    to represent in a UI.

Either approach is difficult to automatically represent in editable
templates, but the Tallyman approach is much more so because you can't
process strings that have multiple sources, you have to do multi-table
selects that can be database-dependent. This effectively rules out
something like an on-the-fly product with options.

What I hope to do with the new model is allow both -- keep the existing
mechanism as well as adding an auto-modifier mechanism that is based
on tables maintained by the UI, and allow you to select either or both
on a product-by-product basis. 

-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

Be patient. God isn't finished with me yet.  -- unknown