You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/02/04 18:50:21 UTC
[cforms] new validation: every widget can have a validator
Hi peeps,
I finally managed to finish the new style of validation we discussed a
while ago.
This new validation allows *any* widget to have a validator. The
immediate effect is that <wd:validator> is now outside of <wd:datatype>
since not all widgets have a datatype.
The validator interface has also changed, since not all widgets are
capable of displaying a validation error. A validator now has the
responsibility, if validation fails, to set a ValidationError on the
validated widget itself or one of its children. Widgets that accept a
validation error implement the ValidationErrorAware interface.
The existing validators have been wrapped with an adapter and are
therefore still supported, although deprecated.
I updated the form1 definition in the samples: moved the validation
outside the datatype, and added a validation on the repeater that checks
if contact names are disctinct among the different rows. This sample
uses a new JavaScriptValidator that allows validator to be written as a
JS snippet.
Enjoy,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [cforms] new validation: every widget can have a validator
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
<snip>
> I made no answer to your recent addition to Woody because of lack of
> time, but will do it very soon (it contains very interesting stuff).
Ok. No pressure.
> I do think, however, that the flowscript integration should just be an
> /integration/ and not an extension. By this, I mean there should be no
> Woody features only available in flowscript except those that are
> intimately flowscript related such as form redisplay using continuations.
>
> Sylvain
>
Of course it's open to debate, but it seems to me that if you are using
flowscript then that is also the best place to put the action,
on-change, and validation callbacks. If you're not using flowscript
then what are you using (actions?). You can write your own FormHandler
to handle action, on-change, and validation in your action. I don't
think we should duplicate that functionality in the form definition (in
terms of JS snippets and repeater-action) simply because it may be
inconvenient to do it in an action.
Chris
Re: [cforms] new validation: every widget can have a validator
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
> Sylvain Wallez wrote:
>
>> Joerg Heinicke wrote:
>>
>>>> My plan is to make some of the most useful Woody classes directly
>>>> visible in the JS snippets. This includes ValidationError, among
>>>> others.
>>>
>>>
> Seems like a hack, but anyway...
I thought it could make life easier. But if it feels hacky, we can also
live without it!
>>> Does this mean like import in Java, so that it is possible to access
>>> the class without package?
>>
>
> In the CVS version of Cocoon, flow scripts can use packages under
> "java" , "javax", "com", and "org" without the "Packages" prefix. In
> addition, the importClass() and importPackage() functions should be
> usable now (in previous versions these failed when a script was
> reloaded).
>
> You could add the same functionality to your implementation Javascript
> snippets in Woody form definitions.
>
> My personal opinion is, however, that these snippets should be
> eliminated (as well as repeater-action addrow and repeater-action
> delete-rows and the like) and instead that functionality should be
> provided by the Woody flowscript API.
I made no answer to your recent addition to Woody because of lack of
time, but will do it very soon (it contains very interesting stuff). I
do think, however, that the flowscript integration should just be an
/integration/ and not an extension. By this, I mean there should be no
Woody features only available in flowscript except those that are
intimately flowscript related such as form redisplay using continuations.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [cforms] new validation: every widget can have a validator
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Joerg Heinicke wrote:
>
>>>
>>>
>>> My plan is to make some of the most useful Woody classes directly
>>> visible in the JS snippets. This includes ValidationError, among
>>> others.
>>
>>
Seems like a hack, but anyway...
>>
>> Does this mean like import in Java, so that it is possible to access
>> the class without package?
>
>
In the CVS version of Cocoon, flow scripts can use packages under
"java" , "javax", "com", and "org" without the "Packages" prefix. In
addition, the importClass() and importPackage() functions should be
usable now (in previous versions these failed when a script was reloaded).
You could add the same functionality to your implementation Javascript
snippets in Woody form definitions.
My personal opinion is, however, that these snippets should be
eliminated (as well as repeater-action addrow and repeater-action
delete-rows and the like) and instead that functionality should be
provided by the Woody flowscript API.
Chris
Re: [cforms] new validation: every widget can have a validator
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> On 04.02.2004 23:12, Sylvain Wallez wrote:
>
>>> Which properties are available here? Obviously widget, but maybe
>>> also form?
>>
>>
>> The form is available on each and every widget through
>> "widget.getForm()" or "widget.form" in JS.
>
>
> Ah, good to know. Just like document.getElementById() and
> element.getOwnerDocument() in DOM.
I hadn't made the parallel, but it's a good comparison.
>> I also added get/setAttribute on Form that allows passing arbitrary
>> data between the enclosing context (flowscript or action) and the
>> various components operating on the form (validators, event handlers,
>> etc).
>
>
> Nice.
>
>>> Must we specify
>>> Packages.org.apache.cocoon.woody.datatype.ValidationError() ?? It
>>> seems to be to much typing. What about just
>>> setValidationError(String [, more parameters])? Do we loose
>>> flexibility? At the moment there is only
>>> o.a.c.w.validation.ValidationError and the deprecated extending
>>> o.a.c.w.datatype.ValidationError.
>>
>>
>> My plan is to make some of the most useful Woody classes directly
>> visible in the JS snippets. This includes ValidationError, among others.
>
>
> Does this mean like import in Java, so that it is possible to access
> the class without package?
Exactly.
>>> BTW, shouldn't the sample create a non-deprecated ValidationError?
>>
>>
>> Yeah sure. This is the first commit of this new feature, which needs
>> some polishing. The deprecated ValidationError remains from the
>> various code iterations.
>
>
> Ok, will polish it :)
Please do ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [cforms] new validation: every widget can have a validator
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.02.2004 23:12, Sylvain Wallez wrote:
>> Which properties are available here? Obviously widget, but maybe also
>> form?
>
> The form is available on each and every widget through
> "widget.getForm()" or "widget.form" in JS.
Ah, good to know. Just like document.getElementById() and
element.getOwnerDocument() in DOM.
> I also added get/setAttribute on Form that allows passing arbitrary data
> between the enclosing context (flowscript or action) and the various
> components operating on the form (validators, event handlers, etc).
Nice.
>> Must we specify
>> Packages.org.apache.cocoon.woody.datatype.ValidationError() ?? It
>> seems to be to much typing. What about just setValidationError(String
>> [, more parameters])? Do we loose flexibility? At the moment there is
>> only o.a.c.w.validation.ValidationError and the deprecated extending
>> o.a.c.w.datatype.ValidationError.
>
> My plan is to make some of the most useful Woody classes directly
> visible in the JS snippets. This includes ValidationError, among others.
Does this mean like import in Java, so that it is possible to access the
class without package?
>> BTW, shouldn't the sample create a non-deprecated ValidationError?
>
> Yeah sure. This is the first commit of this new feature, which needs
> some polishing. The deprecated ValidationError remains from the various
> code iterations.
Ok, will polish it :)
Joerg
Re: [cforms] new validation: every widget can have a validator
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> From the form1 sample (shortened):
>
> <wd:repeater id="contacts">
> <wd:validation>
> <wd:javascript>
> ...
> for (var i = 0; i < widget.size; i++) {
>
> Which properties are available here? Obviously widget, but maybe also
> form? This would be cool as I can replace the XReporter asserts that I
> have problems with.
The form is available on each and every widget through
"widget.getForm()" or "widget.form" in JS.
I also added get/setAttribute on Form that allows passing arbitrary data
between the enclosing context (flowscript or action) and the various
components operating on the form (validators, event handlers, etc).
> ...
> row.getWidget("firstname").setValidationError(new
> Packages.org.apache.cocoon.woody.datatype.ValidationError("Duplicate
> contact name", false));
>
> Must we specify
> Packages.org.apache.cocoon.woody.datatype.ValidationError() ?? It
> seems to be to much typing. What about just setValidationError(String
> [, more parameters])? Do we loose flexibility? At the moment there is
> only o.a.c.w.validation.ValidationError and the deprecated extending
> o.a.c.w.datatype.ValidationError.
My plan is to make some of the most useful Woody classes directly
visible in the JS snippets. This includes ValidationError, among others.
> BTW, shouldn't the sample create a non-deprecated ValidationError?
Yeah sure. This is the first commit of this new feature, which needs
some polishing. The deprecated ValidationError remains from the various
code iterations.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [cforms] new validation: every widget can have a validator
Posted by Joerg Heinicke <jo...@gmx.de>.
From the form1 sample (shortened):
<wd:repeater id="contacts">
<wd:validation>
<wd:javascript>
...
for (var i = 0; i < widget.size; i++) {
Which properties are available here? Obviously widget, but maybe also
form? This would be cool as I can replace the XReporter asserts that I
have problems with.
...
row.getWidget("firstname").setValidationError(new
Packages.org.apache.cocoon.woody.datatype.ValidationError("Duplicate
contact name", false));
Must we specify
Packages.org.apache.cocoon.woody.datatype.ValidationError() ?? It seems
to be to much typing. What about just setValidationError(String [, more
parameters])? Do we loose flexibility? At the moment there is only
o.a.c.w.validation.ValidationError and the deprecated extending
o.a.c.w.datatype.ValidationError.
BTW, shouldn't the sample create a non-deprecated ValidationError?
...
</wd:javascript>
</wd:validation>
Joerg
On 04.02.2004 18:50, Sylvain Wallez wrote:
> Hi peeps,
>
> I finally managed to finish the new style of validation we discussed a
> while ago.
>
> This new validation allows *any* widget to have a validator. The
> immediate effect is that <wd:validator> is now outside of <wd:datatype>
> since not all widgets have a datatype.
>
> The validator interface has also changed, since not all widgets are
> capable of displaying a validation error. A validator now has the
> responsibility, if validation fails, to set a ValidationError on the
> validated widget itself or one of its children. Widgets that accept a
> validation error implement the ValidationErrorAware interface.
>
> The existing validators have been wrapped with an adapter and are
> therefore still supported, although deprecated.
>
> I updated the form1 definition in the samples: moved the validation
> outside the datatype, and added a validation on the repeater that checks
> if contact names are disctinct among the different rows. This sample
> uses a new JavaScriptValidator that allows validator to be written as a
> JS snippet.
>
> Enjoy,
> Sylvain
>