I have another possible solution for this validation problem. It
involves going back to your original answer where you suggested the
Process Validations phase as the logical place for this type of
activity to occur.
My main problem was access to other components so I could see their
submitted value. As I mentioned I am not thrilled with relying on the
structure of the component tree in my validation logic, yet I really
need access to these components. I started thinking about the binding
attribute but that limits you to binding a single pair of components
only.
My idea is to create a custom component that would extend UIInput but
not generate any HTML when rendered. This component could hold
references to a Map of components that would bind to it using the
binding attribute. That way you could write validators for this
"binding component" and have access to all of the components you need.
I haven't figured out the details (such as how the components would
be keyed) but its a different approach that might yield something
interesting.
What do you think?
sean
On 8/8/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > I'm sure this is obvious to you :-), but to help the rest of us out
> > ... can you provide a concise statement of what this method would be
> > used for? Let's assume we use the name check() or whatever you want
> > ... what would the Javadocs say?
>
> This method allows for the option to perform complex validations
> and/or the enforcement of specialized business logic. Since the
> method is called after Update Model phase, this allows the checking of
> components based on values of backing beans instead of requiring the
> programmer to look them up through the component tree. Since this
> will occur after the Update Model phase, it is understood that any
> data changes to the backing beans will not be rolled back as they
> would during the Process Validations phase. If this behavior is
> desired, it is up to the programmer to provide this logic.
>
> > The reason for my hesitation is I want to be *extremely* conservative
> > about expanding the scope (and therefore complexity) of the overall
> > interface. Yes, it's only one method ... but can you do what you want
> > without it? [In this case, all the use cases I can think of are
> > easily handled by adding a line of code to the beginning of your
> > action methods] Would the change tempt the user into bad design
> > choices? [My gut says there is something here to be concerned about
> > -- see below.]
>
> No objection to your conservative approach. I agree that
> ViewController should not degenerate into a collection of countless
> specialized methods. If we can't agree that this is a common problem
> that is not well handled by existing means, then it shouldn't go in.
> No argument there.
>
> > OK, now we both know how we *feel* about it :-). Can you articulate
> > *why* you feel that way?
>
> To me it feels like what I am asking for is a new step in the
> lifecycle. Its something I would like to have applied to all of my
> dialogs. It seems a little indirect to initiate a new "phase" from
> inside another one. Invoke Application phase is concerning itself
> with handling a specific user request to perform an action. *Before*
> I reach this point, I want to make sure the data is well formed, etc.
>
> > Here's my response to that question. To me, checking business rules
> > (the primary use case you described) in such a method is problematic,
> > because the type of checking you do will be dependent on which action
> > method is going to be invoked anyway -- you certainly do want to check
> > them on a "Save", but what's the point on a "Cancel"? Are there use
> > cases for wanting to universally check things *without* knowing which
> > action method is going to be invoked?
>
> I don't think this is an issue. I was envisioning the new phase to be
> called after Update Model. If you have a "cancel" command you would
> just use "immediate=true" so this phase would be skipped.
>
> > The reason for the latter constraint is that I would want the
> > signature of this method, if accepted, to be the same as all the rest,
> > taking no arguments. If you need more state information than just
> > being able to call FacesContext.getCurrentInstance(), that is a danger
> > sign that this is not a uninversal design pattern; instead it is an
> > action-specific behavior that, since JSF provides nice callbacks for
> > action methods already, should be encapsulated there instead of being
> > separated.
>
> 100% agree with your intentions of keeping the method signatures as no
> argument methods. I think my previous answer makes this a non issue.
>
> > Wouldn't a PhaseListener approach to this still require knowing which
> > action will be invoked later?
>
> Again see previous answer.
>
> > The API for validators was specifically designed so that you would
> > focus on "the" value of "the" component that is passed in. That being
> > said, you should be able to implement an "is the value for field A
> > less than the value for field B" sorts of validators -- so you can
> > navigate the component tree if you need to.
> >
> > But, think about the contracts involved. The reason Process
> > Validations is a separate phase is to make clear what a validator can
> > assume:
> >
> > * You can assume that *all* of the submittedValue properties
> > have been set.
> >
> > * You can assume that *none* of the conversions and updates
> > performed by Update Model Values have been performed.
> >
> > Therefore, accessing the component tree is perfectly safe -- as long
> > as you remember that the only useful thing to look at is submitted
> > values.
>
> IMO its more dangerous to rely on knowledge of the component tree then
> it is to rely on indirect communication via backing beans. While
> accessing the component tree may be safe from a data standpoint, if
> you make changes to your component tree (such as changing the name of
> the form or nesting the component inside of a new component like a
> table) your code will break.
>
> So if you treat the backing beans similar to forms in Struts, you can
> "pass them around" by referring to them in different "check" methods.
> This isn't how I normally would use backing beans but in the case of
> dialogs, I use the #{dialog.data} bean in this manner. Its a catch
> all bean designed to be used by multiple dialog steps so why not? Its
> also bound to each of the components that I want to "cross validate"
> so it seems superior to accessing the tree.
>
> I will defer to your framework expertise if you don't want to add a
> new method to ViewController, but I'm still interested in hearing your
> thoughts on this last point.
>
> > Craig
>
> sean
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
