Hi all, I was chatting with Alex Smirnov this week, and he pointed out that an essential feature needed for Ajax validation is missing from the Ajax support in JSF 2.0. When you are doing Ajax validation, you need an option to not update the backing beans (in other words, skip the update model phase), so that *if the value is valid*, then aren't saved to the model. I think this is sufficiently important enough to go into the JSF maintenance release. The RichFaces syntax is like: <f:ajax updateModel="false" /> BTW, Ed, any updates on the MR? Pete

Pete, Alex - Can you elaborate on the consequences of running through the update model phase during Ajax validation? Is the concern that this is just unnecessary overhead (ie. is this a performance issue)? Or are there other functional issues that come up? FWIW, we haven't added such a facility for skipping update model in Trinidad/ADF Faces Ajax. Perhaps we haven't needed this because we primarily rely on client-side validation for quick feedback (though of course there are cases that client-side validation does not cover.) Ted - Just curious - does ICEfaces provide a mechanism for skipping update model during Ajax validation? Andy Pete Muir wrote: > Hi all, > > I was chatting with Alex Smirnov this week, and he pointed out that > an essential feature needed for Ajax validation is missing from the > Ajax support in JSF 2.0. > > When you are doing Ajax validation, you need an option to not > update the backing beans (in other words, skip the update model > phase), so that *if the value is valid*, then aren't saved to the > model. I think this is sufficiently important enough to go into the > JSF maintenance release. The RichFaces syntax is like: > > <f:ajax updateModel="false" /> > > BTW, Ed, any updates on the MR? > > Pete

Thanks Pete - Pete Muir wrote: > The issue is that it isn't always (normally IMO) the case that you > want the model update on an ajax request to do validation, you only > want the model updated when you actually hit submit... This is a > problem if you are applying values directly to the managed JPA > entities which get flushed to the database at the end of the TX. > What are the consequences of applying a validated value to a managed entity early - ie. during Ajax validation, as opposed to waiting until the full submit? Is there some overhead here that you want to avoid? Presumably the value is not being flushed to the database immediately (as you said, this won't happen until the end of the TX),

On Mon, Jun 22, 2009 at 2:32 PM, Andy Schwartz <andy.schwartz(a)oracle.com > wrote: Andy Schwartz wrote: Thanks Pete - Pete Muir wrote: The issue is that it isn't always (normally IMO) the case that you want the model update on an ajax request to do validation, you only want the model updated when you actually hit submit... This is a problem if you are applying values directly to the managed JPA entities which get flushed to the database at the end of the TX. What are the consequences of applying a validated value to a managed entity early - ie. during Ajax validation, as opposed to waiting until the full submit? Is there some overhead here that you want to avoid? Presumably the value is not being flushed to the database immediately (as you said, this won't happen until the end of the TX), Oh, actually... So is the deal that your are committing the TX in response to the Ajax validation, and thus the value is actually being flushed to the database immediately? That's correct. The flush (i.e., database update) is avoidable by sidestepping a transaction or using a JPA vendor extension such a Hibernate's manual flushing, but the concern is that it is too easy for a developer to inadvertently cause a database update by adding Ajax w/o changing backend code. The whole "skip the update model" aspect of validation is really worth debating in a separate thread. The counter argument to using it is that cross-field validation becomes very awkward because you have to retrieve the converted value from the component rather than from the model property (throwing a wrench in more advanced Bean Validation usage as well). But let's venture down that discussion in a separate thread. As far as I know, ICEfaces does not support the "bypass model update" when using partial submit. I've discussed this with Ted, but I don't thing anything ever came of it. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

On Mon, Jun 22, 2009 at 2:32 PM, Andy Schwartz <andy.schwartz(a)oracle.com > wrote: Andy Schwartz wrote: Thanks Pete - Pete Muir wrote: The issue is that it isn't always (normally IMO) the case that you want the model update on an ajax request to do validation, you only want the model updated when you actually hit submit... This is a problem if you are applying values directly to the managed JPA entities which get flushed to the database at the end of the TX. What are the consequences of applying a validated value to a managed entity early - ie. during Ajax validation, as opposed to waiting until the full submit? Is there some overhead here that you want to avoid? Presumably the value is not being flushed to the database immediately (as you said, this won't happen until the end of the TX), Oh, actually... So is the deal that your are committing the TX in response to the Ajax validation, and thus the value is actually being flushed to the database immediately? That's correct. The flush (i.e., database update) is avoidable by sidestepping a transaction or using a JPA vendor extension such a Hibernate's manual flushing, but the concern is that it is too easy for a developer to inadvertently cause a database update by adding Ajax w/o changing backend code.

The whole "skip the update model" aspect of validation is really worth debating in a separate thread. The counter argument to using it is that cross-field validation becomes very awkward because you have to retrieve the converted value from the component rather than from the model property (throwing a wrench in more advanced Bean Validation usage as well). But let's venture down that discussion in a separate thread.

As far as I know, ICEfaces does not support the "bypass model update" when using partial submit. I've discussed this with Ted, but I don't thing anything ever came of it. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.