Em Fri, 11 Sep 2009 23:11:59 -0300, Kalle Korhonen
<kalle.o.korho...@gmail.com> escreveu:
Interesting - I happen to think it's a great pattern to follow. You
try to save and then roll back if it didn't work out - that's what the
transaction management is for and Tapestry gives you a very nice way
to accomplish this easily.
I think onValidate() is for validation, the data store should only be
changed (or attepted to be changed) when validation succeeds and
controller classes (business rules tier) should deal with transactions,
not Tapestry-related code (nor any UI code). I write code following the
three-tiers architecture and the separation of concerns philosphy strictly.
If you only save in onSuccess you have to
decide yourself whether you want to commit or abort,especially if
multiple objects are involved and can't easily communicate back to the
user what the error was (if he was trying to submit a form). How would
you do this?
My approach is to write code to check any consistence error before sending
data to the store. This way, the only errors left are not recoverable (not
related to business logic)and a generic error message is shown. I love
checks buit int the database, but I don't use them to do validation, just
to make sure no inconsistent data is written.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
