Hi,
Thanks for pointing this out Dmitry.
Yes I have bound my child components parameters to a PersistConstants.FLASH
property in the containing parent component! This of course explains why it is
lost after subsequent use. I'm not sure what to do about that if persisting
into session is bad practice, but for now I have just changed them to
PersistConstants.CLIENT. This really makes my requests messy though, but it
works. :(
John
----- Original Message -----
From: Dmitry Gusev
To: Tapestry users
Sent: Friday, December 06, 2013 2:07 PM
Subject: Re: component paramter frustrations
I don't think you understand that tapestry parameters are actually
bindings, which means they don't store any values at all -- the value if
stored on the referencing side. See this example:
Page.tml
<t:component param="value" />
Page.java
public class Page {
@Property
private String value;
}
Component.java
public class Component {
@Parameter
private String param;
}
Here in component if you read something from Component#param you will
actually read it from Page#value. This is implemented the way that when
tapestry transforms your component it replaces field declaration with
method call, when you read Component#param -- a generated getter method
will be executed that will read bounded value from Page#value, assigning
value to Component#param in your code will actually invoke generated setter
method that will write assigned value to Page#value.
So if you put @Persist annotation to your Page#value this will keep your
value persisted across requests.
On Mon, Dec 2, 2013 at 3:21 PM, John <j...@quivinco.com> wrote:
> my grumble is having to define 2 members for a single value:
>
> @Parameter
> private Integer workIdParm;
> @Parameter
> private Integer venueIdParm;
> @Parameter
> private Integer reservationIdParm;
>
> @Property
> private Integer vendorId;
> @Persist
> private Integer workId;
> @Persist
> private Integer venueId;
>
> and then I'm doing this:
>
> @SetupRender
> void setup() throws Exception {
> if (workIdParm != null) {
> workId = workIdParm;
> }
> if (reservationIdParm != null) {
> reservationId = reservationIdParm;
> }
> if (venueIdParm != null) {
> venueId = venueIdParm;
> }
>
> Is there something neater than doing this? Like maybe capturing those
> initial parameter values with a constructor like method?
>
> ----- Original Message -----
> From: Thiago H de Paula Figueiredo
> To: Tapestry users
> Sent: Monday, December 02, 2013 11:00 AM
> Subject: Re: component paramter frustrations
>
>
> On Mon, 02 Dec 2013 07:21:27 -0200, John <j...@quivinco.com> wrote:
>
> > Hi,
>
> Hi!
>
> > I pass parameters to some of my componenets but they don't persist by
> > default
>
> And that's a very good thing. The less state you keep in memory, the
> better. You are the one who knows what should be persisted and what
> shouldn't. Actually, almost 100% of the time it makes no sense to persist
> component parameters exactly because they're being passed from someone
> else to them. If you need to persist something, it's generally in pages
> or
> services (through ApplicationStateManager).
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
> Help me spend a whole month working on Tapestry bug fixes and
> improvements: http://igg.me/at/t5month
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
