>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]. Its 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 Strings as part of the actual parameter.
Now, lets say that I have a custom validation function that I want to
register. Well use another simple example. Lets 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 shales 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 doesnt have client side script
support only server-side.
<validator name="dateonweekend"
classname="org.acme.MyValidationRule "
method=" isDateOnWeekend"
methodParams="java.sql.Date"
msg="errors.date"
depends=""/>
..
.
<form name="org.apache.shale.validator.dateonweekend">
<field property="date">
<arg position="0" name="message" key="arg" resource="false"/>
<arg position="1" name="message" key="submittedValue"
resource="false"/>
<arg position="0" name="parameter" key="submittedValue"
resource="false"/>
</field>
</form>
The JSP might look something like this:
<h:inputText id="date"
value="#{mybean.partytime}">
<f:convertDateTime pattern="MM/dd/yyyy"/>
<val:commonsValidator
type="dateonweekend"
datePatternStrict="MM/dd/yyyy"
message="{0} is not on the weekend"
arg="Party time"
server="true"
client="false"/>
</h:inputText>
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
validators 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!!
> > 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 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.
