Hi Kalle,
The key to it is this snippet: "if the stuff you are setting up is not
needed for component event requests, consider putting it elsewhere".
If I understand your example correctly, the object you are creating IS
needed for a component event request so DO put it in onActivate(...).
For example, from JumpStart's UserCreate.java:
void onActivate() {
// Instantiate a User for the page data to overlay.
_user = new User();
_user.setActive(true);
}
Edit follows the same principal. From UserEdit.java:
Long onPassivate() {
return _userId;
}
void onActivate(Long id) {
_userId = id;
try {
_user = getSecurityFinderService().findUser(_userId);
}
catch (DoesNotExistException e) {
// Handle null user in the template
}
}
void setupRender() {
_userRoles =
getSecurityFinderService().findUserRolesShallowishByUser(_userId);
}
But with edit, if you want optimistic locking then you have to include
the entity's version attribute in the form:
<form t:type="form" t:id="form">
<!-- Include version in the form to prevent it being updated/
refreshed in onActivate(),
which would defeat optimistic locking. -->
<t:hidden t:id="version" value="user.version"/>
...
in which case if you submit, press Back, then submit, you'll get an
exception thrown by the persistence mechanism about optimistic locking
- it tells us that the User has changed since the page was first
displayed. It's correct, and all you do is hit refresh and try again.
If you don't want optimistic locking then don't put the entity's
version attribute in the form.
How does that sound?
Cheers,
Geoff
On 02/09/2009, at 4:03 PM, Kalle Korhonen wrote:
On Tue, Sep 1, 2009 at 9:50 PM, Geoff
Callender<geoff.callender.jumpst...@gmail.com> wrote:
Good question. Yes, it does still seem to me to be best practice
and no, I
don't see it breaking the back button. Can you give an example?
Assuming you use something else than session or client persistence and
you initialize (create) an object, set it as a value of some page
property in your setupRender(), then submit the form, press the back
button and re-submit the formit, the object will be null (because it
was initialized in setupRender() that was never invoked rather than
onActivate()).
Kalle
On 01/09/2009, at 8:37 AM, Kalle Korhonen wrote:
Hey Geoff,
I recall reading at some point that you had recommended not using
onActivate() for all initialization purposes, and sure enough, I dug
it up and at
http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/navigation/onactivateandonpassivate/3
you say "It can be tempting to put lots of setup code into
onActivate(...). However, if the stuff you are setting up is not
needed for component event requests, consider putting it elsewhere,
such as setupRender() or getter methods."
Does that still reflect your current understanding of the best
practices? The caveat with using setupRender() (or anything else
except for onActivate()) is that even for non-ajax applications, it
"breaks the back button", i.e. if a user goes back in history and
say
re-submits a form (for one reason or another) the objects required
by
the page/form are not initialized. Obviously it depends on the case
what the application should do, but you loose half the benefits of
redirect-after-post if your require a refresh before a page is
usable
again. Do you simple prefer rendering an an error in the back
button/direct form submit case or do you generally do all
initialization in onActivate()?
Kalle
On Tue, Aug 4, 2009 at 7:59 PM, Geoff
Callender<geoff.callender.jumpst...@gmail.com> wrote:
Hi all,
JumpStart 4.4 is now available. It's a tidying up release: the
structure's
a bit neater and it uses the latest OpenEJB, ie. 3.1.1.
Use it live:
http://jumpstart.doublenegative.com.au:8080/jumpstart/
or download it:
http://jumpstart.doublenegative.com.au
And if someone can figure how to get Jetty/OpenEJB in Eclipse to
use the
libs and classes in the WAR instead of having to be spoon-fed a
classpath,
then please let me know. I suspect it's a class-loading issue
that might
soon be solved by http://code.google.com/p/embed-openejb-in-eclipse/
.
Cheers,
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
