[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
[mvance@lwm.com: [mv] Re: Art/Frames and CommonAdjust (new thread name)]
****** message to minivend-users from "Mr. Christopher F. Miller" <cfm@maine.com> ******
> You're right about one thing: This is my first MV catalog. However, all my db experience can be summed
> up to what
> I've done for this project. I basically started working here and was told "Here, implement Minivend".
> The db was in place already, I've been modifying it as necessary. My Perl experience is just above basic
> (the first script I wrote used references in just about every line...I have yet to delve into module
> programming).
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. ;^)
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.
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.
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.
Best,
cfm
--
Christopher F. Miller, Publisher cfm@maine.com
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
1.207.657.5078 http://www.maine.com/
Database publishing, e-commerce, office/internet integration, Debian linux.
-
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
