You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tapestry.apache.org by bu...@apache.org on 2004/06/02 14:56:29 UTC

DO NOT REPLY [Bug 29340] - Suggest to use component level pooling instead of page level pooling

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29340>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29340

Suggest to use component level pooling instead of page level pooling

hlship@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From hlship@apache.org  2004-06-02 12:56 -------
The cost is not the memory usage, which is trivial. It is the cost of 
connecting the components to the pages, and doing all the other work. See the 
PageLoader code ... quite a bit of reflection to instantiate objects, connect 
them together, analyze the results.

In addition, having components fixed to the page solves a lot of problems 
related to localization, and allows the components greater latitude to cache 
invariant binding values in local instance variables.

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org