Re: Price Not Appearing
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 28444
interpreted = N
texte = >on 03/02/00 9:02 AM, jpeacock@univpress.com at jpeacock@univpress.com wrote: > >> Do you have a field called price in your database? If you do, change it to >> my_price (or anything else). When you are inside an orderfile context (either >> implied or explicit), the field [price] from the orderfile will override any >> field of the same name in the database. The best methodology to follow is to >> assign the appropriate price at the point a line is added to the shoppingcart >> (usually through the use of formulas.db). > >Thanks. I tried changing the name of the price field to myprice. It >worked on some pages, but not on others (as did just using price), so I >revised the database to have a field for price and another for myprice. >This sorta worked, but it just doesn't seem right to have to work around a >problem this way. I definitely agree, it doesn't seem right but that's just the way it is. Maybe SM will consider this situation as a genuinedrawback now that someone new has mentioned it once again.It seems like this issues relates directly to the fact that webcatalog uses common names for the fields in the shopping cart as well as the exact same names in the catalog.db -- thus causing conflicts inside orderfile contexts which appear inside founditems contexts or vice versa ...If only the shopping cart fields all had a prefix of pcs or sm for example, then there would never be any confusion or conflicts between the field names in a database and the field names in a cart file, because the field names would never have to be the same, so the tags would not be the same either.Let's say for example, that instead of the cart file having a field called price it had a field called smPrice.If this were the case, it becomes very clear that the [smPrice] field would *NEVER* be confused with the [price] field in the database, so we wouldn't have to build our own convoluted work-arounds in order to get the value we need and want, instead we would always end up with the right value exactly where we expect it to be.But unfortunately that's not the case when using webcatalog, so instead we must deal with these conflicts ourselves -- by using unintuitive work-arounds just to be able to get at the information we need on the pages where we need that information.A similar problem occurs with tags such as [date] which mean one thing inside an orderfile context and something else when outside an orderfile context -- and God forbid that we create a field in our database named date!Of course, these problem could be resolved by SM rebulding their software to adopt a new tag-naming standard, something like [smOrderDate] for the orderfile date field and [smTodaysDate] for the global date tag, etc.But will this ever happen???It doesn't seem like the engineers thought of of this potential problem until they already started selling webcatalog years ago. Then instead of fixing it ASAP when they were first alerted to the issue, they 'grandfathered' the problem into every new version, in an apparent effort to remain backward-compatible with previous versions.Well, backawrd compatibility makes sense -- to a point -- and then it becomes a serious hindrance. I cannot remember anyone at PCS/SM talking about changing this in all the years I have been using webcatalog, so it looks like we may be stuck with these conflicts for years to come -- unless we develop our own work-arounds.That's why several years ago I developed a completely separate cart system for my own webdna development work. My system never deals with these issues because it completely ignores the webcatalog cart system in favor of a faster model which provides far greater speed and flexibility in many other areas as well.Maybe I should market my pre-built cart solution as a value-added option to webcatalog, so other webdna programmers can take advantage of it as well ... :)================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server. To end your Mail problems go to
.This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to
Associated Messages, from the most recent to the oldest:
>on 03/02/00 9:02 AM, jpeacock@univpress.com at jpeacock@univpress.com wrote: > >> Do you have a field called price in your database? If you do, change it to >> my_price (or anything else). When you are inside an orderfile context (either >> implied or explicit), the field [price] from the orderfile will override any >> field of the same name in the database. The best methodology to follow is to >> assign the appropriate price at the point a line is added to the shoppingcart >> (usually through the use of formulas.db). > >Thanks. I tried changing the name of the price field to myprice. It >worked on some pages, but not on others (as did just using price), so I >revised the database to have a field for price and another for myprice. >This sorta worked, but it just doesn't seem right to have to work around a >problem this way. I definitely agree, it doesn't seem right but that's just the way it is. Maybe SM will consider this situation as a genuinedrawback now that someone new has mentioned it once again.It seems like this issues relates directly to the fact that webcatalog uses common names for the fields in the shopping cart as well as the exact same names in the catalog.db -- thus causing conflicts inside orderfile contexts which appear inside founditems contexts or vice versa ...If only the shopping cart fields all had a prefix of pcs or sm for example, then there would never be any confusion or conflicts between the field names in a database and the field names in a cart file, because the field names would never have to be the same, so the tags would not be the same either.Let's say for example, that instead of the cart file having a field called price it had a field called smPrice.If this were the case, it becomes very clear that the [smPrice] field would *NEVER* be confused with the [price] field in the database, so we wouldn't have to build our own convoluted work-arounds in order to get the value we need and want, instead we would always end up with the right value exactly where we expect it to be.But unfortunately that's not the case when using webcatalog, so instead we must deal with these conflicts ourselves -- by using unintuitive work-arounds just to be able to get at the information we need on the pages where we need that information.A similar problem occurs with tags such as [date] which mean one thing inside an orderfile context and something else when outside an orderfile context -- and God forbid that we create a field in our database named date!Of course, these problem could be resolved by SM rebulding their software to adopt a new tag-naming standard, something like [smOrderDate] for the orderfile date field and [smTodaysDate] for the global date tag, etc.But will this ever happen???It doesn't seem like the engineers thought of of this potential problem until they already started selling webcatalog years ago. Then instead of fixing it ASAP when they were first alerted to the issue, they 'grandfathered' the problem into every new version, in an apparent effort to remain backward-compatible with previous versions.Well, backawrd compatibility makes sense -- to a point -- and then it becomes a serious hindrance. I cannot remember anyone at PCS/SM talking about changing this in all the years I have been using webcatalog, so it looks like we may be stuck with these conflicts for years to come -- unless we develop our own work-arounds.That's why several years ago I developed a completely separate cart system for my own webdna development work. My system never deals with these issues because it completely ignores the webcatalog cart system in favor of a faster model which provides far greater speed and flexibility in many other areas as well.Maybe I should market my pre-built cart solution as a value-added option to webcatalog, so other webdna programmers can take advantage of it as well ... :)================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server. To end your Mail problems go to .This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to
Kenneth Grome
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
HTML E-mails demystified (2002)
Help with database strategy (1998)
Search Command, multiple dbs, etc. --still confused (2000)
multiple price line in formula.db (2004)
WebDNA and Virtual Servers (2003)
Has anyone used SecurePay for credit card payments? (2005)
[WebDNA] Some JS help please (2010)
[HIDEIF] inside [FOUNDITEM] (1997)
searchable list archive (1997)
[shownext max (1997)
Nested Loops and SHOWIFs (1997)
MATH TIME (1997)
ShowNext Command (1997)
tiny Linux issue (1999)
Calendar Snippet Problems (1998)
ssl support WDNA 5.0 (2003)
WCS Newbie question (1997)
A little syntax help (1997)
WebCat2b15MacPlugIn - [authenticate] not [protect] (1997)
Nesting format tags (1997)