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

This WebDNA talk-list message is from

2002

It keeps the original formatting. numero = 43591
interpreted = N
texte = 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.- brianAt 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)

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.- brianAt 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: