Hm... interesting... I had a different understanding of the pooling process... though I could be wrong. :) My understanding is that only the pages are pooled. The page spec, and all component specs contained therein, are parsed once and cached. The page instance, and all contained components, are created once; once a component instance is created, it is always associated with the same page instance, even after the page is returned to the pool. In which case, most of the overhead you mention is avoided (except in the initial caching process). I think the only thing that you'd be looking at in terms of additional overhead is the binding process... not sure how much overhead that adds, though. Someone with more intimate knowledge of the process want to comment here?
Robert Darío Vasconcelos wrote: > As far as I understand, the page rendering is always done on-the-fly, > that is, there is a component pool and when some page needs one, the > pool quickly provides it. Now, thinking what Chris originally asked, > is there too much overhead if I have a page with, say, 20 components? > Or 50? If a page has deeply nested components and many many variables > to bind (doing it both in the rewinding and the processing phases), > Tapestry of course would be a much better option over JSPs or similar, > but is there an inflexion point where one would be indeed abusing the > concept? > > > PS. Proof-reading my own post I realize this is kind of a silly > question, since such a complex page should never exist and would be a > problem not only for any framework but also for any user... :-) > > > On 8/5/05, Kevin Menard <[EMAIL PROTECTED]> wrote: > >>On Friday 05 August 2005 19:13, Robert Zeigler wrote: >> >> >>>My point was simply that, just because you can't reuse the component >>>across multiple projects doesn't mean it shouldn't be a component. :) >>>(Or, there's nothing wrong with application-specific components. :) >> >>Ahh good, then we're in agreement :-) >> >>-- >>Kevin >> >>--------------------------------------------------------------------- >>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]
