Hello Drew,
> Why this email? Because IMO it seems that along the way, while dealing
> (or not) with individual issues, things relating to how the GUI deals
> with required fields got a bit messed up.
Thanks for catching this and starting the discussion!
> Alright - well, here is a statement that I can not actually back up with
> empirical evidence - "When a user declares a text field as NOT NULL they
> almost always mean that an empty string ( or a string of all white space
> characters ) is also invalid input". Now before you say I'm wrong on
> that ask yourself when the last time you did such a thing?
I'd agree that this statement simply isn't true in this form.
> Using DEV300 m27 it appears that setting a CHAR or VARCHAR field as
> REQUIRED is in all but one use case meaningless in the context of the
> the Base GUI. The one case being on insert of a new record, and here
> even it is now open for silly data input errors that could have been
> avoided.
>
> It seems to me worthwhile, at the moment, to look at the whole issue of
> dealing with required fields for a moment and not just myopically
> looking at each of the separate issues.
Well, the overall picture takes into account one more item, which you
mentioned implicitly only: The "Empty is NULL" property of a control.
For all kind of controls with text-like input, it is as follows:
1a. If you set "Empty is NULL" to true, then an empty string will be
updated as NULL.
1b. If the field cannot be set to NULL, because it is defined as NOT
NULL, or if "Empty is NULL" is false, an attempt is made to update
the empty string
2a. If "forms check for required fields" is OFF, then the value as
computed in 1. will be sent to the database back-end, this way
delegating the acceptance/refusal of the value to it
2b. If "forms check for required fields" is ON, then columns containing
a NULL and defined as NOT NULL will be reported to the user, and the
row is not committed.
What issue 87514 fixed is that "formatted fields", which are used in the
table data view, did not respect the NOT NULL property, *only* the
"Empty is NULL" setting. This was different from other text-input
controls, which did respect both.
Worth mentioning here is that for the table data view, only formatted
fields are used (except for multi-line texts and controls only displying
the <object> placeholder), and "Empty is NULL" is always set to TRUE,
without the user having a chance to change this.
Also worth mentioning is that the table data view does not have an
equivalent for the "Form Check Required Fields" setting, it is
implicitly assumed to be OFF (simply because the table data view never
had the mechanism described in 2b, so there was no need/use for this
setting.)
So, I think you can tweak your *form* to behave like you want, but the
table data view might not meet all expectations, because both the "Empty
is NULL" and the "Forms check for required fields" setting are out of
your control. Which might justify additional RFEs.
As one more note, there's yet another RFE missing: The current
implementation of the forms runtime also checks the *logical* form for
the presence of a FormsCheckRequiredFields property (which a script
could easily add using the addProperty method), which can override the
database-wide property. It might be reasonable to add an item for this
in the property browser ...
Thanks & Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
