Hi Lasitha, I use same approach as well, don't persist, persist(flash) if you have to inject that page and setup some value.
This does bring up another issue, easy if the page involves only one person, you can look it up again, how about a complicated document? maybe a certain streaming mechanism to save the entire temporary object and retrieve it later by an ID in the onActivate event? persist back to the data store in onSuccess? that seems easier to handle than T5's @Persist? then again maybe T5's persist is actually doing the same thing? It might solve the Tapestry-Hibernate's related issue of not able to roll back changes, if the setters update only a temporary object, and this object will be used to set the object in the data store in onSuccess, Tapestry-hibernate might work as expected? comments? A.C. lasitha wrote: > > > Ok, so it seems most of my comments boil down to: don't persist, and > use flash/client strategies if you must :) > > Let me throw something else in to break the monotony: you can > eliminate the conditional in onSuccess() by defining an onValidate() > handler. If onValidate() records errors, tapestry will know not to > call onSuccess(). > > Ok, hope that helps some. > Cheers, lasitha. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/T5%3A-Edit-page-best-practice--tf4874654.html#a13962080 Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
