[jsr-314-open] Ajax validation

[Ted Goddard]

ICEfaces doesn't alter the lifecycle from the point of view of
validation -- our purpose there was to make Ajax development and
non-Ajax development as similar as possible.  The submit action is
where we typically recommend putting the database commit.

During partial submit, ICEfaces disables the required status on all
but the "active" component to allow the user to progressively fill
out a form without being chastised for empty fields they haven't
visited yet.  (We would like to enhance this feature to keep track
of visited fields so that empty field warnings would remain during
field navigation.)

Ted.


On 22-Jun-09, at 12:51 PM, Dan Allen wrote:

> On Mon, Jun 22, 2009 at 2:32 PM, Andy Schwartz <andy.schwartz at 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.