Re: T5: Strategy for pages that edit beans
I have encountered a similar issue, and the use of onPrepare() doesn't make
sense to me. Surely there's no point persisting any fields and then
resetting in onPrepare() is there? May as well just remove the @Persist.
There must be something I'm missing here.. can anyone fill me in?
Howard Lewis Ship wrote:
How about an onPrepare() event handler method to reset the _user field
to a new User instance?
On Jan 18, 2008 8:44 AM, Hugo Palma [EMAIL PROTECTED] wrote:
Imagine the following use case:
A page to register a new user. I have a User class so i'm all set.
The page class looks something like:
@Meta(tapestry.persistence-strategy=flash) // because of the
validation tracker thing
public class Register {
@Persist
private User _user = new User();
public User getUser() {
return _user;
}
public void setUser(User user) {
_user = user;
}
}
I'm not using the BeanEditForm component so my template just has a
couple of TextField components with it's value binded to the user bean
properties.
So, now the problem. Because of the way property persistence works, the
actual reference to the user property is kept, so instead of the
property being reset to a brand new instance it's given the kept
reference.
This means that every time that i navigate to the register page the form
will have the values from the last time the form was submitted.
I guess a workaround would be on every place where i navigate to this
page, to reset the user property before navigating to it. This isn't a
very good solution design wise and doesn't solve the problem when
someone accesses the page directly from it's url.
So, how are you guys implementing such use case ?
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/T5%3A-Strategy-for-pages-that-edit-beans-tp14957154p16467445.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]
Re: T5: Strategy for pages that edit beans
What about calling discardPersistentFieldChanges onCleanupRender? http://tapestry.apache.org/tapestry5/tapestry-core/guide/persist.html Clearing Persistent Fields If you reach a point where you know that all data for a page can be discarded, you can do exactly that. The method discardPersistentFieldChanges() of ComponentResources will discard all persistent fields for the page, regardless of which strategy is used to store the property. This will not affect the page in memory, but takes effect for subsequent requests. -- View this message in context: http://www.nabble.com/T5%3A-Strategy-for-pages-that-edit-beans-tp14957154p16467529.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]
Re: T5: Strategy for pages that edit beans
Hugo,
Your UserPage.tml/UserPage.java is the view and your User POJO the model,
right ?
The way I see the probem is who ever (eg UserListPage, Register Link) needs
to use the UserPage needs to pass in te POJO, otherwise the UserPage wont
know what to display.
What are the UseCases that you need to navigate to the UserPage
1. Register a new User (Use ActionLink and set a new User() in the
onActionFromRegisterUser() method)
2. View an existing User (Use ActionLink and set the User in the
onActionFromViewUser() method)
3. Edit an existing User (Use ActionLink and set the User in the
onActionFromEditUser() method)
You can also do all the above by passing the userId in the context of the
ActionLink and then retrieve him from the persistency layer in the
onActivate() method of your UserPage.
The question I have is, why would you want to reset the User if you are
going to be setting a new one or an existing one anyway ?
Petros
HugoPalma wrote:
Imagine the following use case:
A page to register a new user. I have a User class so i'm all set.
The page class looks something like:
@Meta(tapestry.persistence-strategy=flash) // because of the
validation tracker thing
public class Register {
@Persist
private User _user = new User();
public User getUser() {
return _user;
}
public void setUser(User user) {
_user = user;
}
}
I'm not using the BeanEditForm component so my template just has a
couple of TextField components with it's value binded to the user bean
properties.
So, now the problem. Because of the way property persistence works, the
actual reference to the user property is kept, so instead of the
property being reset to a brand new instance it's given the kept
reference.
This means that every time that i navigate to the register page the form
will have the values from the last time the form was submitted.
I guess a workaround would be on every place where i navigate to this
page, to reset the user property before navigating to it. This isn't a
very good solution design wise and doesn't solve the problem when
someone accesses the page directly from it's url.
So, how are you guys implementing such use case ?
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/T5%3A-Strategy-for-pages-that-edit-beans-tp14957154p16476114.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]
Re: T5: Strategy for pages that edit beans
Cool, i didn't even know about that particular event.
I just found that it's explained in the Input Validation section of
the docs.
Just thinking out loud, but wouldn't it be great if all the
notifications a component can send were documented with the component
documentation itself ?
Maybe some javadoc markup could be used to document the notifications in
the component class itself and then the reference doc generator could
pick those up ?
Howard Lewis Ship wrote:
How about an onPrepare() event handler method to reset the _user field
to a new User instance?
On Jan 18, 2008 8:44 AM, Hugo Palma [EMAIL PROTECTED] wrote:
Imagine the following use case:
A page to register a new user. I have a User class so i'm all set.
The page class looks something like:
@Meta(tapestry.persistence-strategy=flash) // because of the
validation tracker thing
public class Register {
@Persist
private User _user = new User();
public User getUser() {
return _user;
}
public void setUser(User user) {
_user = user;
}
}
I'm not using the BeanEditForm component so my template just has a
couple of TextField components with it's value binded to the user bean
properties.
So, now the problem. Because of the way property persistence works, the
actual reference to the user property is kept, so instead of the
property being reset to a brand new instance it's given the kept reference.
This means that every time that i navigate to the register page the form
will have the values from the last time the form was submitted.
I guess a workaround would be on every place where i navigate to this
page, to reset the user property before navigating to it. This isn't a
very good solution design wise and doesn't solve the problem when
someone accesses the page directly from it's url.
So, how are you guys implementing such use case ?
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Strategy for pages that edit beans
How about an onPrepare() event handler method to reset the _user field
to a new User instance?
On Jan 18, 2008 8:44 AM, Hugo Palma [EMAIL PROTECTED] wrote:
Imagine the following use case:
A page to register a new user. I have a User class so i'm all set.
The page class looks something like:
@Meta(tapestry.persistence-strategy=flash) // because of the
validation tracker thing
public class Register {
@Persist
private User _user = new User();
public User getUser() {
return _user;
}
public void setUser(User user) {
_user = user;
}
}
I'm not using the BeanEditForm component so my template just has a
couple of TextField components with it's value binded to the user bean
properties.
So, now the problem. Because of the way property persistence works, the
actual reference to the user property is kept, so instead of the
property being reset to a brand new instance it's given the kept reference.
This means that every time that i navigate to the register page the form
will have the values from the last time the form was submitted.
I guess a workaround would be on every place where i navigate to this
page, to reset the user property before navigating to it. This isn't a
very good solution design wise and doesn't solve the problem when
someone accesses the page directly from it's url.
So, how are you guys implementing such use case ?
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
