On Tue, Jan 19, 2010 at 8:03 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
> I'm doing some interesting work with changes to > ComponentClassTransformer right now; part of what I'm doing is to set > the stage for moving away from Javassist in the future. > > Increasingly, I'm building up new APIs that allow the transformations > on the component class to be expressed in terms of interfaces and > callbacks, and I'm decreasing the amount of "Javassist-psuedocode" > that gets written. Reducing the generated code feels like a step in the right direction... in any way... > I'll have some checkins to 5.2 in a few more days. > > One idea that's occured to me is that, in addition to instrumenting > injected fields and parameter fields, we could use the same trick for > ordinary fields, holding transient per-request data. Effectively, the > page would contain no mutable state, all mutable state for the page > would be shunted off into a per-request HashMap. ... while this feels like a derivation from a jure-language... > There'd be some overhead to that (reading or updating a field would > turn into several method calls), but if done properly, it means we > would only need ONE instance of a page (per locale). > > I wonder if this is worth pursuing; it's a lot of work. Done a > reduction in memory overhead and some of the other aspects (such as > page pool maintenance) justify the overhead for field access? Plus > there are some areas I'm not sure how to handle. Well field access is quite common so putting an overhead on that are doesn't sounds so appealing while on the other hand if that overhead is limited to the call to n-methods that simply do lookups (maybe to the mentioned map) and doesn't move things around, well, could not be bad. That said we already have have an application server to run T5 that holds a various types of pools and threads so i see simplifications of the "T5 page" mechanism as a great plus, having one instance of a page instead of a pool to serve requests is by definition a good thing while i'm not sure to follow you where you want to "store" the map holding the "request states" Anyway i must admin that my experience with T5 is with complex web applications with not so many pages but with pages with a lot of states and complex structure so I'm not so incline to have trouble with the current default pages-pool system. Cheers -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
