On 8/8/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > [Sorry I replied to the user's list by mistake. This is a repost to > the dev list.] > > Craig, > > I have been thinking about this issue some more and I have some > additional thoughts in response to your comments. > > I definitely like the idea of a new method in ViewController. I > wouldn't call it validate though, perhaps "check" or something else > that won't be confused with the validation phase.
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? 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.] > I don't really like the idea of calling this check method from an > action handler. This is what we had been doing before I posted the > original message but it doesn't sit well with me. It seems like this > is an abuse of the action handler phase. Conceptually this is more > like a new phase so I like your suggestion of a new phase listener > better. OK, now we both know how we *feel* about it :-). Can you articulate *why* you feel that way? 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? 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. > > I'd like for you to consider adding something like this to the Shale > interface. I think it would be helpful to people who are frustrated > with the limitations of the existing validation phase. I'd rather try > and establish a common methodology that us JSF/Shale developers could > use rather than implement my own custom PhaseListener. > Wouldn't a PhaseListener approach to this still require knowing which action will be invoked later? > IMO consulting the JSF component tree during the validation phase is > dangerous. This requires an extra level of "hard-coding" (the > relative position of your component in the tree) in addition to the > component name. In my case (and I suspect in the case of many other > users) the data is not updated in the database until the > InvokeApplication phase. So the fact that the data cannot be rolled > back is not a problem. I just want to kick the dialog screen back to > the user and ask them to try again. In other scenarios, I just want > to update a backing bean value that's tied to a hidden field without > having to look up the hidden field. > > What do you think? > 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. > sean Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
