Craig
i have created an issue.. you can reach it from
here<http://www.nabble.com/CommonsValidator-doesn%2527t-take-component-converters-into-account%2521-tf3266040.html>
...
Matthias
you are absolutely right :). converters only defined(by id) in config file
but they aren't registered for special types in general.. these converters
generally assigned for components externally... may be, i've over
consantrated about "looking for custom component converters before by-type
converters" part of conversation ;)
Gary
in fact, it doesn't matter, whether there is a converter for that type or
not... in any case, CommonsValidator should look for component's custom
converter first. if can not find, look up for a by-type converter later.
this is the main issue... JSF RI works as this way..
there might be a registered converter for my type.. But if i assigned a
custom converter for a field, JSF RI will use it not the registered by-type
converter.. so CommonsValidator should work like it too....
hasan..
http://www.jroller.com/page/hasant
On 2/22/07, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>From: "Matthias Wessendorf" <[EMAIL PROTECTED]>
>
> On 2/22/07, Hasan Turksoy wrote:
> > jsf-ri1.1 contains converter for "javax.faces.DateTime" class only...
not
> > for java.util.Date class.... you can download and look at
> > jsf-ri-config.xml...
> >
> > in fact, this is not the main problem... i can overcome my issue by
adding a
> > converter for "java.util.Date"... But this doesn't solve the problem
in the
> > origin....
>
> are you talking about this:
>
> javax.faces.DateTime
> javax.faces.convert.DateTimeConverter
>
>
>
> that is just the id...
>
> I think the -for-class is only there for "simple" converters like
>
> javax.faces.convert.FloatConverter
>
Yeah, for some reason I was thinking that the RI already has a converter
registered by type for the java.util.Date type.
<converter-for-class>java.util.Date</converter-for-class>
The shale commons validator uses the ConverterHelper [1] (uses JSF type
converters) to convert the submitted value, after the components converter
has already converted to a Date object, back to a String to match the
commons validator methodParams.
<validator name="date"
classname="org.apache.shale.validator.CommonsValidator"
method="isDate"
methodParams="java.lang.String,java.lang.String"
msg="errors.date"
jsFunctionName="validateDate"
jsFunction="
org.apache.commons.validator.javascript.validateDate"
depends=""/>
[1]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup
> -M
>
Gary
>
> > Because; in JSF, one can add custom converter for each component
> > separately... in such a case, using my by-type java.util.Dateconverter is
> > meaningless! because, user assigned a custom converter for that
field!! JSF
> > will use it instead of by-type converter... so, commons should use it
too...
> >
> > now, when assigned custom validator for fields,, JSF RI and
CommonsValidator
> > behaving differently!!! this is not an acceptable situation! isn't it?
> >
> > to realize the problem... when returned to my sample in the previous
post;
> > suppose that i have a "java.util.Date" converter... and no custom
> > converter... in this case, CommonsValidator and JSF RI will work
same..
> > both will use our by-type converter...
> >
> > But, if i use a custom converter for my inputtext as below;
> >
> > **
> > > > />
> >
> >
> > then, JSF RI will use this custom component converter to convert it's
value
> > but CommonsValidator will use our by-type java.util.Date converter...
> > different behaviours!!...
> >
> > In conclusion; when we look at JSF RI code, we see that; it first
looks for
> > custom component converter then, if can not find, searches for a
by-type
> > converter... CommonsValidator must work same i think...
> >
> > i have injected my solution into my CommonsValidator class and it
works
> > perfect... above suggestion should be implemented in original
> > CommonsValidator releases as soon as possible i think...
> >
> > i can provide code if required...
> >
> > regards..
> >
> > hasan..
> >
> >
> >
> >
> >
> > On 2/21/07, Gary VanMatre wrote:
> > >
> > > >From: "Hasan Turksoy"
> > > >
> > > > hi all,
> > > >
> > > > Env: jsf1.1, commons-validator1.3.1, shale1.0.4..
> > > >
> > > > i'am trying to put a required validator for my date entering
field.. My
> > > > field has a f:convertDateTime to make conversion between String
<->
> > > > java.util.Date. it's like;
> > > >
> > > >
> > > >
> > > >
> > > > > > > server="true"
> > > >/>
> > > >
> > > >
> > > > When i entered a valid value into my date field it throws a
> > > > ConverterException as below;
> > > >
> > > > "javax.faces.ConverterException: You have requested a conversion
for
> > > type
> > > > java.util.Date, but there is no by-type converter registered for
this
> > > type."
> > > >
> > >
> > >
> > > I'm not sure why you are seeing this exception. I belive that the
> > > java.util.Data
> > > converter should be registered with the JSF runtime.
> > >
> > > Can you tell where the exception is being raised from the stack
trace?
> > > The reason for asking is that the shale commons validator uses JSF
> > > converters to coerce data types to match the signatures of the
server
> > > side validation methods.
> > >
> > >
> > >
> > >
> > >
> > > > as i understand; it needs a converter for the java.util.Dateclass.. But
> > > in
> > > > JSF, one can assign custom converter tags as above sample...
> > > >
> > > > this means, (my suggestion) commonsvalidator should get the
converter
> > > for
> > > > that type from component. if component don't have any converters
> > > assigned,
> > > > it should lookup for a by-type converter then... Otherwise, i will
have
> > > to
> > > > define by-type converters for all my component converters! this
will be
> > > > stupid i think...
> > > >
> > > > any comments?? or solutions??
> > > >
> > > What version of the JSF runtime are you using? This sounds like a
rutime
> > > issue.
> > >
> > >
> > >
> > > > thanks in advance,
> > > > hasan..
> > >
> > >
> > > Gary.
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
