AltME groups: search

I told you that the cleaner option would be: write a input data validation 
routine to, at least, catch those undefined words.

Oh, I see, you were going to implement VALUE? for validation. I just 
didn't think you meant checking the entire input; I thought you were 
talking about the result

I have put my example script for CGI forms with validation and refilling 
previously filled fields online on the rebol.org site. http://www.rebol.org/view-script.r?script=cgi-form-val-example.r
Maybe somebody with more (CGI security) expertise can look at it 
and comment on safety issues please.

validation-proposal, dialog-system, gob-capture, save-state etc

MS has tried to improve things, and I think they have, with better 
test and validation tools for drivers. Helping people that way is 
key.

The code I posted doesn't do any validation according to what might 
work in the real world when dialed.

The chess program I want to make give the moves of a piece like on 
the shredder site http://www.shredderchess.com/daily-chess-puzzle.html
and it will have a minimal validation routine so my kids (and me 
too) can beat the machine.

The second thing is the validation I have in mind is in fact a client 
side Javascript/jQuery script before sending the form.

Client-side validation is a nice courtesy touch for the user -- they 
get told of errors without a network delay. But the server-side code 
needs to also do full validation as there is no way of guaranteeing 
the data has been POSTed from your form....Or perhaps the user had 
Javascript turned off.

On the form validation issue. I managed to get things working as 
I initially intented. Using a Javascript function to change the text 
of the field: 
var changer = document.getElementById('fieldid');
changer.value = fieldvalue;
Where fieldvalue was filled from the cgi data block cgi/fieldname

It was really fun to get this right with all the needed double-quotes 
and curly braces that alle represent comments in rebol as you know 
and generate this from within the well-known function emit: func 
[code] [ repend html code]
I had to add an id tag to all the form fields.

Scot, it is ironic because just today I was observing an elementary 
school lab and assessment and true validation was the subject.

No form validation ?

It is one I want to tackle though. form validation is a big problem 
too.

I did some validation on forms which I posted.

but this was validation by type only.

I think, that email validation is so often required that every bot 
must know how to fill field named EMAIL

Dates have natural ranges depending on their domain.

An expected due date of an unborn baby is (in theory) no more than 
9 months away.

The expected due date assigned to my mother before I was born is, 
now, a long time ago.


I don't'see how you can get around applying all due diligence to 
*any* input field. That may include asking for 4-digit dates on some 
occassions or disambiguating 24/oct/05 to ensure you know which part 
is the year.


Validation is one of the hardest parts of any real-world application, 
and one of the parts that most languages -- REBOL included -- offer 
only token support for.
Ideally, we'd have a range of to-xxx? words, like:
to-date? "29-feb-03"
== [false  "no such date"]
to-date?/strict "29-feb-04"    
== [false "ambiguous year/day]
to-date?/window "29-feb-04" [1975 2074]
== [true 29-feb-2004]

Ladislav: I see your point about immutability.


I guess that point about zone boils down to one of  datatype. I had 
been thinking along the lines that zone was a special datatype but, 
after checking, I see if it is of type time!.


What has confused me is the additional validation on time/zone in 
to-date:

>> to-date 9-mar-2006/14:17:38+8:01
** Syntax Error: Invalid date -- 9-mar-2006/14:17:38+8:01
** Near: (line 1) to-date 9-mar-2006/14:17:38+8:01

I guess, you'll need a validation routine to be called after each 
entering of a number by the user, and chech with something like
if error? try [...]

yeah.. and some validation too.

When we added validation for the license field, we limited it to 
licenses that had actually been used by people contributing scripts:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/license-help.r


I reckon there are way too many license variants already in the world 
-- it's the bane of the open source movement. (We had a list of over 
40 licenses that people in theory said they'd like to use when contributing 
scripts)

But,. as the note on the page says:

f you'd like to use a license for a contributed script, and you can't 
see it listed above, please send us Feedback.

It's short, but still leaves room for confusion.

How about being more descriptive ? Eg. "validation-filtered-load" 
?

Anybody of some generic form validation scripts/hints.  I like how 
.Net allows you to validate a group of radio buttons with one command 
rather than having to code a check for each radio button in the group.

If the user can just SHIFT-TAB after making changes to the field 
then the validation in the action block is skipped and the field 
is left showing invalid data.

this is a difficult issue. personally, i prefer tab and shift-tab 
to not do any validation, while enter does. it's not always a good 
idea to not let users go away from a field just because it is invalid.

ok. I follow your extraction of rules idea & this is what you had 
in your original suggestion.  Now I am getting more familiar with 
what I am looking at I can understand the benefit of that & will 
start to work that way now.

[copy .. [" ip address" to end]]  was to get the interface address 
in the interface section of the file. It is identified by
1) some line after the line containing "interface"

2) at the begining of the line always starting with one space before 
the word "ip address"

3) before any line with a non-blank first char unless it is a new 
instance of "interface" (hence my IntFlag which Steeve didn't like 
my method of use)


I found from testing that [to "ip address" copy temp to end] or [to 
" ip address" copy temp to end] found the string anywhere in the 
line, but [copy .. [" ip address" to end]] only finds the string 
if it is at the start of the line which is what I was trying to achieve. 
Have I made a mistake here & need to retest my assumptions perhaps?


I always appreciate lots of different views on issues so I am loving 
the multiple responses. 

Sunanda you have reminded me about line numbers. I will tackle them 
after the extraction of rules I think, as I want them in my output 
for data output quality & validation checking.


I have been looking at your parse-ini.r to see how you have read 
a file into a Rebol block, but I may stick with read/line for a bit 
longer while get my head round parsing each line in turn.  I get 
the impression that once I have a final block of code there will 
be someone who can turn it into 2 short lines including a built in 
Easter egg game.

Hi,so i am quite new to the rebol community and have been assigned 
a project to work on.So to be frank i started reading rebol 2 days 
ago and i am quite confused since i worked with c++ before that.I 
am stuck at flow control and operators(sad i know).So basicaly i 
thought of when i moved from delphi to c++,basically if one of you 
guys can provide me with a rebol version of this small program i 
whipped up(flow control number check-the basics) it would be of great 
help to me,so here is my program and thanks in advance.
    

It inputs an integer number n and outputs the sum: 1+22+32+...+n2.I 
use input validation for n to be positive.
#include <iostream>
using namespace std;
    
int main()
{
     int n;
     cin >> n;
     if (n < 0) return 1;
     int sum = 0;
     int i = 0;
     while (i <= n) sum += i*i;
     cout << sum;
     return 0;
}

I do screen validation by datatypes ( for data input ).  If the user 
enters an invalid datatype ... ..

I am using an adapted form of it commercially so far.  I have implemented 
full schema validation and loading (in rebol) but its proprietary 
code I can't release.  So guys, it can be done !

I'm starting to see some abandonment of XML in favour of JSON .. 
mainly in web 2.0 .  but it will not replace xml where validation 
 is required.

If you are doing type specifications to validate records, the fastest 
way to do it is to generate static validation rules based on the 
specification, then just apply the generated per row. Static validation 
rules would be faster than dynamic.

rollback would be neet as a parse keyword  :-)  it would allow us 
to break several levels at once... something I would have needed 
when I did my XML schema validation engine.

Not sure there is a good solution other than to require optional 
parameters to have keywords to identify them.

Then you need to take only one pass at the input, and use defaults 
(or ignore) parameters that are not present.  At the end of the pass, 
you can then see if the collection you have makes sense (maybe some 
optional parameters are needed if others are also present).

Basically, its raw data validation....Boring, but necessary.

yes, I saw this in Chris's  validation lib " Defining a good dialect 
(simple, short, efficient) isn't an easy task. Chris did some work 
about such form validation dialect in QM. See http://www.rebol.org/documentation.r?script=filtered-import.r
" (on this url)

Though not included in the rebol.org submission (it's in QM), I actually 
have two data matching dialects that use the same validation vocabulary 
(in both cases, set-words are the anchor to each rule).


 import [this "1"] [this: integer! is 1] ; import extracts name/value 
 pairs

 match [1][this: integer! | decimal! is 1] ; match evaluates a free-form 
 dialect


Both have different basic expressions, yet use exactly the same validation 
code.

For example ["1" "20" "46"] might represent options where input requested 
integers between 1 and 50.  Successful validation would return [1 
20 46] whereas ["1" "foo"] would fail as foo is not an integer.

had anyone done an email address validation according to rfc 2822? 
Well, I mean email adress part? Our to-email "whatever-stupidity-you-write-here423423423-rebol-considers-being-an-meail@{{}}}]//" 
is kind of funny :-)

OK, Carl asked me to announce this, so this will be quick and dirty:

The VID Extension Kit for R2:


This is a library that overhauls VID and the styles to improve the 
experience in using it and creating bigger programs with it. This 
is very much a work in progress, but if I continue to keep it under 
wraps, I'll never get it out. :-)

Quick feature list:

- Full tab navigation
- Field validation and autoformatting
- Full resizing
- Many new flags

- Much better face control: disabling/enabling faces, different setting 
and getting of panels, complex face navigation

- Many new styles: Selectors, balancers, lists, fields, panels, scrollers, 
iterators

- Many VID bugs are fixed, although the impossible ones still remain

- Many new VID bugs are introduced as well :-) Some styles are not 
working.

Try it out at:

http://www.hmkdesign.dk/rebol/vid/src/vid-ext-kit.r

A simple style browser is available at:

http://www.hmkdesign.dk/rebol/vid/tools/style-browser.r

Very preliminary docs at:

http://www.hmkdesign.dk/rebol/vid/docs/vid-extension-kit.html


I'll release the full sources later, but have a look and see what 
you think. Remember to ask questions.

Wondering if there are any plans to include group element validation, 
ie, mutlple radio-buttons or checkboxes validated based on group-name 
rather than each item checked individually?

