Another option is environmentals
http://tapestry.apache.org/environmental-services.html
Typically, a parent component will push() and environmental onto the (thread
local) stack and a child component will peek() for the environmental and
update it in some way.
--
View this message in context:
On Wed, 28 Nov 2012 21:22:09 -0200, Robert Hailey rhai...@allogy.com
wrote:
Unless I'm mistaken (which is possible), tapestry will create two
distinct components when building the component trees, and they will not
have access to the same variable.
So a template like:
html ...
I've read the everyone out of the pool blog post, but have not been able to
find an example of how to best use per-thread value on a page or service (seems
like what's provided is an internal tapestry case).
As a (lazy?) tapestry developer, my first thought is to try this:
@Inject
Hi Robert.
Are you looking for a reason to use PreThreadValue? Or do you just want to
have a page/component level property that you can access for the life of
the request?
In a page or component you just declare the variable and let tapestry do
it's magic in the background.
private int
Unless I'm mistaken (which is possible), tapestry will create two distinct
components when building the component trees, and they will not have access to
the same variable.
So a template like:
html ...
t:widget/
t:widget/
t:widget/
/html
Would yield three log messages
Ah right, I was assuming a loop, which would be one instance.
Hmm... I can't remember a time when I've needed to talk across component
instances where using a @SessionState object didn't work. But I can see how
you might want to not have the state persist between requests...
If someone doesn't
On Wednesday, November 28, 2012, Robert Hailey wrote:
I've read the everyone out of the pool blog post, but have not been able
to find an example of how to best use per-thread value on a page or service
(seems like what's provided is an internal tapestry case).
As always. Some of the best
