Re: [mv] Art/Frames and CommonAdjust

[Marty Vance <mvance@lwm.com>]

******    message to minivend-users from Marty Vance <mvance@lwm.com>     ******

> That makes for a much better question.  I'm not
> going to include text here...
>
> > The root of my original question is "how do I get minivend to use the existing price table for
> > CommonAdjust?"
> >
> > Thanks for your input.  Maybe this info will help you give me a better solution.  I did create price
> > fields in the art and frame tables, as you originally suggested, set to 0.
>
> Were you able to get the catalog to work with those prices?  Let's
> not care if they are right or wrong or that you can select your
> favorite frame, just that the catalog works.   ;^)

I decided to create another table specifically for minivend to deal with for pricing:
create table pricing (
itemcode varchar(5) PRIMARY KEY,
size1 decimal(6,2) not null default '0.00',
size2 decimal(6,2) not null default '0.00',
size3 decimal(6,2) not null default '0.00',
size4 decimal(6,2) not null default '0.00',
size5 decimal(6,2) not null default '0.00',
size6 decimal(6,2) not null default '0.00',
size7 decimal(6,2) not null default '0.00',
size8 decimal(6,2) not null default '0.00',
size9 decimal(6,2) not null default '0.00',
size10 decimal(6,2) not null default '0.00');

Each column in this table comtains the data from the corresponding row in my existing price table.

My project manager and I think this approach would be the easiest to implement, but we realize it will make
the db admin harder.  We can deal with that.

I then added a size column to the art and frame tables.  For each record, this field contains 'size1=1,
size2=2, size3=3, ... size10=10'.

In my catalog.cfg file, I have

CommonAdjust    ==size:pricing:size:itemCode
UseModifier    size

The art and frame tables each have a price field (set to 0).

In my form, the option in the select box used for the size get assinged values of sizeX, where X is 1-10.  On
submission, this value gets inserted into mv_order_size.

I'm currently doing the art/frame as an order group.  The prices still show up as 0.

>
> Try to break apart the problem into a sequence of independant steps.
>
> CommonAdjust will "adjust" the price, but we need a price to adjust.  So
> get a catalog to work first, perhaps with a "Manager's Choice" or something.
> Then you will find it a simple matter of following docs to get CommonAdjust
> to change the price; **then** you will face the much more complex job of
> getting the right price.
>
> --
>
> TIMTOWTDI, having seen the data, maybe you want to precreate the items dynamically
> rather than trying to build them after the fact.  eg, if they select a particular
> item, visitor jumps to a page where that item and all related accessories
> are presented as preselected options or even preselected packages. That's
> almost certainly how we would do it.

I would be willing to explore an option like that, but the clients have specified how they want it to work.
As soon as we get their DNS worked out, I'll pass you the url.

>
>
> See http://www.mainelobsterdirect.com/ and click on link to "Fantasy Dinner".
> This builds a virtual item with pricing entirely independant of the per
> item a-la-carte pricing.  The database complexity is handled **before**
> the visitor sees it.
>
> Tell me if it does not make sense:  What if visitor selects a piece of art
> and clicks to a page where the various frame and size options are laid out
> and pre-priced like the Fantasy Dinner?  Do the db lookups and calculations
> **first**.  CommonAdjust would handle the specific pricing routine.
>
> --
>
> Please don't take this personally but as a comment on the experience
> you bring to this.  Hopefully I'm wrong, but given your level of minivend,
> perl and db experience I don't think you will be able to pull this off
> as you currently envision it.  You've done well to pick out excellent
> tools for the job; it's just you've only begun to learn how to use them.

I realize this.  Minivend is powerful, it's just strict and not documented well.

>
>
> What can you do to rethink the parameters?  In particular, can you offload some
> of the processing to simple perl/DBI scripts?  Suppose you brute force
> create 100,000 records with perl/DBI covering every allowable picture and
> frame?  mySQL won't burp on 100,000 records.  If you eliminate the joins and
> simplify your data structures you won't need to know much SQL and the
> CommonAdjust issue might even go away.  If that is what it takes to get it
> to work, you win.

This might be another option (I guess you mean condense everything, so the product codes would become
artID-frameID-size).

Any more ideas?

Marty Vance
LiveWire
mvance@lwm.com
www.lwm.com


-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list