Since you are also responsible for RebForms maybe this can be a feature 
request.  In .Net, you can have a form Validation Control, that confirms 
all of the validation checks on the fields of the form.  You are 
also allowed to indicate for each form element, whether it is to 
be included in the form-level validation or not (ie, free form text 
fields typically don't need validation).

Brock: validation is also on my ToDo list (you can see the beginnings 
of it in the field widget character length limits). A couple of questions 
though (both how it is done in .Net and how it *should* be done in 
RebGUI):

	What's the granularity of the validation?

 Does it allow the specification of a mask (e.g. for phone numbers)?

 Is it validated as I type, when I leave the field, or when I save 
 the form? (Or is it flexible enough to let me choose the level of 
 validation?)


shadwolf: Haven't really thought about it much, but I figured the 
tab-panel redraw feel was a logical place to do the work.

Didier did some work on field validation with VID

http://membres.lycos.fr/didec/rebsite/styles/filter-field/test-filter-field.r

Alpha2 build available at: http://www.dobeash.com/files/RebGUI-020.zip

Highlights include:


 - New, unit based sizing model (see http://www.dobeash.com/it/rebgui/display.html)

 - Improved language localization (see http://www.dobeash.com/it/rebgui/locale.html)

 - New arrow, chevron, check-group, led-group, scroller, spinner and 
 drop-list widgets
	- Lots of minor fixes
	- show redefine removed
	- Use of -1 instead of 9999 to denote auto-size
	- Aesthetic improvements (use of gradients)
	- %tour.r substantially rewritten

Known issues

	- spinner and drop-list widgets need more work
	- scroller needs more work (resizeable dragger)

In progress

	- Improved tab-panel (shadwolf)
	- Menu (cyphre / shadwolf)
	- tabbing
	- field input validation (field input masks, etc)

That leaves less than half a dozen widgets to go!

	list		single column
	listview	multi-column
	treeview
	popup-menu	context menu
	status		status bar with one or more “segments”

Latest build available at: http://www.dobeash.com/files/RebGUI-022.zip

Highlights include:

	- Added drop-list, edit-list and auto-fill widgets
	- New splash function added (run %tour.r to see it in action)

 - Window management logic improved (disallows duplicate windows and 
 "sticks" child windows to first)
	- Couple of minor fixes and cosmetic improvements
	- %tour.r has an additional "List" tab

 - Prototype table widget added (run %table-002.r to see it in action)

Known issues

	- spinner and auto-fill widgets need more work
	- edit-feel needs to handle highlight, cut & paste
	- scroller needs more work (resizeable dragger)
	- table needs row selection logic added
	- edit-list needs auto-fill logic added

In progress

	- Improved tab-panel
	- Menu
	- tabbing
	- field input validation (field input masks, etc)
	- list-view (shadwolf)


With regards to "lists", I envision 5 types we need. They are (in 
ascending order of complexity):


 drop-list	- non-editable, single sorted column with single value 
 selection [optimized for < 100 values]

 edit-list	- derived from drop-list but editable with an auto-fill 
 field

 table		- multi-column representation of a DB table; used to create 
 something like a GUI SQL client with single-row selection [< 100,000 
 rows]

 list-view	- multi-column multi-media content (supports images, URL's, 
 etc); used to create something like a file explorer with single perhaps 
 multi-row selection [<10,000 rows]

 grid		- cell-level addressing and editing supporting simple spreadsheet 
 formulas and formatting [< 1,000 rows]

... simplest widget ever ...
 How much is there to write about?

	widgets: make widgets [my-widget: make face []]

Or am I missing something? ;)


Your VID edit styles sound interesting, but I'm looking for a more 
universal solution to "field input masks" and "field input validation". 
Something that would let me define a telephone number mask for example.

Ashley, I felt the need for this kind of validation / masking as 
well. Just never got around to it.  It's not simple.

Latest build available at: http://www.dobeash.com/files/RebGUI-024.zip

Highlights include:


 - New edit object / feel added in a separate file, %rebgui-edit.r

 - Documentation on above at: http://www.dobeash.com/it/rebgui/edit.html
	- Face redefinition localised to widgets object
	- Radio-group color toned down from green to leaf

Known issues:

	- auto-fill broken for the time being

 - edit feel needs to support tab / shift+tab into and out of "grouping" 
 widgets

 - cursor down goes to end of text instead of next line?! (yell if 
 you know the answer as I'm stumped on this one)

On the drawing board

	- area widget needs a scroller added to it by default
	- field format / validation masks
	- inline spell-checker

Latest build available at: http://www.dobeash.com/files/RebGUI-030.zip


*** Note that this version requires View 1.2.124 or later, and that 
the zip file is unusually large (346Kb) as it includes a dictionary 
file (future builds wont). ***

Highlights include:

	- New language, dictionary and spellcheck functionality added

 - Documentation on above at: http://www.dobeash.com/it/rebgui/edit.html#section-4
	- All objects merged into one context
	- Major code reorganization / restructure
	- Reduced number of global words to 11
	- Pre-0.3.0 comments removed
	- Pre View 1.2.124 code removed
	- New text-list widget added
	- Added show-color accessor function

 - rebface and rebfocus synonyms to avoid collision with face / focus
	- Large number of bug fixes
	- http://www.dobeash.com/it/rebgui/roadmap.htmlupdated

Known issues:


 - edit feel needs to support tab / shift+tab into and out of "grouping" 
 widgets

 - cursor down goes to end of text instead of next line?! (yell if 
 you know the answer as I'm stumped on this one)
	- focus

 - edit-list / drop-list should use show-popup/away (some compatibility 
 problems)

On the drawing board

	- area widget needs a scroller added to it by default
	- field format / validation masks
	- menu widget
	- better keyboard navigation / focus

Yep, that works.  Thanks.  I am trying to provide field level data 
validation so do need actions to fire on tab as well as on enter.

Otherwise field level validation becomes trickier to do.

Ashley, what do you think of adding in some way of assisting with 
field level validation.  I was thinking of perhaps an optional dialected 
block that specifies if the field is of date type, not null, character 
length min/max, and for passwords, sufficiently complex.  That way 
when building database applications, you can specify the table constraints 
at the field, and let rebgui automatically enforce that.

My tentative design concept for field level validation at the moment 
is to allow a block of REBOL data types to be specified, such as:

	field options [integer! decimal! none!]


with invalid input changing the field color and not allowing focus 
to leave. Successful validation would restore field color and place 
the loaded face/text contents in face/data. Haven't thought about 
min / max lengths, although an empty field would be treated as none! 
so null / not null is handled by default.


The password suggestion is a good idea, perhaps a min/max length 
option and a 'dict option that ensures the password contains no spaces 
and does not appear in the currently loaded dictionary?

Latest build available at: http://www.dobeash.com/files/RebGUI-037.zip

Issue log: http://www.dobeash.com/it/rebgui/issues.html


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 ***

Highlights include:

	- Close handler refinement added to display function

 - Closing the main window when more than one is open now prompts 
 for confirmation

 - New 'after keyword added to layout (helps with displays that arrange 
 widgets in one or more columns)

 - Fixed major bugs with 'at positioning and window size determination
	- Couple of layout 'reverse bugs fixed
	- Documentation updated to reflect above changes
	- Number of minor bug fixes

In the works

	- revamped focus system
	- basic menu widget
	- context menu widget
	- field-level validation
	- stabilize existing code-base for 0.4.0 beta release

I owe you my opinion on field level validation probably, so here 
we go ...

As I already said, it is imo insufficient or even let's say incorrect 
to base field validation upon rebol datatypes. As we can't have our 
own datatypes, those available are just some kind of primitives, 
not of much of a use ...

In CA-Visual Objects, the logic was even more abstracted - you e.g. 
defined DB field tel-num, char(20). That field, you could use across 
your tables, and from the application pov, you defined mask objects 
- you could e.g. have different mask objects, defining behaviour, 
validation, mask, tight to the same tel-num, char(20) field ...

One of the most difficult fields was date entry field 99.99.9999, 
with VO we had three or more implementations. Native one pretty sucked 
- it is all about what chars you allow, what happens if you press 
tab, del, how is field hilighted by default, what part is hilighted, 
if your backspace key deleting letters stops at dot or not etc ec. 
With date field - do you want to allow user to enter any number? 
67 or other number is surely not a good day-number, is it? :-) Now 
do you want to disallow user to type nonsense directly? How do you 
know without linking it to calendar? Or do you do your validation 
when leaving your field? Some ppl do validation once per form, e.g. 
when you try to press "Save" button (not my preferred way, at least 
for some field-types, but some do prefer that) ...

Graham - aren't character of integer field another level of complication? 
Let's have one type of field, with kind of clever masking/validation 
- then, using the SAME rules, let's define your character or integer 
field, please ;-)

*Some* validation can only happen after the event -- unless you enforce 
the order in which fields are completed. And even then it's not always 
possible.

May you need some lightweight masks for simple things. Plus the ability 
to skip off to a tailored validation function for the more awkward 
stuff.

I am currently doing field validation by datatypes, but it does have 
it's limitations as Pekr says.

Good questions.....A zio code format depends on the country....even 
if you switch masks vy country name, the country name may be entered 
after the zip code.

You'll only handle that correctly with post-form completion validation.

imo some simplified parse dialect could work (we have Gab's parse 
rules, so we could be able to define parsing rules dynamically, or 
we implement it other way, dunno), the tricky part could be, if you 
would like to do validation upon each event (key-press), or only 
when your field is losing focus ...

focus would look for a face/focus function while unfocus would look 
for a face/unfocus function. So the code might look like:

	...
	field unfocus-action [do-validation face/text]


the validation, if it failed, might shift focus back into the field 
the user tried to leave. Something like that I guess.

Latest build available at: http://www.dobeash.com/files/RebGUI-038.zip

Issue log: http://www.dobeash.com/it/rebgui/issues.html


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 (1.3.2 preferred) ***


This is mainly a bug-fix release with a new prototype event trigger 
system (see %"Demo - actions.r") and a very early proof of concept 
bubble-menu (see %"Demo - bubble-menu.r").


I'm particularly keen to see whether the event trigger system is 
flexible enough to remove [or reduce] the need for a dedicated (and 
hard to design / implement) one-size-fits-all "field validation" 
system as discussed previously. The bubble-menu demo shows how transparency 
and event detection within a non-square area *could* be done. The 
implementation is not perfect (or anywhere near usable) so I'm open 
to alternate design suggestions! ;)

and demo for field validation does not work at all ...

The idea with the on-* naming is to clearly indicate an event. I 
toyed with using just focus / unfocus but these verbs could be confused 
with the functions of the same name. Likewise, 'enter could be confused 
with the 'return keyword and 'exit has the same issue with regards 
to both 'exit and 'quit. 'on-enter and 'on-exit are possibilities 
though.


on-focus and on-unfocus return true or false so as you can handle 
failure. This scenario is more likely with on-unfocus where you would 
want to trap and handle a field validation failure for example.


The difference between on-unfocus and the usual action (both may 
be triggered by pressing enter for instance) is that on-unfocus enables 
you to interrupt the normal work-flow by aborting the unfocus and 
subsequent focus operation - something you could not [easily] do 
normally. Also, for many widgets the usual action and on-* actions 
may be different (e.g. pressing enter to initiate the default action 
may be quite different to pressing tab and leaving the field).


For those familiar with Oracle*Forms, and similar products, these 
new actions are like the pre-field and post-field triggers (with 
the app-level ones mapping to pre-form and post-form).

Good questions all, keep them coming.

I'm not sure that this is relevant, but I did some basic screen validation 
for vid, and documented here


http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse/Screen_Validation

ie.form validation and not field validation

a later version, using schema validation, understands multiple subelements 
and automatically converts them to blocks IIRC.

so you do document/element/3/subelement/#attribute.

my newer version doesn't have the schema validation process.... that 
is a very complex engine to build.   schemas and Parse traversal 
do not follow the same algorythm... so its a bitch to implement.

Hi,so i am quite new to the rebol community and have been assigned 
a project to work on.So to be frank i started reading rebol 2 days 
ago and i am quite confused since i worked with c++ before that.I 
am stuck at flow control and operators(sad i know).So basicaly i 
thought of when i moved from delphi to c++,basically if one of you 
guys can provide me with a rebol version of this small program i 
whipped up(flow control number check-the basics) it would be of great 
help to me,so here is my program and thanks in advance.
    

It inputs an integer number n and outputs the sum: 1+22+32+...+n2.I 
use input validation for n to be positive.
#include <iostream>
using namespace std;
    
int main()
{
     int n;
     cin >> n;
     if (n < 0) return 1;
     int sum = 0;
     int i = 0;
     while (i <= n) sum += i*i;
     cout << sum;
     return 0;
}

To be a little more constructive (hopefully): This whole debate started 
because I had an idea to try making my backend programming system 
even more elegant. So I did this as an experiment and so far I haven't 
meet any problems (it automatically creates prepared statements so 
it's safe without you having to make ?'s and matching values). "dbfunc" 
accepts some validation dialect I have instead of arguments, as you 
can see content of functions is normal SQL issues are turned into 
prepared statement values... 


This is example of the code: http://paste.factorcode.org/paste?id=2321

No, it's validation of Firebird's approach.

For BETTER, REBOL needs to add all the extra features - for example, 
Flex offers classes for validation of form data that are very robust.

he has had a prototype unit (about 10kW if I recall) heating a building 
for about a year prior to the public announcement. The plant(s) (there 
will be one in Greece and one somewhere else, I think) coming this 
year, hopefully, will be the validation of the process everyone is 
demanding. If you read at the above links, you'll see that his intent 
isn't to stop the technology from being used by as many people as 
possible.

thanks.  is the MOD system flexible enough to allow the server to 
be something else than a "WEB" server...  more precisely, a web service, 
I already have all the XML and schema validation libs to make it... 
its just that my current server is blocking and when I relay commands 
to othe servers, it causes timeouts on new commands.

Doc, I am making that form -> validation -> v. notices display in 
form ...  I will post code if it works out well

Any feedback on this filter-validate-process dialect is velcome.. 
(it is meant for processing posted form data)

first word in row is request field name ;;; req | opt  is  required 
| optional + default value  ;;; than you can have a chain of aditional 
validators like int , string , email, url , one-word ;;; then you 
can have check which executes your custom code and if it returns 
a string it uses it as validation notice ( to check something app 
specific or in DB for example ) ;;; then you can process the value 
with do and again custom code the returned value of that block of 
code is set to that field ..

filter-validate-process-example: 
[
	id req and int .
	username req .

 email req and email check ( either email-exists email [ "email taken"] 
 [ none ] ) .
	website opt "" do ( to-visible-url website ) .
	adress opt "not given" .
]

Defining a good dialect (simple, short, efficient) isn't an easy 
task. Chris did some work about such form validation dialect in QM. 
See http://www.rebol.org/documentation.r?script=filtered-import.r

maybe even just provide a little PARSE rule which provides input 
validation representing the given schema.

angularjs is surprisingly backward compatible, btw... but serverside 
validation is still a must of course.

in this particular project we tried view, btw, but we need it on 
a tablet later in a warehouse, so /view is not an option at the end 
:(

This was my old code because ot it (I check for </html> and </form> 
to see if I signed out) . Now I am making it status for validation 
for example it will be status 403, etc ..


    onChange2: function(rq, pars) {
        this.assureLANG();
        if (rq.readyState == 4) {
            if (rq.responseText) {
                if ( rq.responseText.indexOf('</html>') > 0 ) {

                    if ( rq.responseText.indexOf('</form>') > 0 ) {
                        alert(LANG.err.session_exp);

                        window.location = window.location.href.replace(/#.*/g, "")+"";
                    } else {
                        alert(LANG.err.ajax_err);
                    }
                } else {
                    c(r.responseText);
                }
            } else { this.onError(); }
        }
    },

I quickly mocked up how ajax code would look if you made it return 
401

    onChange2: function(rq, pars) {
        this.assureLANG();
        if (rq.readyState == 4) {
            if (rq.status == 401) {
                alert(LANG.err.session_exp);

                window.location = window.location.href.replace(/#.*/g, "")+"";
            } else if (rq.status = 200) {
                success(r.responseText);
            } else if (rq.status == 403) {
                validation(r.responseText);
            } else {
                this.onError();
            }
        }
    },

Changelog : 0.9.6 - 21/01/2009

	o FEAT: Ticket submitter can now delete his ticket.
	o FEAT: Admin can now delete any ticket.
	o FEAT: Admin can now delete a user.
	o FEAT: Admin can now change user's role.
	o FEAT: Admin can now force validation of a new user's account.
	
	o FIX:	Tickets list loading twice on first visit issue fixed.
	

 o LOOK: Input fields and buttons border width reduced to 1 pixel.

Another usage for the HIDDEN state.

To add a validation process not associated with something to show.

For example, a component to check the rights of the user at the validation 
of a pannel.

I think an hidden item should not be disabled by default (allowing 
"ghost" validation).
I you want both, then add the both flags HIDDEN + DISABLED

VALIDATION

if they're hidden you can't correct them if they fail validation

just show them if validation fail

The way that accessors on panels work in R2 is a good start (almost):

	>> lay: layout [pan: panel [foo: field "Foo" bar: field "Bar"]]
	>> set-face pan ["Bar" "Foo"]
	>> get-face foo
	== "Bar"
	>> get-face pan
	== [foo: "Foobar" bar: "Barfoo"]

Tie that to validation, eg:

	import get-face pan [foo: string! [some char] bar: opt string!]

Or an active record:

	record/update get-face pan

Henrik: Do you also tie validation and multiple data sources to each 
binding?  I kind of like the independence of a data model co-existing 
with a layout structure, you can poke and prod data from outside 
while the view internals just get on with what they do...

Chris, the storage would require a "save to table" action. It wouldn't 
save as soon as you tab out of the field, so validation is fully 
possible.

this really is about as minimal as it can get with the layout dialect. 
validation would be another reactor.

Does this system caches data somewhere before updating the record(s) 
or data is immediately written on the record field ?

When an user edit a file it must be checked for proper input

When multiple fields are edited they may have a relationship on consistency 
and there is a mutual validation

When you save the recordset  there could be errors on writing and 
the whole transaction need to be discarded instead of being partly 
written.

validation is not a part of the UI yet, but it will be.

the idea is simply not to submit the data until the form is validated. 
I've not decided yet, but validation could be a reactor, the way 
things are shaping up right now.

P: Validation ('import) and Active Record (RoughCut) are essential 
components of QM.  Validation (along the lines of 'import) could 
easily be part of a panel/layout's specification...

http://rebol.hmkdesign.dk/files/r3/gui/228.png


This odd looking dialog marks a few milestones from two days of work:


- Successfully create and open an email dialog created from a single 
style, which represents the content area.

- Successfully validate the content area from the validation information 
stored in the style.

- Successfully display validation result in the content area (the 
letters to the right of the fields show INVALID)

- Successfully block closing it, when it's not correctly filled, 
when clicking "Send" using a new DISMISS reactor.

- Successfully store the content in a way so that it can be returned 
in an object, when the dialog is finished or store a NONE/FALSE when 
cancelled.


The dialog is called by: REQUEST-EMAIL. It doesn't send any email, 
that comes later. The reason it looks odd is because the new resizing 
scheme requires some changes in how sizes are handled in styles and 
I haven't quite figured out how to change them yet.


We'll probably need some more prototypes, but all in all, this is 
a fairly good method of creating complete-featured dialogs quickly.

They are quite a complex data structure, or can be.


Perhaps a first step would be for someone to write a parse rule to 
identify/vaidate IPv6 strings and, optionally, translate them to 
a normative form.


Link to someone who has made  a stab at a BNF defintion for  IPv6, 
and then produced a regex:

   http://crisp.tweakblogs.net/blog/2031/ipv6-validation-%28and-caveats%29.html

To clarify the SSL stuff:

Since the SSL is a layer on top of TCP the idea was that R3 will 
have all the neccesary encryption algorithms (RSA,DH, DSA, RC4, SH256 
etc.) probably in form of embedded extension as part of the host-kit. 
These algorithms needs to be fast so they will be in C (probably 
ported from the R2 codebase if possible). Then the SSL/TLS protocol 
itself won't be written in C as it was in R2 but just done in R3 
script. This way the protocol code will be:
-smaller in size than the C version

-easier to maintain because it is Rebol language, for example we 
can add 'server mode', certificate validation (simmilar to web browsers) 
etc.
-crossplatform as much as Rebol script can be


So far I did simple TLS implementation in R2 to prove that concept. 
The prototype is ~20KB of rebol script and uses only the build in 
encryption ports in R2. It covers most of the TLS functionality that 
is written natively in in form of 'tls scheme. So the next step is 
to get the encryption math to R3 (which can be useful not only for 
SSL so it is definitely worth doing that) and then try how the prototype 
will behave.