Re: SMSI, please fix the StandardConversions.db

This WebDNA talk-list message is from

2005


It keeps the original formatting.
numero = 61223
interpreted = N
texte = >Without thinking about it to hard, don't platforms save CR's in different >formats? Isn't that why we have issues with sendmail formats when changing >platforms? I don't actually see a problem with Ken's change initially but >I am not sure about %0D always being the right character to change. Different platforms use different line break characters, but they should all save s as s and s as s. The *potential* problem comes when trying to accommodate Mac and Windows and Unix at the same time via convertchars or via any other single method, here's why: As far as invisible or line break characters are concerned, the StandardConversions.db only changes VT characters to
, which makes it deal properly with data coming out of all webdna db's. But when data is passed in a formvariable, convertchars has NONE of the required conversions in it to display line breaks properly on the web page. Original line break characters for all three OS's need to be converted, and these are: on macos on unix on windows Knowing this, it would appear to be *okay* to add the " to
" conversion to StandardConversions.db because this will make convertchars work on both mac and windows because they both have in their line breaks and those s will be changed to
s. Okay fine, we have a simple solution for two out of three platforms. But this won't fix the problem on Unix which uses s as line break characters ... and if we add a Unix solution to the StandardConversions.db it will break windows by create "double line spacing" when converting to

. The obvious solution might *appear* to be to use convertwords instead of convertchars -- with a new database that only converts the required line breaks and VT's. But the problem with convertwords is that it cannot handle (it does not properly recognize) %0D as or %0A as ... so it is basically impossible to use convertwords instead of convertchars. In other words, there is no universal solution that entails the use of either convertchars or convertwords, so now we are left with grep, either as a nested context with grep or another context, or possibly alone. I doubt a single grep search string can be constructed to to the required conversions. And there's no documentation provided for WebDNA's version of grep anyways. But even if there were a single search value that would work in grep, we would still have to custom code it every time we want to use it -- and this is nowhere near as simple or straightforward as using a simple context like convertchars. The bottom line is that it would benefit us very much if we had a NEW CONTEXT that would convert data and display it properly on the page -- whether it comes from a database or a formvariable -- and whether the line breaks are Max, Unix or Windows. But this requires SMSI to do it. -- Sincerely, Kenneth Grome www.kengrome.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://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Subject: Re: SMSI, please fix the StandardConversions.db ( Terry Wilson 2005)
  2. Re: SMSI, please fix the StandardConversions.db ( Kenneth Grome 2005)
  3. Re: SMSI, please fix the StandardConversions.db ( Donovan Brooke 2005)
  4. Re: SMSI, please fix the StandardConversions.db ( Kenneth Grome 2005)
  5. Re: SMSI, please fix the StandardConversions.db ( Donovan Brooke 2005)
  6. SMSI, please fix the StandardConversions.db ( Kenneth Grome 2005)
>Without thinking about it to hard, don't platforms save CR's in different >formats? Isn't that why we have issues with sendmail formats when changing >platforms? I don't actually see a problem with Ken's change initially but >I am not sure about %0D always being the right character to change. Different platforms use different line break characters, but they should all save s as s and s as s. The *potential* problem comes when trying to accommodate Mac and Windows and Unix at the same time via convertchars or via any other single method, here's why: As far as invisible or line break characters are concerned, the StandardConversions.db only changes VT characters to
, which makes it deal properly with data coming out of all webdna db's. But when data is passed in a formvariable, convertchars has NONE of the required conversions in it to display line breaks properly on the web page. Original line break characters for all three OS's need to be converted, and these are: on macos on unix on windows Knowing this, it would appear to be *okay* to add the " to
" conversion to StandardConversions.db because this will make convertchars work on both mac and windows because they both have in their line breaks and those s will be changed to
s. Okay fine, we have a simple solution for two out of three platforms. But this won't fix the problem on Unix which uses s as line break characters ... and if we add a Unix solution to the StandardConversions.db it will break windows by create "double line spacing" when converting to

. The obvious solution might *appear* to be to use convertwords instead of convertchars -- with a new database that only converts the required line breaks and VT's. But the problem with convertwords is that it cannot handle (it does not properly recognize) %0D as or %0A as ... so it is basically impossible to use convertwords instead of convertchars. In other words, there is no universal solution that entails the use of either convertchars or convertwords, so now we are left with grep, either as a nested context with grep or another context, or possibly alone. I doubt a single grep search string can be constructed to to the required conversions. And there's no documentation provided for WebDNA's version of grep anyways. But even if there were a single search value that would work in grep, we would still have to custom code it every time we want to use it -- and this is nowhere near as simple or straightforward as using a simple context like convertchars. The bottom line is that it would benefit us very much if we had a NEW CONTEXT that would convert data and display it properly on the page -- whether it comes from a database or a formvariable -- and whether the line breaks are Max, Unix or Windows. But this requires SMSI to do it. -- Sincerely, Kenneth Grome www.kengrome.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://webdna.smithmicro.com/ 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:

Why do extra quotation marks sometimes appear in my databases? (1998) Authenticate (1997) Can't use old cart file (was One more try) (1997) [ShowNext] (1997) RE: Database field limit? (1998) Multiple Ad databases? (1997) New Feature (now!) (2002) WebCatalog/Mac 2.1b2 New Features (1997) Re:Emailer Set Up (1997) problems with 2 tags shakur (1997) Frames (1997) Archives... (1997) Cart questions (1997) WebCat2b15MacPlugin - showing [math] (1997) Trouble with formula.db (1997) RE: [WebDNA] Installing 6.0 onto Server 2008 (2011) Re[3]: 2nd WebCatalog2 Feature Request (1996) append=T problem (1998) [OT] DNS Problems (2004) Close-to Comparison Code (1998)