Re: component paramter frustrations
I've said this many times now. You must pass the parameters in the event context. t:actionlink t:id=foo context=[param1,param2,param3]... / onActionFromFoo(String param1, Foo param2, Bar param3) BTW: IMHO actionlink is deprecated and shouldn't be used. Use eventlink instead.
Re: tapestry-bootstrap question
Hi, which vewrsion of Tapestry are You using? for 5.4 You don't need to user fwtype, just 'class' attribute Eugen 2013/12/5 Nicolas Barrera nbarr...@gmail.com: Hi, Just wandering why should I use the fwtype parameter as in the jumpstart bootstrap example ( http://jumpstart.doublenegative.com.au/jumpstart/examples/styling/bootstrap/1 ) a t:type=eventlink t:event=refresh fwtype=btn btn-inverse href=#Refresh/a I 've been using the tapestry-bootstrap library and using the class parameter instead and obtained same results a t:type=eventlink t:event=refresh class=btn btn-inverse href=#Refresh/a Nicolás.- - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: component paramter frustrations
On Thu, 05 Dec 2013 21:53:44 -0200, John j...@quivinco.com wrote:
here is the template with the problematic actionlink highlighted
Thanks!
center${message:text.diarydenied}/center
I haven't seen the very deprecated center HTML tag for many years . . .
I felt like in 1998 when I read it. :P
a t:type=actionlink t:id=bardayClickedLeft
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=bc=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: using tapx-templating with T5.4
Thanx for the guidance. I tried out tapestry-offline and it works very nicely for me, I think I will stick with this one. I had one configuration problem with tapestry-offline (maybe a bug?): I was getting exception when GZIP compression was turned on (full stack trace below). When I turned off gzip compression in my AppModule, the exception disappeared: configuration.add(SymbolConstants.GZIP_COMPRESSION_ENABLED, false); Full stack trace: Caused by: java.lang.NullPointerException: Unable to delegate method invocation to property 'HTTPServletRequest' of Proxy for RequestGlobals(org.apache.tapestry5.services.RequestGlobals), because the property is null. at $HttpServletRequest_5af77769928a.readProperty(Unknown Source) at $HttpServletRequest_5af77769928a.getProtocol(Unknown Source) at $HttpServletRequest_5af777699289.getProtocol(Unknown Source) at org.apache.tapestry5.internal.services.ResponseCompressionAnalyzerImpl.isGZipSupported(ResponseCompressionAnalyzerImpl.java:50) at org.apache.tapestry5.internal.services.ResponseCompressionAnalyzerImpl.isGZipEnabled(ResponseCompressionAnalyzerImpl.java:75) at $ResponseCompressionAnalyzer_5af777699283.isGZipEnabled(Unknown Source) at org.apache.tapestry5.internal.services.AbstractAssetFactory.isCompressable(AbstractAssetFactory.java:58) at org.apache.tapestry5.internal.services.AbstractAssetFactory$1.toClientURL(AbstractAssetFactory.java:89) at org.apache.tapestry5.internal.services.javascript.JavaScriptStackPathConstructorImpl$1.map(JavaScriptStackPathConstructorImpl.java:54) at org.apache.tapestry5.internal.services.javascript.JavaScriptStackPathConstructorImpl$1.map(JavaScriptStackPathConstructorImpl.java:51) at org.apache.tapestry5.func.LazyMappedValue.get(LazyMappedValue.java:31) at org.apache.tapestry5.func.LazyFlow.first(LazyFlow.java:52) at org.apache.tapestry5.func.AbstractFlow$1.next(AbstractFlow.java:62) at org.apache.tapestry5.func.AbstractFlow.toMutableList(AbstractFlow.java:41) at org.apache.tapestry5.func.AbstractFlow.toMutableList(AbstractFlow.java:34) at org.apache.tapestry5.func.AbstractFlow.toList(AbstractFlow.java:199) at org.apache.tapestry5.internal.services.javascript.JavaScriptStackPathConstructorImpl.toPaths(JavaScriptStackPathConstructorImpl.java:98) at org.apache.tapestry5.internal.services.javascript.JavaScriptStackPathConstructorImpl.constructPathsForJavaScriptStack(JavaScriptStackPathConstructorImpl.java:91) at $JavaScriptStackPathConstructor_5af77769930e.constructPathsForJavaScriptStack(Unknown Source) at org.apache.tapestry5.internal.services.ajax.JavaScriptSupportImpl.addAssetsFromStack(JavaScriptSupportImpl.java:361) at org.apache.tapestry5.internal.services.ajax.JavaScriptSupportImpl.importStack(JavaScriptSupportImpl.java:414) at org.apache.tapestry5.modules.TapestryModule$29.renderMarkup(TapestryModule.java:1797) at $MarkupRenderer_5af77769930f.renderMarkup(Unknown Source) at org.apache.tapestry5.modules.TapestryModule$28.renderMarkup(TapestryModule.java:1785) at $MarkupRenderer_5af77769930f.renderMarkup(Unknown Source) at org.apache.tapestry5.modules.TapestryModule$27.renderMarkup(TapestryModule.java:1769) at $MarkupRenderer_5af77769930f.renderMarkup(Unknown Source) at org.apache.tapestry5.modules.TapestryModule$26.renderMarkup(TapestryModule.java:1753) at $MarkupRenderer_5af77769930f.renderMarkup(Unknown Source) at org.apache.tapestry5.modules.JavaScriptModule$1.renderMarkup(JavaScriptModule.java:237) at $MarkupRenderer_5af77769930f.renderMarkup(Unknown Source) at org.apache.tapestry5.modules.TapestryModule$25.renderMarkup(TapestryModule.java:1736) at $MarkupRenderer_5af77769930f.renderMarkup(Unknown Source) at $MarkupRenderer_5af77769930a.renderMarkup(Unknown Source) at org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:47) at $PageMarkupRenderer_5af777699308.renderPageMarkup(Unknown Source) at org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:64) at $PageResponseRenderer_5af7776992c9.renderPageResponse(Unknown Source) at org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:72) at org.apache.tapestry5.modules.TapestryModule$34.handle(TapestryModule.java:1962) at $PageRenderRequestHandler_5af7776992cb.handle(Unknown Source) at $PageRenderRequestHandler_5af7776992c5.handle(Unknown Source) at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48) at org.apache.tapestry5.services.InitializeActivePageName.handlePageRender(InitializeActivePageName.java:47) at $ComponentRequestHandler_5af7776992c6.handlePageRender(Unknown Source) at
Re: using tapx-templating with T5.4
I've raised an issue, can you try the fix attached to the issue? https://github.com/uklance/tapestry-offline/issues/4
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. t:actionlink t:id=foo context=[param1,param2,param3]... / onActionFromFoo(String param1, Foo param2, Bar param3) BTW: IMHO actionlink is deprecated and shouldn't be used. Use eventlink instead.
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 j...@quivinco.com wrote:
here is the template with the problematic actionlink highlighted
Thanks!
center${message:text.diarydenied}/center
I haven't seen the very deprecated center HTML tag for many years . . .
I felt like in 1998 when I read it. :P
a t:type=actionlink t:id=bardayClickedLeft
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=bc=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
On Fri, 06 Dec 2013 11:02:27 -0200, John j...@quivinco.com 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. center 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
On Fri, 06 Dec 2013 10:56:32 -0200, John j...@quivinco.com 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
@Cached
does @Cached work in only pages, or should it work in components too?
Re: @Cached
It works both in pages and components. On Fri, Dec 6, 2013 at 2:20 PM, John j...@quivinco.com wrote: does @Cached work in only pages, or should it work in components too?
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
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 lance.j...@googlemail.com 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
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
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
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
Re: @Cached
On Fri, 06 Dec 2013 11:33:05 -0200, Dusko Jovanovski dusk...@gmail.com wrote: It works both in pages and components. Just remember that @Cached only caches method return values during a request, but not between requests. I'm planning to do provide some caching (not just in a single thread) in for Tapestry-IoC and Tapestry someday next year. Pages, for the most part, *are* components, but with just few differences: * You cannot use a page inside another page, while components can be used inside other components. * Pages have URLs, components don't. * Components have parameters, pages don't. * Pages have activation context, components don't. -- 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: tapestry-bootstrap question
I 'm using 5.3 Nicolás.- On Fri, Dec 6, 2013 at 6:15 AM, Eugen eugens...@gmail.com wrote: Hi, which vewrsion of Tapestry are You using? for 5.4 You don't need to user fwtype, just 'class' attribute Eugen 2013/12/5 Nicolas Barrera nbarr...@gmail.com: Hi, Just wandering why should I use the fwtype parameter as in the jumpstart bootstrap example ( http://jumpstart.doublenegative.com.au/jumpstart/examples/styling/bootstrap/1 ) a t:type=eventlink t:event=refresh fwtype=btn btn-inverse href=#Refresh/a I 've been using the tapestry-bootstrap library and using the class parameter instead and obtained same results a t:type=eventlink t:event=refresh class=btn btn-inverse href=#Refresh/a Nicolás.- - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: tapestry-bootstrap question
On Fri, 06 Dec 2013 16:28:51 -0200, Nicolas Barrera nbarr...@gmail.com wrote: I 'm using 5.3 Check the documentation at https://github.com/trsvax/tapestry-bootstrap. As far as I could see, fwtype is a parameter of the FW mixin, which is applied to all components automatically by Tapestry-Bootstrap. Nicolás.- On Fri, Dec 6, 2013 at 6:15 AM, Eugen eugens...@gmail.com wrote: Hi, which vewrsion of Tapestry are You using? for 5.4 You don't need to user fwtype, just 'class' attribute Eugen 2013/12/5 Nicolas Barrera nbarr...@gmail.com: Hi, Just wandering why should I use the fwtype parameter as in the jumpstart bootstrap example ( http://jumpstart.doublenegative.com.au/jumpstart/examples/styling/bootstrap/1 ) a t:type=eventlink t:event=refresh fwtype=btn btn-inverse href=#Refresh/a I 've been using the tapestry-bootstrap library and using the class parameter instead and obtained same results a t:type=eventlink t:event=refresh class=btn btn-inverse href=#Refresh/a Nicolás.- - 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
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
Contributing an object that itself can take contributions?
I'm building a service MasterFooProvider that takes contributions of type
FooProvider. I'd really love for one my FooProvider implementations,
ConfigurableFooProvider, to be able to take contributions of its own (of
type String), so its behavior can be customized.
My first stab at implementing this failed.
I made ConfigurableFooProvider a concrete class that implements FooProvider,
and I tried annotating it the class (not interface) with
@UsesConfiguration(String.class). Its constructor takes a ListStringparam.
In my AppModule, I have:
contributeMasterFooProvider() ( OrderedConfigurationFooProvider config) {
config.addInstance(ConfigurableFoo, ConfigurableFooProvider.class);
}
What wound up happening is that Tapestry fails to build MasterFooProvider
with an exception saying that a contribution of type
ConfigurableFooProvider is invalid, because MasterFooProvider expects
contributions of type String.
So I'm pretty sure one misstep I took was trying to make contributions to
an impl instead of an interface, but it's not clear to me if it would work.
To make matters more complicated, I have the need to sub-class
ConfigurableFooProvider, and I don't want the derived classes to share
configuration. In other words, I want to be able to configure/contribute to
each sub-class separately.
Is there a way to do what I'd like to do here, or do I need to change my
approach to making a configurable FooProvider?
John
Trying to get Tapestry Cometd working with T5.4
Hello, Im trying to get lances Tapestry Cometd working with 5.4, however I'm running into a couple problems. I'm get the following exception. Now I'd like to point out I'm not using Tapestry-Jquery like the documentation says your suppose to do to the fact jquery is now a part of 5.4. Lance, any suggestions? Thanks. *with reload*: Force a reload of component classes. This is often necessary after fixing a class that previously failed to compile due to errors. java.lang.NoSuchMethodError *org.apache.tapestry5.json.JSONObject.init([Ljava/lang/String;)V* Filter Frames? Stack trace: org.lazan.t5.cometd.components.PushTarget getInitData()PushTarget.java123 org.lazan.t5.cometd.components.PushTarget beginRender()PushTarget.java105 org.lazan.t5.cometd.components.PushTarget beginRender()PushTarget.java org.apache.tapestry5.internal.structure.ComponentPageElementImpl$BeginRenderPhase invokeComponent()ComponentPageElementImpl.java207 org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AbstractPhase invoke()ComponentPageElementImpl.java138 org.apache.tapestry5.internal.structure.ComponentPageElementImpl$BeginRenderPhase render()ComponentPageElementImpl.java214 org.apache.tapestry5.internal.services.RenderQueueImpl run() RenderQueueImpl.java73 org.apache.tapestry5.internal.services.PageRenderQueueImpl render()PageRenderQueueImpl.java124 org.apache.tapestry5.internal.services.MarkupRendererTerminator renderMarkup()MarkupRendererTerminator.java37 org.apache.tapestry5.internal.services.PageNameMetaInjector renderMarkup() PageNameMetaInjector.java41 org.apache.tapestry5.modules.TapestryModule$29 renderMarkup()TapestryModule.java1795 org.apache.tapestry5.modules.TapestryModule$28 renderMarkup()TapestryModule.java1785 org.apache.tapestry5.modules.TapestryModule$27 renderMarkup()TapestryModule.java1769 org.apache.tapestry5.modules.TapestryModule$26 renderMarkup()TapestryModule.java1753 org.apache.tapestry5.internal.services.javascript.ConfigureHTMLElementFilter renderMarkup()ConfigureHTMLElementFilter.java45 org.apache.tapestry5.modules.JavaScriptModule$1 renderMarkup()JavaScriptModule.java237 org.apache.tapestry5.modules.TapestryModule$25 renderMarkup()TapestryModule.java1736 org.apache.tapestry5.internal.services.PageMarkupRendererImpl renderPageMarkup()PageMarkupRendererImpl.java47 org.apache.tapestry5.internal.services.PageResponseRendererImpl renderPageResponse()PageResponseRendererImpl.java64 org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl handle() PageRenderRequestHandlerImpl.java72 org.apache.tapestry5.modules.TapestryModule$34 handle()TapestryModule.java1962 org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator handlePageRender()ComponentRequestHandlerTerminator.java48 org.apache.tapestry5.services.InitializeActivePageName handlePageRender() InitializeActivePageName.java47 org.apache.tapestry5.internal.services.RequestOperationTracker$2 run()RequestOperationTracker.java73 org.apache.tapestry5.internal.services.RequestOperationTracker handlePageRender()RequestOperationTracker.java66 org.lazan.t5.cometd.services.internal.PageGlobalsComponentRequestFilter handlePageRender()PageGlobalsComponentRequestFilter.java28 org.tynamo.security.SecurityComponentRequestFilter handlePageRender() SecurityComponentRequestFilter.java49 org.apache.tapestry5.internal.services.PageRenderDispatcher dispatch()PageRenderDispatcher.java45 org.apache.tapestry5.modules.TapestryModule$RequestHandlerTerminator service()TapestryModule.java300 org.apache.tapestry5.internal.services.RequestErrorFilter service()RequestErrorFilter.java26 org.apache.tapestry5.modules.TapestryModule$3 service()TapestryModule.java845 org.apache.tapestry5.modules.TapestryModule$2 service()TapestryModule.java835 org.apache.tapestry5.internal.services.StaticFilesFilter service()StaticFilesFilter.java89 com.cardaddy.auto.services.AppModule$1 service()AppModule.java184 org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2 invoke()CheckForUpdatesFilter.java105 org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2 invoke()CheckForUpdatesFilter.java95 org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier withRead()ConcurrentBarrier.java85 org.apache.tapestry5.internal.services.CheckForUpdatesFilter service()CheckForUpdatesFilter.java119 org.apache.tapestry5.modules.TapestryModule$HttpServletRequestHandlerTerminator service()TapestryModule.java251 org.apache.tapestry5.internal.gzip.GZipFilter service()GZipFilter.java59 org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter service()MultipartServletRequestFilter.java44 org.lazan.t5.cometd.services.internal.ServletHttpServletRequestFilter service()ServletHttpServletRequestFilter.java82 org.tynamo.security.services.impl.SecurityConfiguration$1 call() SecurityConfiguration.java56 org.tynamo.security.services.impl.SecurityConfiguration$1 call()SecurityConfiguration.java54 org.apache.shiro.subject.support.SubjectCallable
