Re: history file

This WebDNA talk-list message is from

2002

It keeps the original formatting. numero = 43594
interpreted = N
texte = HiI would like to make sure that when someone logs onto the website that all his previous purchases are shown on a user page which he has to log onto with the username and password he created the first time he joined, what is the easiest way of doing this?Is there a way of adding multiple SKU numbers to his entry in the clients.db file I have rather than search all the old orders as i would rather do it this wayAny help appreciatedPaul-----Original Message-----From: Brian Fries To: (WebCatalog Talk)Date: Thu, 19 Sep 2002 12:03:02Subject: Re: RFE: [include file=filename.inc&strip=t]> Sure:> > gTrim.db:> > from to> %09> %0B> %0D> > I think you may want to add %0A if you're on Windows.> > At 1:57 PM 9/19/02, Gary Krockover wrote:> >Brian, can you post, or email the gTrim.db that you use?> >> >Thx,> >GK> >> >> >| What I use, which proves simpler and faster than a slew of comment> >| contexts, is a global ConverChars database that trims EOL and TAB> >| characters. Most of my include files now look like:> >|> >| [!]header comments...> >| [/!] [ConvertChars db=^db/gTrim.db]> >| [code]> >| [nested code]> >| [/nested code]> >| [/code]> >| [response text]> >| [/ConvertChars]> >|> >|> >| I also use this in contexts like [replace]...> >|> >| [replace db=...][ConvertChars db=^db/gTrim.db]> >| field1=value1> >| &field2=value2> >| [/ConvertChars][/replace]> >|> >|> >| This method won't work for leading / trailing space characters, as> >| they may be needed in the response text, but if you're careful to> >| just use tabs to indent your code, it works great.> >|> >| Rumor has it that 5.0 will include a [trim] context that will do a> >| similar thing (and hopefully deal with leading / trailing spaces as> >| well). I also requested the ability to define functions / macros> that> >| could specify a return value, which would also help this situation.> >|> >| I would prefer to specify the strip or trim option inside the> >| INCLUDE file rather than in the [include] tag, so the calling code> >| doesn't need to know how the include file was coded.> >|> >| - brian> >|> >|> >| At 1:20 PM 9/19/02, John Peacock wrote:> >| >Working with the two include files I just posted, I was again> >| >reminded how stupid WebDNA is with regard to extraneous> whitespace> >| >like EOL characters. Sure, when displayed to a HTML browser,> >| >multiple EOL's or spaces will be supressed. However, just looking> >| >at the maze of [!][/!] contexts I had to put in that file> emphasizes> >| >that this is poorly designed behavior.> >| >> >| >I have long argued that only a handful of contexts require> >| >maintaining the EOL characters ([sendmail] and [writefile] being> the> >| >two most obvious). Every single other context could easily strip> >| >EOL's without interfering in the coding in the slightest. Grant> >| >shot me down, I think because it would mean branching the parser to> >| >know when to strip and when not to strip, based on context.> >| >> >| >Hence, my suggestion that the [include] context at the very least> >| >include a strip=t option (defaults to F) so that it would be much> >| >easier to write user defined functions. I want to return only the> >| >text I want to return, without extraneous EOL characters, and> >| >without having to load up my source code with an unreadable mass of> >| >[!][/!] contexts.> >| >> >| >In fact, if the parser were altered to support this for all> >| >contexts, defaulting to F, I could reduce the size of my pages by a> >| >significant percentage, just by supressing those stupid EOL's.> >| >> >| >When writing CGI code in Perl, I usually turn off the extra EOL's> >| >after I have debugged the code. It makes view source less useful,> >| >but it has a definite impact on how fast the page loads to have all> >| >of the HTML on basically a couple of lines.> >| >> >| >Thanks> >| >> >| >John> >| >> >| >--> >| >John Peacock> >| >Director of Information Research and Technology> >| >Rowman & Littlefield Publishing Group> >| >4720 Boston Way> >| >Lanham, MD 20706> >| >301-459-3366 x.5010> >| >fax 301-429-5747> > -------------------------------------------------------------> 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/-------------------------------------------------------------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:

Re: history file (Donovan 2002)
Re: history file (Paul 2002)

HiI would like to make sure that when someone logs onto the website that all his previous purchases are shown on a user page which he has to log onto with the username and password he created the first time he joined, what is the easiest way of doing this?Is there a way of adding multiple SKU numbers to his entry in the clients.db file I have rather than search all the old orders as i would rather do it this wayAny help appreciatedPaul-----Original Message-----From: Brian Fries To: (WebCatalog Talk)Date: Thu, 19 Sep 2002 12:03:02Subject: Re: RFE: [include file=filename.inc&strip=t]> Sure:> > gTrim.db:> > from to> %09> %0B> %0D> > I think you may want to add %0A if you're on Windows.> > At 1:57 PM 9/19/02, Gary Krockover wrote:> >Brian, can you post, or email the gTrim.db that you use?> >> >Thx,> >GK> >> >> >| What I use, which proves simpler and faster than a slew of comment> >| contexts, is a global ConverChars database that trims EOL and TAB> >| characters. Most of my include files now look like:> >|> >| [!]header comments...> >| [/!] [ConvertChars db=^db/gTrim.db]> >| [code]> >| [nested code]> >| [/nested code]> >| [/code]> >| [response text]> >| [/ConvertChars]> >|> >|> >| I also use this in contexts like [replace]...> >|> >| [replace db=...][ConvertChars db=^db/gTrim.db]> >| field1=value1> >| &field2=value2> >| [/ConvertChars][/replace]> >|> >|> >| This method won't work for leading / trailing space characters, as> >| they may be needed in the response text, but if you're careful to> >| just use tabs to indent your code, it works great.> >|> >| Rumor has it that 5.0 will include a [trim] context that will do a> >| similar thing (and hopefully deal with leading / trailing spaces as> >| well). I also requested the ability to define functions / macros> that> >| could specify a return value, which would also help this situation.> >|> >| I would prefer to specify the strip or trim option inside the> >| INCLUDE file rather than in the [include] tag, so the calling code> >| doesn't need to know how the include file was coded.> >|> >| - brian> >|> >|> >| At 1:20 PM 9/19/02, John Peacock wrote:> >| >Working with the two include files I just posted, I was again> >| >reminded how stupid WebDNA is with regard to extraneous> whitespace> >| >like EOL characters. Sure, when displayed to a HTML browser,> >| >multiple EOL's or spaces will be supressed. However, just looking> >| >at the maze of [!][/!] contexts I had to put in that file> emphasizes> >| >that this is poorly designed behavior.> >| >> >| >I have long argued that only a handful of contexts require> >| >maintaining the EOL characters ([sendmail] and [writefile] being> the> >| >two most obvious). Every single other context could easily strip> >| >EOL's without interfering in the coding in the slightest. Grant> >| >shot me down, I think because it would mean branching the parser to> >| >know when to strip and when not to strip, based on context.> >| >> >| >Hence, my suggestion that the [include] context at the very least> >| >include a strip=t option (defaults to F) so that it would be much> >| >easier to write user defined functions. I want to return only the> >| >text I want to return, without extraneous EOL characters, and> >| >without having to load up my source code with an unreadable mass of> >| >[!][/!] contexts.> >| >> >| >In fact, if the parser were altered to support this for all> >| >contexts, defaulting to F, I could reduce the size of my pages by a> >| >significant percentage, just by supressing those stupid EOL's.> >| >> >| >When writing CGI code in Perl, I usually turn off the extra EOL's> >| >after I have debugged the code. It makes view source less useful,> >| >but it has a definite impact on how fast the page loads to have all> >| >of the HTML on basically a couple of lines.> >| >> >| >Thanks> >| >> >| >John> >| >> >| >--> >| >John Peacock> >| >Director of Information Research and Technology> >| >Rowman & Littlefield Publishing Group> >| >4720 Boston Way> >| >Lanham, MD 20706> >| >301-459-3366 x.5010> >| >fax 301-429-5747> > -------------------------------------------------------------> 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/-------------------------------------------------------------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/ Paul

DOWNLOAD WEBDNA NOW!

Re: history file

2002

Top Articles:

Related Readings: