You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2004/05/25 14:44:27 UTC
Re: how to do form custom validators
Johnson wrote:
>I see the instruction
>*) CForms: Remove custom flow level forms validators. [VG]
>how to to custom validators now?
>
>
See <fd:validation> tags in:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/samples/forms/form1.xml?rev=1.7&view=auto
PS Please avoid cross posting.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: how to do form custom validators
Posted by Joerg Heinicke <jo...@gmx.de>.
On 26.05.2004 09:33, Bruno Dumon wrote:
>> But this is no longer the default way for doing simple
>>field validation. It was really just only a javascript hack. Even for
>>your business logic validation you can probably find better ways to
>>handle it.
>
> No no, you can still do it that way! Just like event listeners can both
> be defined in the form definition and added on a widget instance, the
> same can be done with validators. I agree with Benoit that this is an
> essential feature.
>
> See the interface Widget: it has the methods addValidator and
> removeValidator, which take an object implementing the WidgetValidator
> interface as argument. See the description of that interface on how a
> WidgetValidator implementation is supposed to behave.
>
> There is still one issue, which is that widget validators on parent
> widgets are not executed if any of the validators on one of their child
> widgets fails. Once this is changed, adding a WidgetValidator on a form
> object would be the same as the earlier validator function, except that
> now the validation will be part of normal form processing cycle and that
> avoids a few problems. [this change is just a one line fix, and is
> already agreed upon, but I haven't had time for this yet]
>
> I posted earlier an example to the list on how to implement a Java
> interface in javascript, or you can find that in the rhino docs also.
> Alternatively, in the v3 api you can do widget.validator = function() {}
Thanks for clarification, my answer was _a bit_ superficial.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: how to do form custom validators
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2004-05-26 at 01:07, Joerg Heinicke wrote:
> On 26.05.2004 00:53, Benoit Deshaies wrote:
>
> > I looked at the sample you posted Vadim. I have a question and a
> > comment regarding validation using <fd:javascript>. In those JS
> > snippets, can you access the cocoon object (like session) and can you
> > load your own Java classes (Packages.com.xyz.Object)?
> >
> > And my comment is this: for simple forms, including the validation
> > rules such as which fields are required in the form definition itself
> > is probably fine. But on larger applications with complex validation
> > logic (think income tax report), people are likely to implement some
> > sort of external validator component. My concern is that by including
> > the validation code in the form definition, you're mixing the
> > presentation and business layer. In that respect, I preferred the
> > old-style JS validation function, which correctly put the business
> > logic out of the presentation layer.
>
> Nobody prevents you from doing it that way, you still can readd this for
> your use case.
Hmm, I don't think that's a valid remark. It's like saying "if you don't
like how cocoon works, you can rewrite it".
> But this is no longer the default way for doing simple
> field validation. It was really just only a javascript hack. Even for
> your business logic validation you can probably find better ways to
> handle it.
No no, you can still do it that way! Just like event listeners can both
be defined in the form definition and added on a widget instance, the
same can be done with validators. I agree with Benoit that this is an
essential feature.
See the interface Widget: it has the methods addValidator and
removeValidator, which take an object implementing the WidgetValidator
interface as argument. See the description of that interface on how a
WidgetValidator implementation is supposed to behave.
There is still one issue, which is that widget validators on parent
widgets are not executed if any of the validators on one of their child
widgets fails. Once this is changed, adding a WidgetValidator on a form
object would be the same as the earlier validator function, except that
now the validation will be part of normal form processing cycle and that
avoids a few problems. [this change is just a one line fix, and is
already agreed upon, but I haven't had time for this yet]
I posted earlier an example to the list on how to implement a Java
interface in javascript, or you can find that in the rhino docs also.
Alternatively, in the v3 api you can do widget.validator = function() {}
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: how to do form custom validators
Posted by Joerg Heinicke <jo...@gmx.de>.
On 26.05.2004 00:53, Benoit Deshaies wrote:
> I looked at the sample you posted Vadim. I have a question and a
> comment regarding validation using <fd:javascript>. In those JS
> snippets, can you access the cocoon object (like session) and can you
> load your own Java classes (Packages.com.xyz.Object)?
>
> And my comment is this: for simple forms, including the validation
> rules such as which fields are required in the form definition itself
> is probably fine. But on larger applications with complex validation
> logic (think income tax report), people are likely to implement some
> sort of external validator component. My concern is that by including
> the validation code in the form definition, you're mixing the
> presentation and business layer. In that respect, I preferred the
> old-style JS validation function, which correctly put the business
> logic out of the presentation layer.
Nobody prevents you from doing it that way, you still can readd this for
your use case. But this is no longer the default way for doing simple
field validation. It was really just only a javascript hack. Even for
your business logic validation you can probably find better ways to
handle it.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: how to do form custom validators
Posted by Benoit Deshaies <bd...@yahoo.com>.
I looked at the sample you posted Vadim. I have a question and a
comment regarding validation using <fd:javascript>. In those JS
snippets, can you access the cocoon object (like session) and can you
load your own Java classes (Packages.com.xyz.Object)?
And my comment is this: for simple forms, including the validation
rules such as which fields are required in the form definition itself
is probably fine. But on larger applications with complex validation
logic (think income tax report), people are likely to implement some
sort of external validator component. My concern is that by including
the validation code in the form definition, you're mixing the
presentation and business layer. In that respect, I preferred the
old-style JS validation function, which correctly put the business
logic out of the presentation layer.
Benoit Deshaies
--- Vadim Gritsenko <va...@reverycodes.com> wrote:
> See <fd:validation> tags in:
>
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/samples/forms/form1.xml?rev=1.7&view=auto
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org