I would go further. Using the abstract modifier to distinguish page and
session scope properties is inappropriate. abstract does not denote
session scope, page scope or take a chance. This exacerbates the problem
currently addressed in another thread, "Tapestry starting to look too
steep", because it doesn't help new people to re-use what they already
know, instead it creates the gotcha Alan points out.
How about this solution: a persistence-scope attribute of either 'page'
or 'session' which could be applied to both abstract and concrete
properties. Or the persistence attribute could be enhanced to add these
and depreate 'y' / 'n'.
In that case Alan's problem occurs when the user's scope choice is wrong
or the default is wrong. So I think the default scope should be 'none'
or 'not_cached' or 'cleared' where the page is returned with null. I
think that default is most cases, but the behavior will help us catch
most of the errors in cases where a conscious choice should be made.
Alan Zimmerman wrote:
Hi all
I have been bitten in similar fashion when a page works fine in single
user/development mode, but fails in a multiuser environment due to
the kinds of gotchas explained below.
Is it possible to set the engine up to ALWAYS cull the page pool (and
whatever else it does), so that the single user test case is
representative of the multi-user experience?
I am working with 3.0 at this stage.
Regards
Alan
On Wed, Jul 20, 2005 at 09:16:39AM -0400, Howard Lewis Ship wrote:
You are not making your properties abstract; you are therefore having
problems because user data is stored in properties of pages (stored
within the page pool), not within the HttpSession as they should be.
When the pages are culled from the page pool, you lose your server side data.
You MUST use abstract accessor methods and mark the properties as
persistent. Only in this way will properties be stored into the
HttpSession. This can be done in 3.0 using XML and in 4.0 using
annotations (or XML).
The fact that your application works at all in development is a
feature. It will neither scale to more users on a single server, or
work in properly in a cluster.
Not a single example piece of code in TiA or in the Quick Start
tutorial tries to do such an "end run" around Tapestry. Do so at your
own peril.
The only times I don't use abstract properties is when I want to cache
an expensive object that is not client- or request- dependent. For
example, I may cache an IPropertySelection model, lazily creating it
as necessary.
On 7/18/05, Edward Scanzano <[EMAIL PROTECTED]> wrote:
Hi all,
I have a situtation where my application runs normally
as I click through it. Parameters are being passed to
components correctly, etc. However, if I let the
application sit idle for a short time (maybe 10
minutes, not sure of the exact time) then when I click
on those same links I get exceptions that are caused
by component parameters being null. The session has
not timed out yet.
What is causing this?
Thanks
E
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
