Re: Comparable validation design
I've put an initial version of this validator at the following URL (manually constructed since the link isn't active yet -- may have typos). http://cvs.sourceforge.net/viewcvs.py/jsf-comp/componentsandbox/src/java/org/apache/myfaces/custom/comparetovalidator/CompareToValidator.java It'll probably take a little time for the link to become active, so you might have better luck grabbing it from jsf-comp cvs directly. Make sure to get at least Revision: 1.2 as I added the documentation in that revision. I can also email it to anyone who wants it. On 10/25/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > -Original Message- > 1) What should happen if the compared values do not implement > Comparable and no Comparable is provided? > > Right now, it's passively passing validation. I wonder if it should > throw a FacesException (not ValidationException) instead? > -Original Message- > FacesException. > We could try to catch it already in the tag, but for safety, throw > the exception during validation. > > -Original Message- > 2) If either the foreign component value or the parent component value > are null, perform no validation? This is going to happen by default > if the parent component value is null since JSF won't execute > validators in that case. > > We can't validate if: > a) value is null and foreign value is null > b) value is null and foreign value is not null. > > We could try to validate if > c) value is not null and foreign value is null > d) value is not null and foreign value is not null > > For consistency, I'd say we'd do the same thing for the foreign key, > and only try to validate for case d). > -Original Message- > +1: only d) should be validated > > regards > Alexander >
RE: Comparable validation design
-Original Message- 1) What should happen if the compared values do not implement Comparable and no Comparable is provided? Right now, it's passively passing validation. I wonder if it should throw a FacesException (not ValidationException) instead? -Original Message- FacesException. We could try to catch it already in the tag, but for safety, throw the exception during validation. -Original Message- 2) If either the foreign component value or the parent component value are null, perform no validation? This is going to happen by default if the parent component value is null since JSF won't execute validators in that case. We can't validate if: a) value is null and foreign value is null b) value is null and foreign value is not null. We could try to validate if c) value is not null and foreign value is null d) value is not null and foreign value is not null For consistency, I'd say we'd do the same thing for the foreign key, and only try to validate for case d). -Original Message- +1: only d) should be validated regards Alexander
Re: Comparable validation design
A few more questions. 1) What should happen if the compared values do not implement Comparable and no Comparable is provided? Right now, it's passively passing validation. I wonder if it should throw a FacesException (not ValidationException) instead? 2) If either the foreign component value or the parent component value are null, perform no validation? This is going to happen by default if the parent component value is null since JSF won't execute validators in that case. We can't validate if: a) value is null and foreign value is null b) value is null and foreign value is not null. We could try to validate if c) value is not null and foreign value is null d) value is not null and foreign value is not null For consistency, I'd say we'd do the same thing for the foreign key, and only try to validate for case d). On 10/25/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > @attribute name: > > Couldn't find anything in the 1.2 spec. Looks like it's been > postponed to 2.0 for everything but the required attribute, and for > the required attribute it's named "requiredMessage" > > So I'm recommending that we use "message" as the attribute. > > @validator name: > > "compareToValidator" was perfect, until Mathias's java.util.Comparator > suggestion :) > But I think it still works even with that suggestion, and I'm going to > go with that for now. > > @java.util.Comparator: > > Excellent. I'll add this in. > > @operator names: > > I decided to go ahead and add in "eq", "ne", [...], "==", "!=", [...] > and "=" as operator names since there wasn't any cost to supporting > multiple versions. > > On 10/25/05, Jesse Alexander (KBSA 21) > <[EMAIL PROTECTED]> wrote: > > -Original Message- > > @attribute name: > > > > is there something like this in the RI 1.2? I think that yes, so maybe > > we should go with their name for this. > > -/Original Message- > > +1 > > > > -Original Message- > > @comparable: right, there is the interface name - I didn't think about that. > > > > But then the "equalsValidator" is named by the method it calls - so > > maybe we should take the method name here as well - > > "compareToValidator" or more simple "compareValidator" ? > > > > Forget about my suggestions if I start to enerve you - then just take > > the interface name ;) > > -/Original Message- > > Consider the stage for this to be some sort of brain-storming... > > > > -Original Message- > > define an additional attribute (comparator) which allows the user to > > specify a comparator instance which implements java.util.Comparator if > > the objects don´t implement Comparable > > -/Original Message- > > Good idea > > > > regards > > Alexander > > >
Re: Comparable validation design
@attribute name: Couldn't find anything in the 1.2 spec. Looks like it's been postponed to 2.0 for everything but the required attribute, and for the required attribute it's named "requiredMessage" So I'm recommending that we use "message" as the attribute. @validator name: "compareToValidator" was perfect, until Mathias's java.util.Comparator suggestion :) But I think it still works even with that suggestion, and I'm going to go with that for now. @java.util.Comparator: Excellent. I'll add this in. @operator names: I decided to go ahead and add in "eq", "ne", [...], "==", "!=", [...] and "=" as operator names since there wasn't any cost to supporting multiple versions. On 10/25/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > -Original Message- > @attribute name: > > is there something like this in the RI 1.2? I think that yes, so maybe > we should go with their name for this. > -/Original Message- > +1 > > -Original Message- > @comparable: right, there is the interface name - I didn't think about that. > > But then the "equalsValidator" is named by the method it calls - so > maybe we should take the method name here as well - > "compareToValidator" or more simple "compareValidator" ? > > Forget about my suggestions if I start to enerve you - then just take > the interface name ;) > -/Original Message- > Consider the stage for this to be some sort of brain-storming... > > -Original Message- > define an additional attribute (comparator) which allows the user to > specify a comparator instance which implements java.util.Comparator if > the objects don´t implement Comparable > -/Original Message- > Good idea > > regards > Alexander >
RE: Comparable validation design
-Original Message- @attribute name: is there something like this in the RI 1.2? I think that yes, so maybe we should go with their name for this. -/Original Message- +1 -Original Message- @comparable: right, there is the interface name - I didn't think about that. But then the "equalsValidator" is named by the method it calls - so maybe we should take the method name here as well - "compareToValidator" or more simple "compareValidator" ? Forget about my suggestions if I start to enerve you - then just take the interface name ;) -/Original Message- Consider the stage for this to be some sort of brain-storming... -Original Message- define an additional attribute (comparator) which allows the user to specify a comparator instance which implements java.util.Comparator if the objects don´t implement Comparable -/Original Message- Good idea regards Alexander
Re: Comparable validation design
> I'm also planning on having the comparisons done using the Comparable > interface, so the validator would work only on objects implementing > Comparable (but that seems like it'd probably cover anything worth > comparing). define an additional attribute (comparator) which allows the user to specify a comparator instance which implements java.util.Comparator if the objects don´t implement Comparable -- Mathias
Re: Comparable validation design
@attribute name: is there something like this in the RI 1.2? I think that yes, so maybe we should go with their name for this. @comparable: right, there is the interface name - I didn't think about that. But then the "equalsValidator" is named by the method it calls - so maybe we should take the method name here as well - "compareToValidator" or more simple "compareValidator" ? Forget about my suggestions if I start to enerve you - then just take the interface name ;) regards, Martin On 10/24/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > comparingValidator works for me. As Alexander pointed out, I used > comparableValidator as a "first guess" because it works on any objects > implementing Comparable. > > I don't see the need for comparingValidator to depend on the > OptionalValidatorFramework, although the supporting "boolean wrapping > validator" that Alexander proposed might share code with the OVF > project. > > The OptionalValidatorFramework isn't quite ready yet. I'd say it's > 95% done functionally, but there's still some more work that needs to > be done to handle converters better. Now that we've got it > functional, we have a lot of cleanup that remains. I'm also not happy > with how the facelets integration was implemented, and I need to work > out those details with the Facelets folks. > > Does anyone have a suggestion on the attribute name for specifying an > optional identifier of the message as it is the message-files? This > attribute would be a good tomahawk extension for all validators. > > On 10/22/05, Jesse Alexander (KBSA 21) > <[EMAIL PROTECTED]> wrote: > > -Original Message- > > Just a naming thing - shouldn't it be or > > instead of ? > > -/Original Message- > > I guess the name is just a first throw... maybe comparable > > because it accepts any Comparable object... But part of bringing > > it up here is get some more opinions. > > > > > > -Original Message- > > By the way, are you guys going to move the optional validator > > framework over as well? > > -/Original Message- > > Well, I opened the jsf-comp project as a means to try out stuff > > in a shared way. the rules for getting access are more loose. > > And when the community thinks our stuff is good enough, I would > > really enjoy seeing it moved to the myfaces project. Consider > > our project as a playground for shareable components, a testbed > > before moving them to MyFaces. > > > > the comparable/comparing validator most likely will depend on the > > optional validator stuff. > > > > Does that sound good? > > > > regards, > > Alexander > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
Re: Comparable validation design
comparingValidator works for me. As Alexander pointed out, I used comparableValidator as a "first guess" because it works on any objects implementing Comparable. I don't see the need for comparingValidator to depend on the OptionalValidatorFramework, although the supporting "boolean wrapping validator" that Alexander proposed might share code with the OVF project. The OptionalValidatorFramework isn't quite ready yet. I'd say it's 95% done functionally, but there's still some more work that needs to be done to handle converters better. Now that we've got it functional, we have a lot of cleanup that remains. I'm also not happy with how the facelets integration was implemented, and I need to work out those details with the Facelets folks. Does anyone have a suggestion on the attribute name for specifying an optional identifier of the message as it is the message-files? This attribute would be a good tomahawk extension for all validators. On 10/22/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > -Original Message- > Just a naming thing - shouldn't it be or > instead of ? > -/Original Message- > I guess the name is just a first throw... maybe comparable > because it accepts any Comparable object... But part of bringing > it up here is get some more opinions. > > > -Original Message- > By the way, are you guys going to move the optional validator > framework over as well? > -/Original Message- > Well, I opened the jsf-comp project as a means to try out stuff > in a shared way. the rules for getting access are more loose. > And when the community thinks our stuff is good enough, I would > really enjoy seeing it moved to the myfaces project. Consider > our project as a playground for shareable components, a testbed > before moving them to MyFaces. > > the comparable/comparing validator most likely will depend on the > optional validator stuff. > > Does that sound good? > > regards, > Alexander >
RE: Comparable validation design
-Original Message- Just a naming thing - shouldn't it be or instead of ? -/Original Message- I guess the name is just a first throw... maybe comparable because it accepts any Comparable object... But part of bringing it up here is get some more opinions. -Original Message- By the way, are you guys going to move the optional validator framework over as well? -/Original Message- Well, I opened the jsf-comp project as a means to try out stuff in a shared way. the rules for getting access are more loose. And when the community thinks our stuff is good enough, I would really enjoy seeing it moved to the myfaces project. Consider our project as a playground for shareable components, a testbed before moving them to MyFaces. the comparable/comparing validator most likely will depend on the optional validator stuff. Does that sound good? regards, Alexander
Re: Comparable validation design
I agree with Jesse on his preferences. Just a naming thing - shouldn't it be or instead of ? By the way, are you guys going to move the optional validator framework over as well? regards, Martin On 10/21/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > -Original Message- > > > > Ha ha! You're the expert on designing validators that wrap other > validators. I'll let you write that one! :-) > -/Original Message- > Remember how I first objected to have OVW defined also as Validator... > Just a few seconds later a first flash of cascaded validators > floated before my eyes... and while eating ... this idea solidified... > > Should be possible ;-) > > regards > Alexander > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
RE: Comparable validation design
-Original Message- > Ha ha! You're the expert on designing validators that wrap other validators. I'll let you write that one! :-) -/Original Message- Remember how I first objected to have OVW defined also as Validator... Just a few seconds later a first flash of cascaded validators floated before my eyes... and while eating ... this idea solidified... Should be possible ;-) regards Alexander
Re: Comparable validation design
> Ha ha! You're the expert on designing validators that wrap other validators. I'll let you write that one! :-) On 10/21/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > -Original Message- > 1) is what I'm currently > doing. > 2) > > a) Operator values being "eq", "ne", "lt", "gt", "ge", and "le" in > addition to (or maybe instead of) > b) "==", "!=", ">", "<", "=>'", and "=<". > -/Original Message- > I'd prefer > from 1 and 2: proposal 2 > from a and b: proposal a > > -Original Message- > alternateOperatorName="after" /> > -/Original Message- > How about specifying the identifier of the message as it is the > message-files? > > -Original Message- > I'm also planning on having the comparisons done using the Comparable > interface, so the validator would work only on objects implementing > Comparable (but that seems like it'd probably cover anything worth > comparing). > -/Original Message- > good idea > > > Additional idea: > How about cascading boolean validators added in? > Something like this: > > > > > > > > > regards > Alexander >
RE: Comparable validation design
-Original Message- 1) is what I'm currently doing. 2) a) Operator values being "eq", "ne", "lt", "gt", "ge", and "le" in addition to (or maybe instead of) b) "==", "!=", ">", "<", "=>'", and "=<". -/Original Message- I'd prefer from 1 and 2: proposal 2 from a and b: proposal a -Original Message- -/Original Message- How about specifying the identifier of the message as it is the message-files? -Original Message- I'm also planning on having the comparisons done using the Comparable interface, so the validator would work only on objects implementing Comparable (but that seems like it'd probably cover anything worth comparing). -/Original Message- good idea Additional idea: How about cascading boolean validators added in? Something like this: regards Alexander
