Re: component paramter frustrations
I see what you mean Lance, yes that would be a neat solution so long as it is performant. John - Original Message - From: Lance Java To: Tapestry users Sent: Saturday, December 07, 2013 10:29 AM Subject: Re: component paramter frustrations Yep, I know. Which is why I suggested a new strategy which still uses the URL but uses the context instead of request parameters. Thus prettying up your url without explicitly requiring you to add extra bits to the context. On 7 Dec 2013 10:13, "John" wrote: > Dmitry helped me identify the root cause of my problem. The parameters > were bound to a FLASH persisted property hence they lost their initial > values after first use. I just made them CLIENT and (appart from the long > client state request payload) that issue is resolved satisfactorily. > > John > - Original Message - > From: Lance Java > To: Tapestry users > Sent: Saturday, December 07, 2013 8:04 AM > Subject: Re: component paramter frustrations > > > Perhaps you could write your own persistance strategy. > > @Persist(MyPersistConstants.EVENT_CONTEXT) > > Which implicitly appends to the actionlink / eventlink context clientside > and updates the fields serverside before delegating to the event. >
Re: component paramter frustrations
Yep, I know. Which is why I suggested a new strategy which still uses the URL but uses the context instead of request parameters. Thus prettying up your url without explicitly requiring you to add extra bits to the context. On 7 Dec 2013 10:13, "John" wrote: > Dmitry helped me identify the root cause of my problem. The parameters > were bound to a FLASH persisted property hence they lost their initial > values after first use. I just made them CLIENT and (appart from the long > client state request payload) that issue is resolved satisfactorily. > > John > - Original Message - > From: Lance Java > To: Tapestry users > Sent: Saturday, December 07, 2013 8:04 AM > Subject: Re: component paramter frustrations > > > Perhaps you could write your own persistance strategy. > > @Persist(MyPersistConstants.EVENT_CONTEXT) > > Which implicitly appends to the actionlink / eventlink context clientside > and updates the fields serverside before delegating to the event. >
Re: component paramter frustrations
Dmitry helped me identify the root cause of my problem. The parameters were bound to a FLASH persisted property hence they lost their initial values after first use. I just made them CLIENT and (appart from the long client state request payload) that issue is resolved satisfactorily. John - Original Message - From: Lance Java To: Tapestry users Sent: Saturday, December 07, 2013 8:04 AM Subject: Re: component paramter frustrations Perhaps you could write your own persistance strategy. @Persist(MyPersistConstants.EVENT_CONTEXT) Which implicitly appends to the actionlink / eventlink context clientside and updates the fields serverside before delegating to the event.
Re: component paramter frustrations
Perhaps you could write your own persistance strategy. @Persist(MyPersistConstants.EVENT_CONTEXT) Which implicitly appends to the actionlink / eventlink context clientside and updates the fields serverside before delegating to the event.
Re: component paramter frustrations
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
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 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 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
Re: component paramter frustrations
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
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 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
>
>
> 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 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 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
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
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 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 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
Re: component paramter frustrations
"what would the value IF the @Parameter be" should be "what would the value OF the @Parameter be" (smartphone typo) On 6 Dec 2013 13:54, "Lance Java" wrote: > Let's consider that your component was being used in a t:loop and that the > current loop value was passed to your component as a @Parameter. > > We know that tapestry's static structure / dynamic behaviour means that > there is only 1 instance of your component (rendered multiple times). So, > what would the value if the @Parameter be in the event? Hopefully this > example shows you why you need to pass the @Parameter's in the event > context. > > If it does not make sense, read it again!! >
Re: component paramter frustrations
Let's consider that your component was being used in a t:loop and that the current loop value was passed to your component as a @Parameter. We know that tapestry's static structure / dynamic behaviour means that there is only 1 instance of your component (rendered multiple times). So, what would the value if the @Parameter be in the event? Hopefully this example shows you why you need to pass the @Parameter's in the event context. If it does not make sense, read it again!!
Re: component paramter frustrations
On Fri, 06 Dec 2013 10:56:32 -0200, John wrote: Hi Lance, Hi! I am resistant to passing these parameters in the t:context to my event handlers because: 1) it is boilerplate stuff and Tapestry is supposed to handle that without me writing code That's very, very, very wrong. See my messages about what component parameters are and where they come from and how they should be used. 2) it clutters my event handlers contract with fields and functions the method is not directly concerned with - this breaks OO seperation of concerns, my event handler will have to concern with persistence Actually, this isn't persistence, is passing the event handler method the information it needs to work. And component parameters shouldn't be persisted. Ever. You seem to forgot that clicking in a link is another request, AJAX or not, so the information the event handler needs isn't in the new request, so you should pass it. 3) if I attempt to avoid cluttering my code to implement persistence as above by using client side properties my code is then cluttered with duplicate member definitions and code to set these duplicates up This solution is really awful, not only to duplicating stuff, but also because component parameters are always supposed to come from whatever uses them. -- 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
Re: component paramter frustrations
On Fri, 06 Dec 2013 11:02:27 -0200, John wrote: Hi, Hi! I am not very CSS savy Thiago, but I think center is code efficient vs the css way? I disagree. HTML is structure, CSS is layout. is something that shouldn't be used anymore. Please see my previous response to Lance as to why I am resisting your suggestions. In short it is not OO, DRY or to the Tapestry ethos. Actually, it is all of them. IMO Tapestry framework should take care of persisting component parameters between requests. Just saying ;) I'm sorry, but I just cannot agree with you in this case. You are the one who knows what should be persisted and shwat shouldn't. And component parameters are always expected to come from whatever is using them. You really didn't get the Tapestry philosophy about it. If Tapestry persisted component parameters, it would subvert completely what I just described and, in addition, would persist lots of stuff that doesn't need persisting at all. -- 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
Re: component paramter frustrations
Hi,
I am not very CSS savy Thiago, but I think center is code efficient vs the css
way?
Please see my previous response to Lance as to why I am resisting your
suggestions. In short it is not OO, DRY or to the Tapestry ethos.
IMO Tapestry framework should take care of persisting component parameters
between requests. Just saying ;)
John
- Original Message -
From: Thiago H de Paula Figueiredo
To: Tapestry users
Sent: Friday, December 06, 2013 11:28 AM
Subject: Re: component paramter frustrations
On Thu, 05 Dec 2013 21:53:44 -0200, John wrote:
> here is the template with the problematic actionlink highlighted
Thanks!
> ${message:text.diarydenied}
I haven't seen the very deprecated HTML tag for many years . . .
I felt like in 1998 when I read it. :P
> t:zone="dateZone" t:parameters="parms" href="#" class="daybarnavl"
The 'parameters' parameter of ActionLink and EventLink doesn't work like
you think. As its documentation says, it adds the map as *query
parameters* (a=b&c=d) in the URL, and this is completely unrelated to
component parameters, which are passed from other components or pages. If
you want to get these values back from query parameters, you must use
@RequestParameter or Request.getParameter() or, better yet, don't use
query parameters and do what Lance said and use the 'context' parameter of
ActionLink and EventLink.
--
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
Re: component paramter frustrations
Hi Lance, I am resistant to passing these parameters in the t:context to my event handlers because: 1) it is boilerplate stuff and Tapestry is supposed to handle that without me writing code 2) it clutters my event handlers contract with fields and functions the method is not directly concerned with - this breaks OO seperation of concerns, my event handler will have to concern with persistence 3) if I attempt to avoid cluttering my code to implement persistence as above by using client side properties my code is then cluttered with duplicate member definitions and code to set these duplicates up 4) @Persists(PersistConstants.CLIENT) produces some nasty URLs and burdens the network with excess bytes Whatever of these approach I take is not OO or DRY and do not seem to follow the Tapestry ethos of eliminating boilerplate coding. I hope that doesn't seem like a criticism of you and your helpful replies, thank you Lance. I will certainly be changing my code to using eventlink and it seems I am burdened with swallowing these parameters by passing them through t:context! John - Original Message - From: Lance Java To: Tapestry users Sent: Friday, December 06, 2013 8:36 AM Subject: Re: component paramter frustrations I've said this many times now. You must pass the parameters in the event context. onActionFromFoo(String param1, Foo param2, Bar param3) BTW: IMHO actionlink is deprecated and shouldn't be used. Use eventlink instead.
Re: component paramter frustrations
On Thu, 05 Dec 2013 21:53:44 -0200, John wrote:
here is the template with the problematic actionlink highlighted
Thanks!
${message:text.diarydenied}
I haven't seen the very deprecated HTML tag for many years . . .
I felt like in 1998 when I read it. :P
t:zone="dateZone" t:parameters="parms" href="#" class="daybarnavl"
The 'parameters' parameter of ActionLink and EventLink doesn't work like
you think. As its documentation says, it adds the map as *query
parameters* (a=b&c=d) in the URL, and this is completely unrelated to
component parameters, which are passed from other components or pages. If
you want to get these values back from query parameters, you must use
@RequestParameter or Request.getParameter() or, better yet, don't use
query parameters and do what Lance said and use the 'context' parameter of
ActionLink and EventLink.
--
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
Re: component paramter frustrations
I've said this many times now. You must pass the parameters in the event context. onActionFromFoo(String param1, Foo param2, Bar param3) BTW: IMHO actionlink is deprecated and shouldn't be used. Use eventlink instead.
Re: component paramter frustrations
here is the template with the problematic actionlink highlighted
http://tapestry.apache.org/schema/tapestry_5_3.xsd";
xmlns:p="tapestry:parameter" xmlns:tx="tapestry-library:tapx">
${message:text.diarydenied}
${name}
${message:text.diaryinstructions}
${message:label.appointmentdate}(${timeZoneName})
${startDateDay}
${startDateNum}
${startDateMon}
${startTimeFmt}
${entryDetails}
${message:text.pickadate}
${message:text.anotherdate}:
${startDateDay}
${startDateNum}
${startDateMon}
${message:text.proposalinstructions}
${message:label.proposal}
${message:text.callininstructions}
${message:label.callintime}
the debug log shows the parameters are passed from the browser, but do not get
to the page class:
components.Diary REQ: reservationIdParm=4
components.Diary REQ: t:ac=admin
components.Diary REQ: t:zoneid=timeZone
components.Diary REQ: venueIdParm=1
components.Diary REQ: workIdParm=2
components.Diary preload:{venueIdParm=null, workIdParm=null,
reservationIdParm=null}
public class Diary {
@Parameter
private Integer workIdParm;
@Parameter
private Integer venueIdParm;
@Parameter
private Integer reservationIdParm;
@Property
private HashMap parms;
private void presetup() {
bookingForm.clearErrors();
parms = new HashMap();
parms.put("workIdParm", workIdParm);
parms.put("venueIdParm", venueIdParm);
parms.put("reservationIdParm", reservationIdParm);
for (String pname : request.getParameterNames()) {
log.debug("REQ: " + pname + "=" + request.getParameter(pname));
}
log.debug("preload:" + parms);
}
void onActionFromTimeClicked(long timeClicked) {
presetup();
startTimex = new Date(timeClicked);
startDatex = new Date((startTimex.getTime() / TimeConstants.MS_DAY) *
TimeConstants.MS_DAY);
log.debug("selected " + new Date(timeClicked) + " " + startDatex);
loadTimes(15);
loadCallInTimes();
ajaxResponseRenderer.addRender(timeZone).addRender(formZone);
}
The page class thows a NPE on subsequent use of the workIdParm.
I'd really like the @Paremeter members to be added to all the client side links
by default, seems like boilerplate code to me.
- Original Message -
From: Thiago H de Paula Figueiredo
To: Tapestry users
Sent: Thursday, December 05, 2013 1:36 PM
Subject: Re: component paramter frustrations
Without the code *and* template we cannot help you. We could only guess
what's happening.
--
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
Re: component paramter frustrations
Without the code *and* template we cannot help you. We could only guess what's happening. -- 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
Re: component paramter frustrations
I am trying to preserve the components parameter values between event
invocations by storing them in a map that gets passed to all my action links
and forms.
I have added t:parameters="parms" to all my action links and see that in
request object the parameters are set. However in the code below the presetup
routine can get null values for the assoicated @Parameter members. On the first
invocation of onActionFromTimeClicked the @Parameter members do get set but on
subsequent invocations they become are null even though teh request passes
values?
When I inspect the links in the browser the parameter values are all there. Why
does the component sometimes not set parameters?
John
public class Diary {
@Parameter
private Integer workIdParm;
@Parameter
private Integer venueIdParm;
@Parameter
private Integer reservationIdParm;
@Property
private HashMap parms;
...
private void presetup() {
bookingForm.clearErrors();
parms = new HashMap();
parms.put("workIdParm", workIdParm);
parms.put("venueIdParm", venueIdParm);
parms.put("reservationIdParm", reservationIdParm);
for (String pname : request.getParameterNames()) {
log.debug("REQ: " + pname + "=" + request.getParameter(pname));
}
log.debug("preload:" + parms);
}
@SetupRender
void setup() throws Exception {
log.debug("setup diary parms=" + workIdParm + "," + venueIdParm + "," +
reservationIdParm);
Reservation reservation = null;
if (reservationIdParm != null) {
reservation = reservationFacade.getReservation(reservationIdParm);
log.debug("load parms from reservation" + workIdParm + "," +
venueIdParm);
}
presetup();
...
}
void onActionFromTimeClicked(long timeClicked) {
presetup();
startTimex = new Date(timeClicked);
startDatex = new Date((startTimex.getTime() / TimeConstants.MS_DAY) *
TimeConstants.MS_DAY);
log.debug("selected " + new Date(timeClicked) + " " + startDatex);
loadTimes(15);
loadCallInTimes();
ajaxResponseRenderer.addRender(timeZone).addRender(formZone);
}
...
}
- Original Message -----
From: Thiago H de Paula Figueiredo
To: Tapestry users
Sent: Monday, December 02, 2013 3:59 PM
Subject: Re: component paramter frustrations
On Mon, 02 Dec 2013 12:14:39 -0200, John wrote:
> Yes that's right, my page is passing some key id values to deeper
> components, but the paramter value is lost after the intitial component
> render. That's my challenge.
How are you updating the page after the initial render? Zone updates?
EventLink? Form? As Lance said, you should use the event context of
EventLink and ActionLink and even Form so you don't miss them.
--
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
Re: component paramter frustrations
On Mon, 02 Dec 2013 12:14:39 -0200, John wrote: Yes that's right, my page is passing some key id values to deeper components, but the paramter value is lost after the intitial component render. That's my challenge. How are you updating the page after the initial render? Zone updates? EventLink? Form? As Lance said, you should use the event context of EventLink and ActionLink and even Form so you don't miss them. -- 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
Re: component paramter frustrations
As I said, you just pass the parameters in the event context of you events.
Re: component paramter frustrations
Yes that's right, my page is passing some key id values to deeper components, but the paramter value is lost after the intitial component render. That's my challenge. Should I rerender my components by bubbling up an event back to the page and then back down rendering the components from scratch? That seems wasteful. Maybe I am missing some fundamental concept of using components or parameters, maybe the enclosing page values should be accessed somehow. Is there a good example code to review? My components usualy contain zones that I use to rerender them when users click on action links, then the parameter has gone null though. - Original Message - From: Thiago H de Paula Figueiredo To: Tapestry users Sent: Monday, December 02, 2013 12:05 PM Subject: Re: component paramter frustrations On Mon, 02 Dec 2013 09:35:03 -0200, John wrote: > I hear that, but again my point is what do you do with the parameter to > persist it into the page? Must you have 2 members for the same value? My point is that you're basing this thread in a wrong assumption, which is persisting parameters. That's wrong. You don't persist parameters, neither directly or indirectly as you're doing. Period. And, in pages or through @SessionState/ApplicationStateManager, you persist just what you really need to. You haven't described your scenario, so I don't know what to suggest you. You're probably passing some value from page to component. If you really need to persist the value, and you should avoid it, you persist the value in the page, not in the component. -- 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
Re: component paramter frustrations
On Mon, 02 Dec 2013 09:35:03 -0200, John wrote: I hear that, but again my point is what do you do with the parameter to persist it into the page? Must you have 2 members for the same value? My point is that you're basing this thread in a wrong assumption, which is persisting parameters. That's wrong. You don't persist parameters, neither directly or indirectly as you're doing. Period. And, in pages or through @SessionState/ApplicationStateManager, you persist just what you really need to. You haven't described your scenario, so I don't know what to suggest you. You're probably passing some value from page to component. If you really need to persist the value, and you should avoid it, you persist the value in the page, not in the component. -- 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
Re: component paramter frustrations
I hear that, but again my point is what do you do with the parameter to persist
it into the page? Must you have 2 members for the same value?
- Original Message -
From: Thiago H de Paula Figueiredo
To: Tapestry users
Sent: Monday, December 02, 2013 11:28 AM
Subject: Re: component paramter frustrations
I don't think you got what I tried to say: if you're persisting a
parameter value, you're doing it wrong, very wrong. As a rule of thumb,
I'd say that persisting parameter values is flat out wrong.
On Mon, 02 Dec 2013 09:21:02 -0200, John 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 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
--
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
Re: component paramter frustrations
I don't think you got what I tried to say: if you're persisting a
parameter value, you're doing it wrong, very wrong. As a rule of thumb,
I'd say that persisting parameter values is flat out wrong.
On Mon, 02 Dec 2013 09:21:02 -0200, John 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 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
--
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
Re: component paramter frustrations
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 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
Re: component paramter frustrations
These are useful tips, but how do you get that transient parameter into the page to begin with unless you copy it to a property value? onActivate is not called for component initialisation so doesn't help with respect to copying the parameter value. - Original Message - From: Lance Java To: Tapestry users Sent: Monday, December 02, 2013 9:27 AM Subject: Re: component paramter frustrations I avoid session usage at all costs (with the exception to the rule being the logged in userId) Why not pass the parameter values in your events so the app is stateless? Also, remember that page. onActivate(...) is called for page render and ajax events so sometimes it's better to initialise here instead of @SetupRender.
Re: component paramter frustrations
On Mon, 02 Dec 2013 07:21:27 -0200, John 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
Re: component paramter frustrations
I avoid session usage at all costs (with the exception to the rule being the logged in userId) Why not pass the parameter values in your events so the app is stateless? Also, remember that page. onActivate(...) is called for page render and ajax events so sometimes it's better to initialise here instead of @SetupRender.
component paramter frustrations
Hi, I pass parameters to some of my componenets but they don't persist by default and are lost on subsequent renders. So on my first render I copy them to a session persist member, but then I end up with 2 variables defined for the same value and across each component in the chain that uses the parameter. This seems inefficient and I am now considering moving the value into the session and accessing with some methods manually. Is there a better way? I think next I will add a hidden field or client type @Persist, but I'm not a huge fan of that either. John
