[Date Prev][Date Next] [Chronological] [Thread] [Top]

booleanPretty (Was: Boolean Syntax not implemented (ITS#612))

Redirected to -devel.

I was thinking that boolean syntax/matching rules might be a
good first use of the pretty interface.  This interface is designed
allow for mangling of input before storage.

As it is now, TRUE is TRUE and FALSE is FALSE.  All
other values are invalid.

The booleanValidate could be modified to liberally allow
alternative values for TRUE ('true', 'T', '1', 'on', 'yes') and
FALSE ('false', 'F', '0', 'off', 'no') and booleanNormalize would
normalize these to TRUE or FALSE respectively.
booleanMatch would be left unchanged.

However, without a prettier, these alternative forms would be
stored and returned in searches.  A prettier can however
normalize the value before storage.

At 10:36 AM 6/30/00 +0000, Stephan Siano wrote:
>"Kurt D. Zeilenga" wrote:
>> I added an experiemental (ie: untested) booleanValidate and
>> booleanMatch routines without use of a normalizer...
>ok. the stuff seems to work (I tested adding an object with a boolean
>attribute. That will succeed if the value is TRUE or FALSE and will fail
>> A better approach would be to define booleanValidate as
>> numericStringValidate, add a normalizer which accepted
>> varients of true/false and normalized them to "TRUE"
>> and "FALSE", and add a prettier that stored the vaue
>> in normalized form.
>Hmm, I'm not sure whether I catch you right. 
>You say booleanValidate should be numericStringValidate (which is in
>fact IA5StringValidate). The inserted value should be converted to
>"TRUE" of "FALSE" by the normalizer and the prettier should user the
>normalizer to convert. If I try to store a boolean attribute to the
>database, the validator will let it pass (whatever I enter there). The
>prettier is applied to the value before writing the database and
>converts the data to TRUE or FALSE. So if a do a ldap_add or ldap_modify
>with "myBooleanAttribute:hugo" TRUE (or FALSE?) will be written to
>the database.
>Is this correct?
>Is this the desired behaviour? 
>Stephan Siano
>Stephan Siano                           Mail:  Stephan.Siano@suse.de
>SuSE Linux Solutions AG                 Phone: 06196 50951 31
>Mergenthalerallee 45-47                 Fax:   06196 409607
>D-65760 Eschborn