By the way, an interesting side effect of this is if you pass literal
constant to parameter value and try to modify the param value from
somewhere you'll see runtime error saying that parameter binding is read
only. Which is true, because you can't change the value of constant literal:
Page.tml
<t:component param="literal:Hello World" />
Component.java
public class Component {
@Parameter
private String param;
@OnEvent("CustomEvent")
public void onCustomEvent(String newValueFromEvent) {
param = newValueFromEvent; // Exception, because "literal:Hello
World" means a constant String value
}
}
On Fri, Dec 6, 2013 at 6:07 PM, Dmitry Gusev <dmitry.gu...@gmail.com> wrote:
> 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
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
