Re: P1: How to make webcatalog more stable. - LONG

This WebDNA talk-list message is from

1999


It keeps the original formatting.
numero = 24146
interpreted = N
texte = >>>1) the first time you come to the page, WebCatalog has no idea of the field >>>[email] so it will literally put the text [email] in the box. Ugly >>> >>>so we fix this by putting: >>>>>value=[hideif [email]=[raw][email][/raw]][email][/hideif]> >> >> That's a very OLD-FASHIONED way to hide the [email] tag! >> Why don't you try an up-to-date and far simpler method? >> >> There is a very *simple* technique available that uses text variables to >> make this field blank the first time you come to the page. Just put >> [text]email=[/text] at the top of the page and the email variable will be >> set to 'blank' before the form gets filled in by webcat -- which means you >> NEVER HAVE TO WORRY ABOUT HIDING IT EVER AGAIN!!! > >Almost every single form I code loops back to itself to do data validation >BEFORE redirecting to the next page. This way, if something is wrong, I can >fill in the bad data the user supplied back into the field they supplied it >in, and give them the chance to fix it. Brian, that's exactly what I do myself sometimes, and that part of your technique is good! I'm not disputing that part at all, but it seems like you're missing a crucial understanding of how webcatalog evaluates formvariables and text variables -- and that's why I tried to show you a 'better way' ...Please do not dismiss my technique just because it 'looks like' it won't work. It DOES WORK, and if you had tried it you would know it works ... :)You really have to understand this software inside and out in order to come up with this kind of coding technique. You all know I'm no webcat novice, and I certainly would never suggest a technique that doesn't work. I know how to use this software, and I'm telling you that my technique works, and it works well. If you try it yourself, you will see exactly what I mean, even if you don't understand 'why' it works ... :)>using your method, I would wipe out my data (depending on where I put your >tags) either before I error checked it, or before I allowed the visitor to >fix it. Neither is acceptable.No it will NOT wipe out your data, this is where you are wrong! Let me explain so you and others who might be interested can get a handle on this ...My technique is based on a webcatalog variable hierarchy which is probably not documented, so I cannot blame you or anyone else for not understanding this -- but it is very important that you DO understand this -- especially you Brian, since you're going to attempt to write a book about using webcatalog ... :)Here is the hierarchy of webcatalog variables that makes my technique work:When a formvariable is passed into a template, that formvariable OVERRIDES any text variable with the same name.That's all there is to it. This is not a theory, this is a fact. That's just the way it is, and this feature is what makes my technique so simple compared to yours. Look, here's an example:The first time someone visits your form page, no formvariables are being passed to the page, right? That's why you're using hideif's to hide the raw form tags such as [email] and others, because they do NOT have any values assigned to them when the visitor FIRST visits the form page, and webcat displays raw tags that don't have values pre-assigned to them.You don't want the raw tags showing up in the form, so you came up with your 'hideif' technique for hiding them. And your technique will work fine, I'm not disputing that either, I'm simply saying there is a *easier faster better* way to do it.Just think about this for a moment ...If you had placed [text]email=[/text] at the top of the page like I suggested previously, then the 'email' field would have a 'blank' value, wouldn't it? And that 'blank' value would be displayed in the form instead of the raw [email] tag, thus eliminating the need for your hideif's.Okay, my code has solved one problem, because now you no longer need hideif's to hide raw tags in your forms. If you simply set every form field to a blank value with text contexts at the top of the page, (or preferably a single text context using the 'multi=t' parameter) they will all be blank the first time someone visits the form page.Remember now, we are still only talking about the FIRST visit to the form page, since this is when there are no formvariables passed into the page, okay?Good, so now that happens?The visitor is looking at a blank form, so he fills in the form fields with his values and clicks the Submit button, and those values get passed to the next page. But the next page is actually the SAME PAGE, and this is the second visit to the page. And on this second visit, there are formvariables being passed to the page ...AND THATS THE BIG DIFFERENCE!Because when formvariables are passed into a page, they override all text variables on that page.Do you remember those text variables you set at the top of the page? Well, all those text variables are now being OVERRIDDEN by the formvariables being passed to the page on the second visit.This is the key!The blank text variables are being ignored by webcatalog now, because the formvariables are 'more important' to webcatalog, so the formvariables override the text variables that have the same names.Which means instead of losing the formvariables as you 'thought' would happen, instead those formvariables are overriding the text variables ... and your formvariables are still there!If you don't believe me, just try it, you'll see that it works.IT ALWAYS WORKS!I've been using this technique since webcat introduced text variables a year or more ago, and all my code uses this technique now. It's simple, fast and efficient.I don't blame you for not coming up with this technique yourself. It is certainly not an obvious a technique since it requires a thorough understanding of the hierarchy webcatalog of variables. Without that understanding, it's likely that a person might never come up with this technique.And even if a person understands webcatalog's variable hierarchy, this is still a technique that is not very intuitive, at least in my opinion. Fortunately it's a technique that simpy 'occurred' to me one day, and I'm happy to be able to share it with everyone else.It saves me a lot of webdna coding time. Try it, you'll like it!:)Kenneth Grome WebDNA Consultant Phone 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:

    
  1. Re: P1: How to make webcatalog more stable. - LONG (Miguel Castaneda 1999)
  2. Re: P1: How to make webcatalog more stable. - LONG (Kenneth Grome 1999)
  3. [offtopic]Re: P1: How to make webcatalog more stable. - LONG (Michael O Shea 1999)
  4. Re: P1: How to make webcatalog more stable. - LONG (Bob Minor 1999)
  5. Re: P1: How to make webcatalog more stable. - LONG (Brian B. Burton 1999)
  6. Re: P1: How to make webcatalog more stable. - LONG (Kenneth Grome 1999)
  7. P1: How to make webcatalog more stable. - LONG (Brian B. Burton 1999)
