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]
