RE: [validator] conversion error while validating listbox component's value

[he...@dnbnor.no]

Hi

Your use-case is very specialized. The way I see it, we would need to imlement a groupValidator where you could list all the fields that where to be validated and which validation rules to run. I might be a challenging task that one.

Hermod

-----Original Message-----
From: Hasan Turksoy [mailto:hturksoy@gmail.com]
Sent: Tuesday, March 20, 2007 1:58 PM
To: user@shale.apache.org
Subject: Re: [validator] conversion error while validating listbox
component's value


>>Tomahawk sandbox subForm (and probably others like Trinidad's subForm)
>>will allow you to do validation grouping like you've specified below.

infact subforms can not handle all our requirements.. because we need to
validate "crossform" fields too... suppose we are required to validate (
Form1.fieldA,Form1.fieldB,Form2.fieldC) when comboX submitted and (
Form1.fieldD,Form2.fieldE) when a buttonY submitted...

this means, it's needed, for our project, to validate grouped fields
independent from their forms...

hasan..



On 3/19/07, Mike Kienenberger <mk...@gmail.com> wrote:
>
> Tomahawk sandbox subForm (and probably others like Trinidad's subForm)
> will allow you to do validation grouping like you've specified below.
>
>
> On 3/19/07, Hasan Turksoy <ht...@gmail.com> wrote:
> > >>Sounds like your doing some creating stuff with the validator.
> > Yes, i've customized so many parts at both shale-validator and
> > commons-validator jars... our project needs urgent validation
> requirements..
> > so, i have injected some extra solutions into framework..  nowadays i'm
> > working on validating only some specific(grouped) fields for only some
> > specific submits.. This means; for instance, a combo will only validate
> > A,B,C fields while another button(in the same form) will validate only
> E,F,G
> > fields...
> > This is a hard requirement :).. and needs core changes at framework..
> that's
> > why i have to track and hold all my changes strictly and go parallel
> with
> > original shale code at the same time...
> >
> > best regards,
> >
> > hasan...
> >
> >
> >
> >
> > On 3/17/07, Gary VanMatre <gvanmatre@comcast.net > wrote:
> > >
> > > >From: "Hasan Turksoy" < hturksoy@gmail.com>
> > > >
> > > > i have implemented a workaround for this serverside required
> problem...
> > > > shortly: if validatorscript sets the required attribute, as you say,
> JSF
> > > > won't call my serverside validator when that field's value is
> empty...
> > > to
> > > > overcome this, i've commented the validatorscript's required
> attribute
> > > > setting code.. this means JSF can't see that field as required and
> not
> > > call
> > > > any required validator for that field... So, how can we call
> serverside
> > > > required validators? I've implemented an
> > > > idea from myfaces wiki..
> > > >
> > > > Implementation in short; i have developed an
> > > > RequiredValidatorChecker component.. it traverses all the component
> tree
> > > and
> > > > calls validate methods for found required validators...
> > > > i have entered a blog about  this solution...
> > > >
> > > > So, you can think that serverside required validations are being
> called
> > > when
> > > > needed...
> > > >
> > > > In fact, the problem is ConverterHelper can not handle array/list
> types
> > > in
> > > > current situation... although i can't think of any such scenario,
> > > somehow a
> > > > validation may be necessary to validate an array/list value.. so,
> how
> > > should
> > > > it work in this case? (May be such a scenario is not possible ;) )
> > > >
> > >
> > > Shale Clay has an example of using a converter for string
> arrays[1][2].
> > >
> > > I don't understand your problem with the validators.  I think I would
> have
> > >
> > > tried using the "immediate" flag on the commands to stop short of
> > > validation.
> > > Or, looked at one of tomahawk or trinidad's subform components but you
> > > might have a complex layout that won't let you do that.
> > >
> > > Sounds like your doing some creating stuff with the validator.
> > >
> > > [1]
> > >
> http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/convert/StringArrayConverter.java?view=markup
> > > [2]
> > >
> http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/resources/META-INF/faces-config.xml?view=markup
> > >
> > >
> > > > Hasan...
> > > >
> > > >
> > > > On 3/16/07, Gary VanMatre wrote:
> > > > >
> > > > >
> > > > > The server-side "required" commons validator rule is kind of
> bogus.
> > > I've
> > > > > only seen it useful
> > > > > for client side validation. This is because JSF requires a value
> > > before
> > > > > it will even invoke
> > > > > the server side validation logic. A component's validator will not
> be
> > > > > invoked if the component doesn't have a value. There is a separate
> > > > > "required" attribute for components that are EditableValueHolders.
> > > > >
> > > > > The shale ValidatorScript component, that must be added at the end
> of
> > > the
> > > > > page, looks through the component tree and toggles on the required
> > > attribute
> > > > > for components that include the shale commons validator required
> > > server side
> > > > > rule. So, the ValidatorScript component is needed even if you are
> only
> > > > > using sever side rules.
> > > > >
> > > > > Gary
> >
>


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that the DnB NOR Group
cannot accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *