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

Reply via email to