AjaxFormLoop: Should it really depend on persistent source?

[Ognen Ivanovski <og...@netcetera.com.mk>]

Hi people,

I was playing around with the AjaxFormLoop component and I must admit  
I don't think that it plays well with editing Entities and the  
onActivate() / onPassivate() pattern.

Ideally, when you are editing an entity you rely on onActivate() /  
onPassivate() to setup the page and the entity being edited. It  
doesn't actually matter how many times the user will submit the form  
(validation errors can happen) - the data the user entered will be  
kept around in the ValidationTracker. You just mark the onSuccess()  
with @CommitAfter and you are good to go.

Enter, AjaxFormLoop. It requires a @Persist-ent source (collection) to  
operate. It also requires that you add or remove items from the  
collection when the appropriate event.

The bad thing is that these events come independently of the form as a  
whole. Yes, they are AJAX based events, but, in my view, the  
AjaxFormLoop comes as an enhancement of the classic form and should  
not modify one of its core behaviors - all of the form is submitted in  
a single request.

Here's an example: there is an entity class Person. It has a  
List<PhoneNumber> inside. When I'm editing a Person, I'd like to have  
it as a single form where, I can add, remove or change phone numbers  
as I please. BUT, I (as a user) would expect that the changes I do on  
such a form (even the addition of phone numbers) would take place when  
i press Submit, not before. Also, when I walk away from the from  
nothing should happen.

Probably, there is a way to achieve this by making the phone number  
list @Persist-ent but this *really* complicates the otherwise quite  
elegant pattern mentioned above (when does a new edit start?; what if  
there are updates from the db?; when do I clear the persistent data?;  
etc, etc...)


I think that the AjaxFormLoop should not require that the source is  
persistent. Rather, it should require some kind of "blanks" creator  
(parameter or event) which creates "blank" objects that will be used  
to render the new rows". the "addRow" and "remove" events should be  
delivered *together* with the rest of the form.

In other other words, the workflow for row addition should look  
something like:

  -> form rendered for the first time
  -> user presses 'add phone number'
  -> ajax request sent back
  -> ajax form loop asks BlankCreator to create a blank phone number  
object (explicitly documented that this one will be thrown away)
  -> FormInjector renders new row with blank object
  -> AjaxFormLoop stores information "newRow" in response, instead of id
  -> response sent back
  -> user submits form
  -> form processing as normal
  -> "newRow" information deserialized from form
  -> blanks creator used to create new blank object
  -> object used as value for the this iteration
  -> event "addRow" with ready made and populated object sent to  
container
  -> etc...

What do you think? This way the form is extended as pleased, can be  
submitted as much times as the user likes to make errors, changes  
commited only once (onSuccess()) and there is no need for persistent  
source for the AjaxFormLoop?

Ognen

P.S. I might also missing an elephant in the room ;)



--
Ognen Ivanovski | ognen.ivanovski@netcetera.com.mk
phone +389 -2- 30 64 532 | fax +389 -2- 30 79 495
Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org