Most interaction in my app is Ajax based. Due to some Seaside 2.8
restrictions I am using Lukas' #in:do: workaround for updating/re-rendering one component from the callback of another. This seems to cause the callback count to increase with time (at least the little callback numbers in Seaside generated links keep increasing) _s=i178duf&_k=usj27a&45 <- 45 OK, so I sometimes do an explicit whole-page refresh html anchor callback: [WARenderLoop new call: self] with: 'Explicit Refresh' This of course enables the back button, presumably keeping around stuff that is meaningless for my application. I'm hoping for a simple way to free up at least some of the resources (e.g. large number of callbacks? some RenderContinuations/Contexts/or similar?) left around to support the back button. Is anything like isolate: applicable? html anchor callback: [self isolate: [WARenderLoop new call: self]] with: 'Explicit Refresh' Other suggestions? Thanks - Sophie _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
First, are you sure it's a problem? I wouldn't worry about optimizing
this until you have so many users that you're running out of resources. However, the simplest solution (I think) would be to subclass WASession and implement #initialize initialize super initialize. continuations capacity: 10. "or however many continuations you want to keep around" The default capacity is 20. Julian On Thu, Jul 24, 2008 at 6:43 AM, itsme213 <[hidden email]> wrote: > Most interaction in my app is Ajax based. Due to some Seaside 2.8 > restrictions I am using Lukas' #in:do: workaround for updating/re-rendering > one component from the callback of another. > > This seems to cause the callback count to increase with time (at least the > little callback numbers in Seaside generated links keep increasing) > _s=i178duf&_k=usj27a&45 <- 45 > OK, so I sometimes do an explicit whole-page refresh > > html anchor > callback: [WARenderLoop new call: self] > with: 'Explicit Refresh' > > This of course enables the back button, presumably keeping around stuff that > is meaningless for my application. > > I'm hoping for a simple way to free up at least some of the resources (e.g. > large number of callbacks? some RenderContinuations/Contexts/or similar?) > left around to support the back button. Is anything like isolate: > applicable? > > html anchor > callback: [self isolate: [WARenderLoop new call: self]] > with: 'Explicit Refresh' > > Other suggestions? > > Thanks - Sophie > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
"Julian Fitzell" <[hidden email]> wrote in message
> First, are you sure it's a problem? Reasonably sure, as responsiveness degrades over time (may be other causes to, I'm not sure which objects/inst vars to inspect to actually verify this - any hints?). I don't think its a multi-user issue, more from doing something outside the designed-for boundary of Ajax in 2.8. > However, the simplest solution (I think) would be to subclass > WASession and implement #initialize Thanks, will do that. Sophie > > initialize > super initialize. > continuations capacity: 10. "or however many continuations you want > to keep around" > > The default capacity is 20. > > Julian > > On Thu, Jul 24, 2008 at 6:43 AM, itsme213 <[hidden email]> wrote: >> Most interaction in my app is Ajax based. Due to some Seaside 2.8 >> restrictions I am using Lukas' #in:do: workaround for >> updating/re-rendering >> one component from the callback of another. >> >> This seems to cause the callback count to increase with time (at least >> the >> little callback numbers in Seaside generated links keep increasing) >> _s=i178duf&_k=usj27a&45 <- 45 >> OK, so I sometimes do an explicit whole-page refresh >> >> html anchor >> callback: [WARenderLoop new call: self] >> with: 'Explicit Refresh' >> >> This of course enables the back button, presumably keeping around stuff >> that >> is meaningless for my application. >> >> I'm hoping for a simple way to free up at least some of the resources >> (e.g. >> large number of callbacks? some RenderContinuations/Contexts/or similar?) >> left around to support the back button. Is anything like isolate: >> applicable? >> >> html anchor >> callback: [self isolate: [WARenderLoop new call: self]] >> with: 'Explicit Refresh' >> >> Other suggestions? >> >> Thanks - Sophie >> >> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Sophie424
itsme213 wrote:
> > html anchor > callback: [WARenderLoop new call: self] > with: 'Explicit Refresh' > > This of course enables the back button, presumably keeping around stuff that > is meaningless for my application. > > I'm hoping for a simple way to free up at least some of the resources (e.g. > large number of callbacks? some RenderContinuations/Contexts/or similar?) > left around to support the back button. Is anything like isolate: > applicable? > > html anchor > callback: [self isolate: [WARenderLoop new call: self]] > with: 'Explicit Refresh' > > Other suggestions? > > Thanks - Sophie I cannot answer the question but I have a keen interest in the answer. I hope that some experienced developer can shed some light on this. Thanks, Frank _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |