Geoff, I think your code is great for **ONE** edit-page.
Our project is looking for a web flow from T5, like the Spring one.
Do you have any idea about it?
Howard mentioned he may add this feature in the next release.
Might be a little late to us, but I am expecting to see it.
Cheers,
Jeffrey Ai
Geoff Callender-2 wrote:
>
> Hi,
>
> In search of best practice for an "edit" page, here's my 3rd attempt.
> It's looking pretty clean-cut to me, but I'm looking for suggestions
> on how to improve it further.
>
> private Long _personId;
>
> @Persist("client")
> // Persistence is needed here because this is a detached Entity
> Bean. When we call the service to
> // accept our changes, it will need its id and version fields intact
> to be able to do optimistic
> // locking check and a successful merge. "client" is used so that
> even if you use the Back button
> // to get to this page, we will have the right Person object.
> private Person _person;
>
> void onActivate(Long id) throws Exception { _personId = id; }
>
> Long onPassivate() { return _person.getId(); }
>
> void setupRender() throws Exception {
> if (!_form.getHasErrors()) {
> _person = getPersonService().findPerson(_personId);
> }
> }
>
> void onValidate() throws Exception {
> if (...a bit of validation logic detects an error...) {
> _form.recordError(...);
> }
> }
>
> Object onSuccess() {
> try {
> getPersonService().changePerson(_person);
> _nextPage.onActivate(_personId);
> return _nextPage;
> }
> catch (Exception e) {
> _form.recordError(ExceptionUtil.getRootCause(e));
> return null;
> }
> }
>
> void cleanupRender() {
> _form.clearErrors();
> }
>
> Some notes:
>
> 1. Detached object - Person is a detached entity. I am deliberately
> avoiding refreshing it every time in setupRender() because a) it would
> overwrite the user's changes, and b) it would defeat optimistic
> locking: if someone else has changed the object then I DO want
> getPersonService().changePerson(_person) to reject the transaction
> when Save is pressed.
>
> 2. Thread-safety - I'm using "client" persistence to avoid the whole
> thread-safety issue caused by the user opening a new window or tabs in
> same browser (T5 can't tell them apart so they share the same
> HttpSession).
>
> 3. onPrepareFromForm() - I'm avoiding it because it gets called too
> often (something to do with "rewind"?). setupRender() seems better
> for the job. Any downside t this?
>
> 4. cleanupRender() - if/when 5.0.7 uses flash persistence on the
> form's ValidationTracker then I'll ditch this method.
>
> Suggestions please!
>
> Thanks,
>
> Geoff
>
>
>
--
View this message in context:
http://www.nabble.com/T5%3A-Edit-page-best-practice---Mk-III-tp14249141p14279495.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
