You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Rhodes, Phillip C." <Ph...@alcoa.com> on 2003/11/12 17:31:46 UTC
page vs. visit?
Can someone confirm my understanding? I am struggling to understand what looks to be a great framework.
The page object is in the request scope. That is, instance data in the page object is not persisted across requests.
Session data is stored in the visit object. Each page can get to the visit object in order to set persistent properties.
There is only one visit object in a webapp
Thanks for you time.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: page vs. visit?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Bill Lear wrote:
> On Wednesday, November 12, 2003 at 12:25:02 (-0500) Harish Krishnaswamy writes:
>
>>Yes, I missed that and Howard caught it! So the revised equivalents would be,
>>
>>Scope equivalents:
>>
>>jsp (page + request) = Tapestry Page (no confusion!)
>>jsp session = Tapestry Visit + Persistent Page properties
>
>
> Ok, PPP for Persistent Page Properties.
>
>
>>jsp application = Tapestry Global
>
>
> Just to clear up my praxis-based but nevertheless hazy understanding
> of how this works: Visit and PPP are per-session, that is
> (essentially), per-user. So when a new page is requested, the session
> key (assuming it exists) is used to pull up the appropriate PPP
> information, the page is populated with the latter, and the Visit
> object is then available through the appropriate method calls.
>
> The difference here, obviously, is one of scope: the Visit object
> is accessible by all pages, PPP information only for the particular
> page in which it is declared.
That would be correct although the scope of the PPPs will be that of the session , they are only
*visible* to the declaring page.
>
> I assume Howard's Feb 20th posting of this year to another forum
> still holds in Tapestry 3.0?:
>
>
>>Through 2.3, everything was serialized in the same graph. This is changed
>>in 2.4 where the engine and the visit are serialized together and each
>>persistent page property is stored under its own HttpSession key.
>>
>>This makes more sense from an efficiency standpoint. The engine & visit get
>>(re-)stored into the HttpSession every request cycle so it's very good to
>>keep them as small as possible. Persistent page properties change
>>relatively rarely, storing them individually is, again, more efficient. Of
>>course, this efficiency is only meaningful in a clustered environment, where
>>HttpSession.setAttribute() results in the value being serialized and IPC'ed
>>to other servers.
>>
>>In addition, using many small keys makes it much, much easier to see (in the
>>RequestContext dump) what persistent state has been stored without using the
>>Inspector. I consider this a big plus!
>
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: page vs. visit?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Objects in the Global will not be garbage collected until the application is shutdown at least as
far as I know. Global is mainly for storing data globally applicable to the application
(irrespective of the user). I would recommend storing user data in the Visit or in a persistent page
property or even better in the html page itself (in a stateless mode).
-Harish
Bryan Lewis wrote:
> Interesting thread. Makes me think that I shouldn't be storing large
> lists of data objects (for fast page-batching) in the Visit object. At
> first that seemed like the proper place since the list is of no interest
> to other users. But the efficiency issue raised below indicates that
> the Global object would be a better place.
>
> This is a bit non-intuitive because the list is of no interest to other
> users, but it makes sense if you regard it as basically a non-persistent
> cache. It's going to hang around until it gets cleaned up by garbage
> collection. It uses the same amount of server memory either way. I
> don't mind if it's lost in a failover.
>
> The only small programming wrinkle is, creating a unique key to refer to
> it in Global.
>
> Make sense?
>
> If someone has ideas for cleaning up the old lists more efficiently I'd
> be glad to hear them, but be forewarned that my users are addicted to
> the browser's Back button. (They might have to get over that when we
> convert to Tapestry anyway.)
> Would it be true that objects stored in Global would get
> garbage-collected sooner? Configurable? I'm not using Global for
> anything at the moment.
>
>
> ----- Original Message -----
> From: "Bill Lear" <ra...@zopyra.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Wednesday, November 12, 2003 1:39 PM
> Subject: Re: page vs. visit?
>
>
>
>>On Wednesday, November 12, 2003 at 12:25:02 (-0500) Harish
>
> Krishnaswamy writes:
>
>>>Yes, I missed that and Howard caught it! So the revised equivalents
>
> would be,
>
>>>Scope equivalents:
>>>
>>>jsp (page + request) = Tapestry Page (no confusion!)
>>>jsp session = Tapestry Visit + Persistent Page properties
>>
>>Ok, PPP for Persistent Page Properties.
>>
>>
>>>jsp application = Tapestry Global
>>
>>Just to clear up my praxis-based but nevertheless hazy understanding
>>of how this works: Visit and PPP are per-session, that is
>>(essentially), per-user. So when a new page is requested, the session
>>key (assuming it exists) is used to pull up the appropriate PPP
>>information, the page is populated with the latter, and the Visit
>>object is then available through the appropriate method calls.
>>
>>The difference here, obviously, is one of scope: the Visit object
>>is accessible by all pages, PPP information only for the particular
>>page in which it is declared.
>>
>>I assume Howard's Feb 20th posting of this year to another forum
>>still holds in Tapestry 3.0?:
>>
>>
>>>Through 2.3, everything was serialized in the same graph. This is
>
> changed
>
>>>in 2.4 where the engine and the visit are serialized together and
>
> each
>
>>>persistent page property is stored under its own HttpSession key.
>>>
>>>This makes more sense from an efficiency standpoint. The engine &
>
> visit get
>
>>>(re-)stored into the HttpSession every request cycle so it's very
>
> good to
>
>>>keep them as small as possible. Persistent page properties change
>>>relatively rarely, storing them individually is, again, more
>
> efficient. Of
>
>>>course, this efficiency is only meaningful in a clustered
>
> environment, where
>
>>>HttpSession.setAttribute() results in the value being serialized and
>
> IPC'ed
>
>>>to other servers.
>>>
>>>In addition, using many small keys makes it much, much easier to see
>
> (in the
>
>>>RequestContext dump) what persistent state has been stored without
>
> using the
>
>>>Inspector. I consider this a big plus!
>>
>>
>>Bill
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: page vs. visit?
Posted by Bryan Lewis <br...@maine.rr.com>.
Interesting thread. Makes me think that I shouldn't be storing large
lists of data objects (for fast page-batching) in the Visit object. At
first that seemed like the proper place since the list is of no interest
to other users. But the efficiency issue raised below indicates that
the Global object would be a better place.
This is a bit non-intuitive because the list is of no interest to other
users, but it makes sense if you regard it as basically a non-persistent
cache. It's going to hang around until it gets cleaned up by garbage
collection. It uses the same amount of server memory either way. I
don't mind if it's lost in a failover.
The only small programming wrinkle is, creating a unique key to refer to
it in Global.
Make sense?
If someone has ideas for cleaning up the old lists more efficiently I'd
be glad to hear them, but be forewarned that my users are addicted to
the browser's Back button. (They might have to get over that when we
convert to Tapestry anyway.)
Would it be true that objects stored in Global would get
garbage-collected sooner? Configurable? I'm not using Global for
anything at the moment.
----- Original Message -----
From: "Bill Lear" <ra...@zopyra.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, November 12, 2003 1:39 PM
Subject: Re: page vs. visit?
> On Wednesday, November 12, 2003 at 12:25:02 (-0500) Harish
Krishnaswamy writes:
> >Yes, I missed that and Howard caught it! So the revised equivalents
would be,
> >
> >Scope equivalents:
> >
> >jsp (page + request) = Tapestry Page (no confusion!)
> >jsp session = Tapestry Visit + Persistent Page properties
>
> Ok, PPP for Persistent Page Properties.
>
> >jsp application = Tapestry Global
>
> Just to clear up my praxis-based but nevertheless hazy understanding
> of how this works: Visit and PPP are per-session, that is
> (essentially), per-user. So when a new page is requested, the session
> key (assuming it exists) is used to pull up the appropriate PPP
> information, the page is populated with the latter, and the Visit
> object is then available through the appropriate method calls.
>
> The difference here, obviously, is one of scope: the Visit object
> is accessible by all pages, PPP information only for the particular
> page in which it is declared.
>
> I assume Howard's Feb 20th posting of this year to another forum
> still holds in Tapestry 3.0?:
>
> >Through 2.3, everything was serialized in the same graph. This is
changed
> >in 2.4 where the engine and the visit are serialized together and
each
> >persistent page property is stored under its own HttpSession key.
> >
> >This makes more sense from an efficiency standpoint. The engine &
visit get
> >(re-)stored into the HttpSession every request cycle so it's very
good to
> >keep them as small as possible. Persistent page properties change
> >relatively rarely, storing them individually is, again, more
efficient. Of
> >course, this efficiency is only meaningful in a clustered
environment, where
> >HttpSession.setAttribute() results in the value being serialized and
IPC'ed
> >to other servers.
> >
> >In addition, using many small keys makes it much, much easier to see
(in the
> >RequestContext dump) what persistent state has been stored without
using the
> >Inspector. I consider this a big plus!
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: page vs. visit?
Posted by Bill Lear <ra...@zopyra.com>.
On Wednesday, November 12, 2003 at 12:25:02 (-0500) Harish Krishnaswamy writes:
>Yes, I missed that and Howard caught it! So the revised equivalents would be,
>
>Scope equivalents:
>
>jsp (page + request) = Tapestry Page (no confusion!)
>jsp session = Tapestry Visit + Persistent Page properties
Ok, PPP for Persistent Page Properties.
>jsp application = Tapestry Global
Just to clear up my praxis-based but nevertheless hazy understanding
of how this works: Visit and PPP are per-session, that is
(essentially), per-user. So when a new page is requested, the session
key (assuming it exists) is used to pull up the appropriate PPP
information, the page is populated with the latter, and the Visit
object is then available through the appropriate method calls.
The difference here, obviously, is one of scope: the Visit object
is accessible by all pages, PPP information only for the particular
page in which it is declared.
I assume Howard's Feb 20th posting of this year to another forum
still holds in Tapestry 3.0?:
>Through 2.3, everything was serialized in the same graph. This is changed
>in 2.4 where the engine and the visit are serialized together and each
>persistent page property is stored under its own HttpSession key.
>
>This makes more sense from an efficiency standpoint. The engine & visit get
>(re-)stored into the HttpSession every request cycle so it's very good to
>keep them as small as possible. Persistent page properties change
>relatively rarely, storing them individually is, again, more efficient. Of
>course, this efficiency is only meaningful in a clustered environment, where
>HttpSession.setAttribute() results in the value being serialized and IPC'ed
>to other servers.
>
>In addition, using many small keys makes it much, much easier to see (in the
>RequestContext dump) what persistent state has been stored without using the
>Inspector. I consider this a big plus!
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: page vs. visit?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Yes, I missed that and Howard caught it! So the revised equivalents would be,
Scope equivalents:
jsp (page + request) = Tapestry Page (no confusion!)
jsp session = Tapestry Visit + Persistent Page properties
jsp application = Tapestry Global
-Harish
Bill Lear wrote:
> On Wednesday, November 12, 2003 at 11:46:19 (-0500) Harish Krishnaswamy writes:
>
>>That's right.
>
>
> But what about persistent page attributes? Those need to be mentioned, no?
>
>
>>Scope equivalents:
>>
>>jsp (page + request) = Tapestry Page (no confusion!)
>>jsp session = Tapestry Visit
>>jsp application = Tapestry Global
>
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: page vs. visit?
Posted by Bill Lear <ra...@zopyra.com>.
On Wednesday, November 12, 2003 at 11:46:19 (-0500) Harish Krishnaswamy writes:
>That's right.
But what about persistent page attributes? Those need to be mentioned, no?
>Scope equivalents:
>
>jsp (page + request) = Tapestry Page (no confusion!)
>jsp session = Tapestry Visit
>jsp application = Tapestry Global
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: page vs. visit?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
That's right.
Scope equivalents:
jsp (page + request) = Tapestry Page (no confusion!)
jsp session = Tapestry Visit
jsp application = Tapestry Global
-Harish
Rhodes, Phillip C. wrote:
> Can someone confirm my understanding? I am struggling to understand what looks to be a great framework.
>
> The page object is in the request scope. That is, instance data in the page object is not persisted across requests.
>
> Session data is stored in the visit object. Each page can get to the visit object in order to set persistent properties.
>
> There is only one visit object in a webapp
>
> Thanks for you time.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org