> I am indeed to a certain extent duplicating the existing system, purposely
> in order to preserve some measure of compatability with future Freetrade
> developments and because I can see areas where it has merit. Want to have my
> cake and eat it too.
>
> In the current structure the shirt manufacturer who modifies the color1
> attribute makes a global modification which affects all skus using the
> color1 attribute. While in some instances this might be desirable, in others
> it would be disasterous - especially since this happens without advising the
> administrator of the consequences. I suggest that an alternate mechanism
> should be provided, or the current mechanism modified.
> I have provided for a measure of global level control by allowing the admin
> to create option templates. These templates can be used as the basis for
> creating item-level option lists. ie when creating option lists the admin is
> presented with a list of templates which he can use and modify, or he can
> create new lists. I therefore now have two co-existing mechanisms -
> attributes which are global in scope, and options which are specific to the
> current item. These could easilly be combined using a flag for scope, but I
> havn't done so for compatability reasons. Besides I've only added 4 tables
> and 6 screens - hardly a huge overhead.
>
> The list of attributes that appears on each sku can indeed be quite long. On
> the smallish (200 item) site I'm working on now there would be at least 20
> (multiple color lists, sizes, legnths, etc..). Managing attributes at the
> item/sku level simplifies the screens for the administrator, with less
> chance for confusion.
>
> I'm still left with my initial question (my fault for the long preamble). In
> real life each color/size/whatever combination is a separate sku. This could
> be accomadated by allowing the admin to create a base sku, then duplicating
> it, assigning a new sku# and selecting the unique combination of attributes
> for that sku. This would be presented to the web user using Javascript
> arrays to build the co-dependant select dropdowns.
> Is this reliance on Javascript suicidal in the real world? How many users
> have Javascript disabled? Is it reasonable to insist that Javascript be
> enabled in order to use the site?
>
> The only alternative I can see is to build a post-processor that converts
> base-sku-attribute combinations into final sku's for order-entry and
> inventory tracking. This could also be used as a fall-back when the user has
> Javascript disabled.
>
> This may all seem like nit-picking, but once you look at maintaining on-line
> inventories and integration with off-line order processing systems these all
> become serious issues.
>
> Earl Wyllie
> [EMAIL PROTECTED]
Earl,
Perhaps you can use multiple SKUs and then hack the item screen so that
it uses JavaScript enabled pull downs. If the browser doesn't have
JavaScript, just fall back to an exhaustive listing of the SKUs (sorted,
naturally). You MUST deal with non-JavaScript browsers, but you don't
necessarily have to make it "pretty" for them. Then, within your action
module, do strong error checking to make sure that the user followed the
rules.
-jj
--
if (shannon - jj) * behrens == webEngineer["CLEAR INK�"]:
print "<i>imagination is the only real medium(sm)</i><br>"
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
