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
