Re: RFE: [include file=filename.inc&strip=t]

This WebDNA talk-list message is from

2002

It keeps the original formatting. numero = 43593
interpreted = N
texte = Sure:gTrim.db:from to%09%0B%0DI 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/ Associated Messages, from the most recent to the oldest:

Re: RFE: [include file=filename.inc&strip=t] (Brian Fries 2002)
Re: RFE: [include file=filename.inc&strip=t] (Gary Krockover 2002)
Re: RFE: [include file=filename.inc&strip=t] (Brian Fries 2002)
RFE: [include file=filename.inc&strip=t] (John Peacock 2002)

Sure:gTrim.db:from to%09%0B%0DI 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/ Brian Fries

DOWNLOAD WEBDNA NOW!

Re: RFE: [include file=filename.inc&strip=t]

2002

Top Articles:

Related Readings: