Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-23 Thread Gary VanMatre 
>From: "Hasan Turksoy" <[EMAIL PROTECTED]> 
>
> >I agree it is not acceptable but they are not behaving differently. The 
> validator assigned to the component will be invoked before the 
> >CommonsValidator is invoked. 
> 
> there is NO custom validator Gary, only custom converters there :).. i've 
> realized that i made a mistake while writing my previous mail.. It should be 
> "custom converter" instead of "custom validator".. Sorry for this mistake... 
> 
> >I'm not disagreeing that you have uncovered a bug that will be addressed 
> but what I'm saying is that Shales Commons Validator is using JSF 
> >converters as a utility [1] for converting from one data type to another. 
> 
> what i'm sayin is that too :) i only want to draw attention to custom 
> converters of components before using those JSF converters. 
> 
> >It does this nonsense to provide a generic way (single converter that works 
> for any rule) to invoke any custom validation rule that you might add. 
> 
> i am not talking about using a generic converter or etc - as i say previous 
> sentence... 
> 
> Let me summarize the conversation: 
> in current case; when i assigned a custom converter for a field, JSF RI is 
> using that custom converter but CommonsValidator is using by-type 
> converter.. This leads some misbehaviours... 
> 
> Your comments light my mind,, and asked the same question for whole 
> yesterday... 
> if the value passed to the validator already converted, so why 
> commonsvalidator trying to convert that value again? The answer is; to use a 
> generic validator to do all validations.. As you say at your previous entry; 
> "The data conversion occurs because the apache commons validator needs a 
> String data type and not a date data type." 
> 
> Exactly at this point my issue/suggestion comes: 
> Main point is: Validator have to use the SAME CONVERTER which used before 
> sending that value to it... 
> i mean; if a value converted to java.util.Date type by ConverterX and send 
> to CommonsValidator to validate, so, CommmonsValidator must use that same 
> converter(ConverterX) too, to convert that value again toString/toObject... 
> not java.util.Date type's registered converter... 
>


It is a good question and it's not the first time it has been asked.  It sounds 
like you are familiar it commons validator [1].  It’s important to point out 
that the shale JSF flavor is an integration layer to an existing solution.  

The example we are talking about here is pretty simple. The shale commons 
validator is passed a java.util.Date.  The method performing the validation 
needs two String’s as part of the actual parameter. 


Now, let’s say that I have a custom validation function that I want to 
register.  We’ll use another simple example.  Let’s say that my custom date 
validation function needs a java.sql.Date.

public class MyValidationRule
   public static boolean isDateOnWeekend(java.sql.Date value) 

To register the custom rule with the shale’s JSF integration with commons 
validator [1], I need to declare a new rule in the validator-rule.xml [2] 
configuration file.  My custom validation rule doesn’t have client side script 
support – only server-side.


 
..
…
….
  








The JSP might look something like this:


   

  


The converter registered with the component, "f:convertDateTime",  will convert 
from String to “java.sql.Date”.  How are we going to invoke this function 
without type conversion?  The shale commons validator provides a declarative 
mechanism to register various validation rules.  The same chunk of code handles 
invoking all rules, not just the “date” rule that we have been discussing.


This leads to the bigger questions.  Is this the best way to implement 
validator’s in JSF?  Well probably not.  

Does it provide integration with an existing apache project that focuses on 
declarative form based validation (client and server side).  Yes. 

[1] http://jakarta.apache.org/commons/validator/
[2] 
http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/resources/org/apache/shale/validator/validator-rules.xml?view=markup


 
> regards, 
> 
> hasan 
> http://www.jroller.com/hasant 
> 

Gary


> 
> 
> On 2/23/07, Gary VanMatre wrote: 
> > 
> > >From: "Hasan Turksoy" 
> > > 
> > > 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 
> > > 
> > > Because; in JSF, one can add custom converter for each component 
> > > separately... in such a case, using my by-type java.util.Date converter 
> > is 
> > > meaningless! because, user assigned a custom converter for that field!! 
>

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-23 Thread Hasan Turksoy 

I agree it is not acceptable but they are not behaving differently.  The

validator assigned to the component will be invoked before the

CommonsValidator is invoked.


there is NO custom validator Gary, only custom converters there :).. i've
realized that i made a mistake while writing my previous mail.. It should be
"custom converter" instead of "custom validator".. Sorry for this mistake...


I'm not disagreeing that you have uncovered a bug that will be addressed

but what I'm saying is that Shales Commons Validator is using JSF

converters as a utility [1] for converting from one data type to another.


what i'm sayin is that too :) i only want to draw attention to custom
converters of components before using those JSF converters.


It does this nonsense to provide a generic way (single converter that works

for any rule) to invoke any custom validation rule that you might add.

i am not talking about using a generic converter or etc - as i say previous
sentence...

Let me summarize the conversation:
in current case; when i assigned a custom converter for a field, JSF RI is
using that custom converter but CommonsValidator is using by-type
converter.. This leads some misbehaviours...

Your comments light my mind,, and asked the same question for whole
yesterday...
if the value passed to the validator already converted, so why
commonsvalidator trying to convert that value again? The answer is; to use a
generic validator to do all validations.. As you say at your previous entry;
"The data conversion occurs because the apache commons validator needs a
String data type and not a date data type."

Exactly at this point my issue/suggestion comes:
Main point is: Validator have to use the SAME CONVERTER which used before
sending that value to it...
i mean; if a value converted to java.util.Date type by ConverterX and send
to CommonsValidator to validate, so, CommmonsValidator must use that same
converter(ConverterX) too, to convert that value again toString/toObject...
not java.util.Date type's registered converter...

regards,

hasan
http://www.jroller.com/hasant



On 2/23/07, Gary VanMatre <[EMAIL PROTECTED]> wrote:


>From: "Hasan Turksoy" <[EMAIL PROTECTED]>
>
> 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
>
> Because; in JSF, one can add custom converter for each component
> separately... in such a case, using my by-type java.util.Date converter
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?
>


I agree it is not acceptable but they are not behaving differently.  The
validator assigned to the component will be invoked before the
CommonsValidator is invoked.



> 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!!...

Not exactly, the "java.util.Date" converter is used by commons validator
to convert a Date object to a String (within the validator's validate
method).  The custom converter assigned to the component (the same component
that is using commons validator), is being invoked prior to the call to
commons validator.
I'm not disagreeing that you have uncovered a bug that will be addressed
but what I'm saying is that Shales Commons Validator is using JSF converters
as a utility [1] for converting from one data type to another.  It does this
nonsense to provide a generic way (single converter that works for any rule)
to invoke any custom validation rule that you might add.
I'll try to summarize with code:
// Validator's interface
public void validate(FacesContext context, UIComponent component, Object
value)  {
..
Date obj  = (Date) value;// value is already processed by the
components converter (String --> Date)
ConverterHelper converterHelper = new ConverterHelper();
// uses the a JSF converter Object to String
String objString = converterHelper.asString(context, obj.getClass(), obj);
boolean isValid = isDate(objString, datepattern);

[1]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup

>
> In conclusion; when we look

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-22 Thread Gary VanMatre 
>From: "Hasan Turksoy" <[EMAIL PROTECTED]> 
>
> 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 
> 
> Because; in JSF, one can add custom converter for each component 
> separately... in such a case, using my by-type java.util.Date converter 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? 
>


I agree it is not acceptable but they are not behaving differently.  The 
validator assigned to the component will be invoked before the CommonsValidator 
is invoked.



> 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!!... 
 
Not exactly, the "java.util.Date" converter is used by commons validator to 
convert a Date object to a String (within the validator's validate method).  
The custom converter assigned to the component (the same component that is 
using commons validator), is being invoked prior to the call to commons 
validator.
I'm not disagreeing that you have uncovered a bug that will be addressed but 
what I'm saying is that Shales Commons Validator is using JSF converters as a 
utility [1] for converting from one data type to another.  It does this 
nonsense to provide a generic way (single converter that works for any rule) to 
invoke any custom validation rule that you might add.
I'll try to summarize with code:
// Validator's interface
public void validate(FacesContext context, UIComponent component, Object value) 
 {
..
Date obj  = (Date) value;// value is already processed by the components 
converter (String --> Date)
ConverterHelper converterHelper = new ConverterHelper();
// uses the a JSF converter Object to String
String objString = converterHelper.asString(context, obj.getClass(), obj);
boolean isValid = isDate(objString, datepattern);

[1] 
http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup

> 
> 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 agree... 


> i can provide code if required... 
> 
> regards.. 
> 
> hasan.. 
> 
> 

Gary


> 
> 
> 
> 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.Date class.. 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 f

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-22 Thread Gary VanMatre 
>From: "Hasan Turksoy" <[EMAIL PROTECTED]> 
>
> > Craig 
> i have created an issue.. you can reach it from 
> here> s-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 
> 

The shale commons validator is infact a JSF validator.  As you have stated, 
this means any converter assigned to the component will be invoked before 
validation.  The value passed to the validate method of the validator, is the 
converted type.  That's just how JSF works and how Shale CommonsValidator works 
[1].

I think the problem lies in the "loadMethodParamValues" method in the commons 
validator [1].  More specifically the "convert" method which uses JSF 
validators to convert the "Date" to a String.  The data conversion occurs 
because the apache commons validator needs a String data type and not a date 
data type.  


[1] 
http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/CommonsValidator.java?view=markup

The   


> 
> 
> 
> On 2/22/07, Gary VanMatre wrote: 
> > 
> > >From: "Matthias Wessendorf" 
> > > 
> > > 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. 
> > 
> > java.util.Date 
> > 
> > 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. 
> > 
> > > > 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,

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-22 Thread Hasan Turksoy 

Craig

i have created an issue.. you can reach it from
here
...


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.

java.util.Date

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.

  



[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 signatu

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-22 Thread Gary VanMatre 
>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.

java.util.Date

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.

   



[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.Date converter 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.Date class.. 
> > > > 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: 
>

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-22 Thread Matthias Wessendorf 

On 2/22/07, Hasan Turksoy <[EMAIL PROTECTED]> 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

-M



Because; in JSF, one can add custom converter for each component
separately... in such a case, using my by-type java.util.Date converter 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 <[EMAIL PROTECTED]> wrote:
>
> >From: "Hasan Turksoy" <[EMAIL PROTECTED]>
> >
> > 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.Date class.. 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

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-22 Thread Craig McClanahan 

On 2/22/07, Hasan Turksoy <[EMAIL PROTECTED]> 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

Because; in JSF, one can add custom converter for each component
separately... in such a case, using my by-type java.util.Date converter 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...


This definitely sounds like a real issue.  Could you file a bug report
in our issue tracking system[1]  so we can get it addressed?

Craig

[1] https://issues.apache.org/struts/browse/SHALE




regards..

hasan..





On 2/21/07, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> >From: "Hasan Turksoy" <[EMAIL PROTECTED]>
> >
> > 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.Date class.. 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.

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-22 Thread Hasan Turksoy 

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

Because; in JSF, one can add custom converter for each component
separately... in such a case, using my by-type java.util.Date converter 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 <[EMAIL PROTECTED]> wrote:


>From: "Hasan Turksoy" <[EMAIL PROTECTED]>
>
> 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;
>
>
>
>  
>  />
>
>
> 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.Date class.. 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.

Re: [shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-21 Thread Gary VanMatre 
>From: "Hasan Turksoy" <[EMAIL PROTECTED]> 
>
> 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; 
> 
> 
>
>  
>  />
>
> 
> 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.Date class.. 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.

[shale-validator] CommonsValidator doesn't take component converters into account!

2007-02-21 Thread 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;


 
 


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."

as i understand; it needs a converter for the java.util.Date class.. 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??

thanks in advance,
hasan...