Ok, this sounds reasonable.
The annotations-stuff would of course be great.
regards,
Martin
On 10/16/06, Adam Winer <[EMAIL PROTECTED]> wrote:
Martin,
You don't want the validator to be on the component with
the values - once you've said that it's cross-component validation,
that's just not the right place. For one thing, you're relying on
all sorts of ordering and lifecycle processing that is not
likely to be true going forward (see DynaFaces, for example).
You can do a few things:
- Create a parent component whose role in processing
is to perform cross-component validations.
- Use a phase listener and validation processing entirely
external to the JSF component tree
- Perform validation while committing (e.g., during the
Invoke Application phase and an action)
I kinda like the first one.
What I'd really like to see is bean-level annotations
describing validations that need to be run at that level
(so, including cross-property validations), combined with
the use of ELResolver/PropertyResolver magic to
pick up on those bean-level validations (perhaps
looking for bean-level annotations whenever a setValue()
call is made).
-- Adam
On 10/16/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> I totally agree, Matthias. But the question remains - how do you add a
> validation framework if not via adding a validator with the normal
> properties?
>
> And how will this framework be called in the case of a null value, if
> JSF doesn't let the validators (of this extended framework) run?
>
> regards,
>
> Martin
>
> On 10/15/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > for the required case I agree
> >
> > general no. we (jsf) should not invent the wheel of validation at all.
> > it is pretty much common so that is should be handled in 303.
> >
> > I agree that some *cross value* validations can be handy. sometimes yeah,
> > sometimes no. a framework (see sf.net) on top of faces is maybe fine for
that.
> >
> > what's in swing for the case "if field xyz is not submitted handle me
like..." ?
> > or is it only in 296 ?
> >
> > -M
> >
> > On 10/14/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > Hi *;
> > >
> > > I've added a comment to
> > >
> > > http://issues.apache.org/jira/browse/MYFACES-1467
> > >
> > > essentially saying that the null-value should never make a component
> > > skip validation. What do you think about that?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 10/14/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > > hey
> > > >
> > > > I created ADFFACES-238 to keep track of it and we should have issues
> > > > in jira for almost all commits.
> > > >
> > > > Since you agreed to this issue, I commit the change to the template
> > > > tomorrow or so
> > > >
> > > > On 10/13/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote:
> > > > > I think you're right.
> > > > > I could have sworn that we were special-casing the
required-validator; I
> > > > > even looked at the code in the old
> > > > > corporate repository, but this bug exists there.
> > > > > --arjuna
> > > > >
> > > > >
> > > > > On 10/13/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > please take a look at MYFACES-1467 which is also trure for
> > > > > > UIXEditableValue.java's validate() method.
> > > > > >
> > > > > > But the spec javadoc for validate() says:
> > > > > > Retrieve the submitted value with getSubmittedValue(). If this
returns
> > > > > > null, exit without further processing. (This indicates that no value
> > > > > > was submitted for this component.)
> > > > > >
> > > > > > the patch is basicly doing this instead:
> > > > > >
> > > > > > Object submittedValue = getSubmittedValue();
> > > > > > if (submittedValue == null && !this.isRequired()) return;
> > > > > >
> > > > > > (it add's the && !this.isRequired())
> > > > > >
> > > > > >
> > > > > > Why?
> > > > > > See the descr. for the issue, since a man-in-the-middle tool can do
> > > > > > some funny things. I saw David's demo this afternoon in ApacheCon
> > > > > > Hackaton.
> > > > > >
> > > > > > I think the javadoc for jsf 1.1 and 1.2 should be changed...
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > -Matt
> > > > > > --
> > > > > > Matthias Wessendorf
> > > > > > http://tinyurl.com/fmywh
> > > > > >
> > > > > > further stuff:
> > > > > > blog: http://jroller.com/page/mwessendorf
> > > > > > mail: mwessendorf-at-gmail-dot-com
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > > http://tinyurl.com/fmywh
> > > >
> > > > further stuff:
> > > > blog: http://jroller.com/page/mwessendorf
> > > > mail: mwessendorf-at-gmail-dot-com
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
