World: r3wp

Henrik - generally - do we have per-field validation, or per-form 
validation? I e.g. don't like systems, which lock me inside a field, 
untill I correct it. I hope it is the latter :-)

Both, afaict from the source.

The scope is whatever you want to validate, whether it be a field 
or a whole form.

And it won't lock you in the field, it just indicates it's not valid. 
So you can tab around like mad but the save button might not be enabled.

BTW, it's subtle, but if you make mistakes and validate, the validation 
will automatically focus the first field with an error in it.

So, it will both support Robert's method of a disabled save button 
and one that only validates at the end.

What I hate most about validations, is sometimes their strictness. 
I would break anyone's hands, who pushes me to write a phone number 
to some "standard". The phone number is used by humans anyway, and 
even then, it can be still parsed even by automat. My number is +420-777-172 
171 .... I choose my own format for the readability purposes, and 
I hate, when the form blocks me :-)

well, then you don't have to use it. validators are made from the 
user's perspective using the MAKE-VALIDATOR function to fit any format 
supported by the style to validate.

Must have selected value

 in item list 1, but doesn't mark a non-selection as invalid after 
 marking a selected item as valid and deselecting it by clicking in 
 the list-view somewhere below item "3".

This looks like great progress Henrik.

ChristianE, ok, bug in TEXT-LIST.

Gregg, thanks. There will be another iteration as new ideas have 
come up.

Henrik - question to your site being down on ML. I know that it is 
now available via IP address, but dunno if you want to get it published. 
Feel free to answer on ML.

hrm... I responded and it showed up on the list, saying that my mail 
address is blocked due to spam. Did it show up?

it did not show-up yet ...

Henrik - as for validation example - Numering required panel, 'f8, 
I have no value there, yet it shows positive validation ...

Parser issue. Will see if it can be fixed.

updated validation.r3. added also a field for the only-chars validator.

I'm thinking there is a design issue with validation, particularly 
the initial state:


The latest version will show that the "Only Chars" field validates 
as OK, which is technically correct, but confusing, as absolutely 
nothing has been entered in the field.


The issue is that the VALIDATE-PANEL/INIT function will see the field 
prefilled with an empty value and this passes validation. All fields 
that show a black dot, actually fail validation and a black dot is 
shown as the initial state.


I understand what this means, but it may be confusing for someone 
who is using the validation system for the first time. The fix is 
simply to add the NOT-EMPTY validator to the field, for the field 
to fail validation initially.

Is this easy to understand?


I've studied the issue with setting an initial state for each field, 
but then there would be a problem with the validation system understanding 
prefilled values, and I would have to add functions to the validation 
system to mimick SET-PANEL that setup fields in a special way. I 
don't want to bloat the GUI like that. This method works fine, as 
long as you know what's going on.

Are you replying to yourself?

As for me - this sounds so complicated, that normal person can't 
know what you are talking about at all.

I'm asking the question, but it seems to be difficult to understand 
the issue.

Pekr, if you try the validation.r3 file again, you will see one field 
showing up as OK.

I just don't understand, why is that being a design issue? Any design, 
which pretends empty field belongs to "only chars", is wrong. And 
if it is difficult to fix, then the validation mechanism design is 
wrong as well ...

how is that implemented? Are you using parsers? What is the problem 
to check for the empty string?

The issue is that the VALIDATE-PANEL/INIT function will see the field 
prefilled with an empty value and this passes validation
 - why is that so?

What is the link to validation docs/proposal?

Is validation a fundamental gui aspect that has to be dealt with 
now?

Not numbers
 field fails too with an empty field ...

Graham - that is my ethernal question with the GUI project :-)

As for me, I can imagine Henrik doing much more important work, especially, 
as we have just few basic styles, which are even not working properly 
yet. But - we can't see the big picture. Henrik's work can go in 
parallel, and I think that Robert is sane enough to know what he 
is doing/requesting and why. That means - we have to be missing something 
...

Graham, yes.

I hope soon enough we will be able to see fully working area, navigation 
by keyboard, tabbing system (including the ability to set the order, 
skip certain widgets, etc.), styles like tabs, tree (fully keyboard 
navigation support), table/grid (ditto). With those three styles, 
we can be kings ....

I just think that the work is running in multiple levels (native 
- Cyphre, styles - Rebolek, high-level - Henrik), and at some point 
in time, it will all settle down and merge together ...

Pekr, I see you don't understand the design of the only-chars validator: 
Each validator is single-purpose. This one checks only if only chars 
exist in the field. You can combine it with another validator to 
get stricter validation.

There is no problem with checking for an empty string, but the only-chars 
validator does not check for empty strings. The not-empty validator 
does that.

Of course I am tempted to see things we expect most - more complete 
styleset and at least basically usable gui, but I will test what 
comes-out, as I think talking about what will come next just makes 
guys nervous :-) Of course some basic time-frame  would be usefull 
...

but only-chars CAN'T be imo true for an empty string, no? :-)

Time frame is ASAP. The work is being done for apps (now not one, 
but two) that need to get into the field by RM Asset as soon as possible.

Pekr, what if you have a case, where you want both?

Henrik - can you please repost link to your validation related doc?

The doc is not yet updated for the latest validation prototype.

Perhaps the discussion should wait until that is completed.

Henrik - that would be OK, no? It is imo about perception of what 
are you expecting. If I ask - non-empty, that means something is 
entered, whatever. If I ask only-chars, it should validate only if 
chars are entered = include non-empty state by default ...

Simply:

not-empty - some value of any type has to be entered
only-chars - only chars allowed (len > 1)
only-numbers - only numerical values allowed (len > 1)

yes. what if you want to allow both empty and only-chars?

some-chars, any-chars?

possible, but adds more validators.

If I want to allow both empty and only-chars, then I have to explicitly 
express that. But only-chars itself has to fail on an empty field, 
no? Maybe I am just wrongly guessing something from the validation 
test example form field descritions ... I will wait for docs ...

Pekr, I understand what you say, but I would call it "going the long 
way around".