>>>1) the first time you come to the page, WebCatalog has no idea of the field >>>[email] so it will literally put the text [email] in the box. Ugly >>> >>>so we fix this by putting: >>>>>value=[hideif [email]=[raw][email][/raw]][email][/hideif]> >> >> That's a very OLD-FASHIONED way to hide the [email] tag! >> Why don't you try an up-to-date and far simpler method? >> >> There is a very *simple* technique available that uses text variables to >> make this field blank the first time you come to the page. Just put >> [text]email=[/text] at the top of the page and the email variable will be >> set to 'blank' before the form gets filled in by webcat -- which means you >> NEVER HAVE TO WORRY ABOUT HIDING IT EVER AGAIN!!! > >Almost every single form I code loops back to itself to do data validation >BEFORE redirecting to the next page. This way, if something is wrong, I can >fill in the bad data the user supplied back into the field they supplied it >in, and give them the chance to fix it. Brian, that's exactly what I do myself sometimes, and that part of your technique is good! I'm not disputing that part at all, but it seems like you're missing a crucial understanding of how webcatalog evaluates formvariables and text variables -- and that's why I tried to show you a 'better way' ...Please do not dismiss my technique just because it 'looks like' it won't work. It DOES WORK, and if you had tried it you would know it works ... :)You really have to understand this software inside and out in order to come up with this kind of coding technique. You all know I'm no webcat novice, and I certainly would never suggest a technique that doesn't work. I know how to use this software, and I'm telling you that my technique works, and it works well. If you try it yourself, you will see exactly what I mean, even if you don't understand 'why' it works ... :)>using your method, I would wipe out my data (depending on where I put your >tags) either before I error checked it, or before I allowed the visitor to >fix it. Neither is acceptable.No it will NOT wipe out your data, this is where you are wrong! Let me explain so you and others who might be interested can get a handle on this ...My technique is based on a webcatalog variable hierarchy which is probably not documented, so I cannot blame you or anyone else for not understanding this -- but it is very important that you DO understand this -- especially you Brian, since you're going to attempt to write a book about using webcatalog ... :)Here is the hierarchy of webcatalog variables that makes my technique work:When a formvariable is passed into a template, that formvariable OVERRIDES any text variable with the same name.That's all there is to it. This is not a theory, this is a fact. That's just the way it is, and this feature is what makes my technique so simple compared to yours. Look, here's an example:The first time someone visits your form page, no formvariables are being passed to the page, right? That's why you're using hideif's to hide the raw form tags such as [email] and others, because they do NOT have any values assigned to them when the visitor FIRST visits the form page, and webcat displays raw tags that don't have values pre-assigned to them.You don't want the raw tags showing up in the form, so you came up with your 'hideif' technique for hiding them. And your technique will work fine, I'm not disputing that either, I'm simply saying there is a *easier faster better* way to do it.Just think about this for a moment ...If you had placed [text]email=[/text] at the top of the page like I suggested previously, then the 'email' field would have a 'blank' value, wouldn't it? And that 'blank' value would be displayed in the form instead of the raw [email] tag, thus eliminating the need for your hideif's.Okay, my code has solved one problem, because now you no longer need hideif's to hide raw tags in your forms. If you simply set every form field to a blank value with text contexts at the top of the page, (or preferably a single text context using the 'multi=t' parameter) they will all be blank the first time someone visits the form page.Remember now, we are still only talking about the FIRST visit to the form page, since this is when there are no formvariables passed into the page, okay?Good, so now that happens?The visitor is looking at a blank form, so he fills in the form fields with his values and clicks the Submit button, and those values get passed to the next page. But the next page is actually the SAME PAGE, and this is the second visit to the page. And on this second visit, there are formvariables being passed to the page ...AND THATS THE BIG DIFFERENCE!Because when formvariables are passed into a page, they override all text variables on that page.Do you remember those text variables you set at the top of the page? Well, all those text variables are now being OVERRIDDEN by the formvariables being passed to the page on the second visit.This is the key!The blank text variables are being ignored by webcatalog now, because the formvariables are 'more important' to webcatalog, so the formvariables override the text variables that have the same names.Which means instead of losing the formvariables as you 'thought' would happen, instead those formvariables are overriding the text variables ... and your formvariables are still there!If you don't believe me, just try it, you'll see that it works.IT ALWAYS WORKS!I've been using this technique since webcat introduced text variables a year or more ago, and all my code uses this technique now. It's simple, fast and efficient.I don't blame you for not coming up with this technique yourself. It is certainly not an obvious a technique since it requires a thorough understanding of the hierarchy webcatalog of variables. Without that understanding, it's likely that a person might never come up with this technique.And even if a person understands webcatalog's variable hierarchy, this is still a technique that is not very intuitive, at least in my opinion. Fortunately it's a technique that simpy 'occurred' to me one day, and I'm happy to be able to share it with everyone else.It saves me a lot of webdna coding time. Try it, you'll like it!:)Kenneth Grome WebDNA Consultant Phone 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:

Calendar Solutions (1998) Configuring E-mail (1997) HELP WITH DATES (1997) [SearchString] problem with [search] context (1997) insecure client not shown (1998) Document Contains No Data! (1997) Nesting format tags (1997) Re[2]: searches with dash, period etc. (back form politenes (2000) Re:quit command on NT (1997) authenticating a second user (1997) [isfolder] and [filename] (1997) WebCatalog can't find database (1997) LOG IN LOG OUT (1997) b12 cannot limit records returned and more. (1997) please anybody help (2005) Can he do that? (1998) WebCat2b15MacPlugin - showing [math] (1997) Cold Fusion Buster (1997) Realtor Search (2000) Solution help needed (1998)