Re: 2nd Request for help/advice on variable pricing
This WebDNA talk-list message is from
2000
It keeps the original formatting.
numero = 34870
interpreted = N
texte = > > > > seems easier to me stick all the field values in orderfile headers so you can > > simply use imputs with predefined values equal to those headers.> > I'm not exactly sure what you mean by using inputs with predefined values. > Do you mean the input name equals a particular header? which will evaluate to- when Header14 has no value yet but- when Header14 has a value of yes already> > > > when I use ?no_cache=[random][random][random] in my URLs I usually have no > > trouble with too much caching. > > Does that prevent caching of values?prevents browsers like IE from sending the user to a previosuly cached version of a page when the user clicked a link to go to the page a *2nd* time with a *different display* because something(s) have changed since the first time thru'. If you don't understand what I mean, then I recommend forgetting about it and dealing with any cach issues as they come up and are therefore crystal clear. Or if you want to plan ahead without knowing why till later, then just stick no_cache=[random][random][random] in all your URLs. You can pass as many variables in your URL as the browser allows characters in URL as far as I know. I have never hit a limit myself.> Can I still pass other variables > through the URL in addition to the no_cache, or does that only matter in a > GET submit where you can see the variables in the URL?all I said above applies to URLs. Not post forms. I don't know if you need to pass no_cache=[random][random][random] in a hidden input for post forms or not. I don't yet and someone here once said you don't need to.> > > > > >> 3. After data is written to the temp storage db, customer is taken to the > >> checkout/payment page. He enters his credit card info, the order is > >> processed, and then, if the order succeeds, the info is retrieved from the > >> temporary storage db and outputted to the text file. > > > > except I would simply create an identical record in the Approved.db and then > > delete the temp record. > > Do you mean use Approved.db instead of the text file? If so, I hope I > clarified that above, about needing the text file for the other branch of > the operation. Because I need to export the text file in a particular format > (it's a wacky pipe-delimited format) and with a particular name, a > standard WebCat db won't work as the export file. Also, the system that > it's exported to deletes the file after it retrieves it via FTP so that the > next AppendFile command will start a fresh file and it won't import the same > ad more than once.fine. You could still store approved orders as db records if you wanted to for some reason and generate the text files from those records as needed. But this maybe an unnecessary step. I only suggested using db records because webcat is great at handling them. Like what if you want to search for all the orders that were approved between 7 March and 14 march which were from customers in Wisconsin...? You know better than me what you need.> > > >> If the order fails for some reason, the ad info is just deleted from the > >> temporary storage db. > > > > maybe give the user a chance to rectify the situation, and then delete his > > record if he doesn't respond in a reasonable amount of time...? > > That's a good idea that I had already thought of, too, and I'll implement it > as I can. > > Thanks again for all the advice. I greatly appreciate it. When I get > experienced enough that I can help people, I'll do all I can to answer > requests for help on this list and give back to the community some.we're all winging it ;-) ------------------------------------------------------------- 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 Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
> > > > seems easier to me stick all the field values in orderfile headers so you can > > simply use imputs with predefined values equal to those headers.> > I'm not exactly sure what you mean by using inputs with predefined values. > Do you mean the input name equals a particular header? which will evaluate to- when Header14 has no value yet but- when Header14 has a value of yes already> > > > when I use ?no_cache=[random][random][random] in my URLs I usually have no > > trouble with too much caching. > > Does that prevent caching of values?prevents browsers like IE from sending the user to a previosuly cached version of a page when the user clicked a link to go to the page a *2nd* time with a *different display* because something(s) have changed since the first time thru'. If you don't understand what I mean, then I recommend forgetting about it and dealing with any cach issues as they come up and are therefore crystal clear. Or if you want to plan ahead without knowing why till later, then just stick no_cache=[random][random][random] in all your URLs. You can pass as many variables in your URL as the browser allows characters in URL as far as I know. I have never hit a limit myself.> Can I still pass other variables > through the URL in addition to the no_cache, or does that only matter in a > GET submit where you can see the variables in the URL?all I said above applies to URLs. Not post forms. I don't know if you need to pass no_cache=[random][random][random] in a hidden input for post forms or not. I don't yet and someone here once said you don't need to.> > > > > >> 3. After data is written to the temp storage db, customer is taken to the > >> checkout/payment page. He enters his credit card info, the order is > >> processed, and then, if the order succeeds, the info is retrieved from the > >> temporary storage db and outputted to the text file. > > > > except I would simply create an identical record in the Approved.db and then > > delete the temp record. > > Do you mean use Approved.db instead of the text file? If so, I hope I > clarified that above, about needing the text file for the other branch of > the operation. Because I need to export the text file in a particular format > (it's a wacky pipe-delimited format) and with a particular name, a > standard WebCat db won't work as the export file. Also, the system that > it's exported to deletes the file after it retrieves it via FTP so that the > next AppendFile command will start a fresh file and it won't import the same > ad more than once.fine. You could still store approved orders as db records if you wanted to for some reason and generate the text files from those records as needed. But this maybe an unnecessary step. I only suggested using db records because webcat is great at handling them. Like what if you want to search for all the orders that were approved between 7 March and 14 march which were from customers in Wisconsin...? You know better than me what you need.> > > >> If the order fails for some reason, the ad info is just deleted from the > >> temporary storage db. > > > > maybe give the user a chance to rectify the situation, and then delete his > > record if he doesn't respond in a reasonable amount of time...? > > That's a good idea that I had already thought of, too, and I'll implement it > as I can. > > Thanks again for all the advice. I greatly appreciate it. When I get > experienced enough that I can help people, I'll do all I can to answer > requests for help on this list and give back to the community some.we're all winging it ;-) ------------------------------------------------------------- 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 Web Archive of this list is at: http://search.smithmicro.com/
John Butler
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...