You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@tapestry.apache.org by Geoff Callender <ge...@gmail.com> on 2008/01/28 13:46:10 UTC

Re: T5: Edit page best practice - Mk III - now Mk V

Here's Mark V of the single page edit.  In previous attempts I was  
clinging onto client-side persistence of the entity to ensure  
optimistic locking, and then "the penny finally dropped" - all you  
need to ensure optimistic locking is to ensure the entity's version is  
retained - and you can do that with a hidden field.  So client-side  
persistence really isn't necessary.  Hallelujah!

	private Long _personId;

	private Person _person;

	void onActivate(Long id) throws Exception {
		_personId = id;
		_person = getPersonService().findPerson(_personId);
	}

	Long onPassivate() {
		return _personId;
	}

	void onValidateFromForm() {
		if (...a bit of validation logic detects an error...) {
			_form.recordError(...);
			return;
		}
		try {
			// move this back to onSuccess() once TAPESTRY-1972 has been  
resolved.
			getPersonService().changePerson(_person);
		}
		catch (Exception e) {
			_form.recordError(ExceptionUtil.getRootCause(e));
		}
	}

	Object onSuccess() {
		_nextPage.onActivate(_personId);
		return _nextPage;
	}

	void cleanupRender() {
		_form.clearErrors();
	}

and in the html form, use the Hidden component that's been discussed  
in this mailing list:

  		<t:hidden t:id="version" value="person.version"/>

or if you're using BeanEditForm:

	<t:beaneditform t:id="form" object="person" submitLabel="Save">
		<t:parameter name="version">
			<t:hidden t:id="version" value="person.version"/>
		</t:parameter>
	</t:beaneditform>

Yes, onActivate(...) is called twice if there's an error detected  
server-side, but that's due to the redirect-after-post paradigm, so  
it's a cost with a pretty big benefit.

One last note, the cleanupRender() method can be removed if T5 moves  
to "flash" persistence on the form's ValidationTracker.

Anything I've missed?

Cheers,

Geoff

On 12/12/2007, at 7:39 AM, Geoff Callender wrote:

> I'm planning on doing one, but not today.  If you know your way  
> around T4 then the web flow example in JumpStart Max 2.0.0 may help  
> you. It's at http://files.doublenegative.com.au/jumpstart/ .
>
> Here's Mk IV of the single page edit.  It seems that recording  
> errors in onSuccess() can cause fields to revert when you redisplay  
> with error, so I've moved some of it to onValidate().   The notes  
> from before are still relevant.
>
> 	private Long _personId;
> 	
> 	// "client" is used so that  even if you use the Back button
> 	// to get to me, I will have the right Person object.
> 	@Persist("client")
> 	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(...);
> 			return;
> 		}
> 		try {
> 			getPersonService().changePerson(_person);
> 		}
> 		catch (Exception e) {
> 			_form.recordError(ExceptionUtil.getRootCause(e));
> 			return;
> 		}
> 	}
> 	
> 	Object onSuccess() {
> 		_nextPage.onActivate(_personId);
> 		return _nextPage;
> 	}
>
> 	void cleanupRender() {
> 		   _form.clearErrors();
> 	}
>
> Cheers,
>
> Geoff
>
> On 12/12/2007, at 4:53 AM, jeffrey ai wrote:
>
>>
>> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>