At 2001-03-23 10:32 +1100, Helen Borrie <helebor@...> wrote:

>At 03:56 PM 22-03-01 -0700, you wrote:
>
> >It isn't uncommon for the majority rule to take precedence over mathematical
> >correctness. In the case of IBO, if you are the unusual case that needs
> >whitespace left alone it is a simple setting to do so. That was the decision
> >I made back when I made it this way.
>
>IMO, this is the key point. Theoretically "all characters matter" but in
>practice, trailing whitespace is redundant and usually accidental. In the
>99% case, it gets there because a user leaned on the spacebar during an
>edit. IBO already lets you handle the 1% case. For the integrity of the
>data, that should be restricted to columns which user input cannot
>influence. Any application which allows users to input "significant"
>trailing whitespace is defective, considering that there is no feedback to
>the UI as to the size of such whitespace. However, that is a developer
>choice: if a developer wants to include such risk in his UI, IBO already
>has the means to allow it. Just don't change the status quo to cater for
>bad UI design.
>
>I have no argument to support left-trimming or instring-trimming: but
>that is NOT the issue here. I think David Trudgett's comments are not
>pertinent to right-trimming in the 99% case.

Only when talking about validating and filtering user input, I think. If
that's what most people do with IB_Query, that's fine. As I may have
mentioned in another message, what's important to me is that the default is
easily overridable (is there such a word??) (and that the default is
clearly documented).

>
>
>The default right-trimming behaviour is a workaround to enhance
>performance in the buffers but it also has other benefits. I shudder to
>think of the impact of changing the default behaviour (reports overloaded
>with unwanted whitespace, the need to alter parsers, the double or triple
>impact on apps written over databases with widestring charsets, etc.
>etc.) Let's KEEP the current behaviour wrt both char and varchar and
>DOCUMENT it clearly. It's not IBO's job to emulate the past errors of
>others, nor to supply default behaviour that breaks good designs to cater
>for bad UI design. It was the right design choice when it was originally
>made and it still is.

I think it's the right decision for user input components and output or
reporting components. I don't think it's a good idea on database access
components. If the database and/or database access components want to do
tricky things like compress spaces for efficiency purposes, that's great
(InterBase already does it).

>Jeanne d'Arc
>(alias Helen)
>
>:)

You know what happened to her, don't you :-)))


David Trudgett

>All for Open and Open for All
>InterBase Developer Initiative · http://www.interbase2000.org
>_______________________________________________________
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>