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 | [EMAIL PROTECTED]
phone +389 -2- 30 64 532 | fax +389 -2- 30 79 495
Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
