Thanks for getting back to me. I can see difference but it still feels a bit
odd.
I would expect anything declared inside a loop not to persist between
iterations. But thanks for explaining it to me, I can ensure that my
components have the relevant cleanup methods.
On Wed, Jul 8, 2009 at 6:26 PM, Robert Zeigler <robe...@scazdl.org> wrote:
> You're comparing apples to oranges:
> The first is a single component instance rendered three times.
> The second is three separate instances of a particular component type
> being rendered.
>
> Consider the difference between:
>
> <t:loop source="users" row="currentUser">
> <t:textfield value="currentUser.firstName"/>
> </t:loop>
>
> and
>
> <t:textfield value="someOtherValue"/>
>
> The textfield within the loop is clearly the same component instance... and
> you want it to be (although you want bindings to be updated iteration of the
> loop so you're always bound to the current user's firstName).
>
> I think your confusion comes in misunderstanding the pooling process.
> Components aren't pooled. Pages are.
> The process goes:
> User requests a page
> If page instance exists in pool, return, otherwise, assemble a new page
> When assempling a new page, each component used by the page (and, in turn,
> its embedded components) is /instantiated/. It is /not/ checked out from a
> pool. There is no pool of components, only a pool of pages. The things
> tapestry does to speed up page fetching (aside from pooling /page/
> instances, with the entire component tree of the page associated with it) is
> to cache the page "assembler", which is basically a list of instructions on
> how to create a new page, so you're not constantly parsing templates, etc.,
> but just re-executing a pre-programmed set of commands. Generating the
> assembler is expensive; running the assembler is cheaper (but still
> expensive enough to justify page pooling).
>
> HTH.
>
> Robert
>
>
> On Jul 8, 2009, at 7/86:33 AM , Jack Nuzbit wrote:
>
> Hello,
>>
>> Am I correct in thinking that when a component is acquired from the pool
>> it's state should be reset?
>> I'm asking because I've noticed that when rendering components repeatedly
>> in
>> a loop the state doesn't get reset.
>>
>> Here's the test component I've used:
>>
>> public class Test {
>>
>> @Property
>> private int a;
>>
>> void setupRender() {
>> a++;
>> }
>> }
>> with corresponding component html:
>>
>> <t:container xmlns:t="
>> http://tapestry.apache.org/schema/tapestry_5_1_0.xsd";>
>> ${a}
>> </t:container>
>>
>>
>> Here's the page i used to test the component.
>>
>>
>> <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd";>
>> <body>
>>
>> <h3>Looped references</h3>
>> <t:loop source="1..3" >
>> <t:test/>
>> </t:loop>
>>
>> <h3>Static references</h3>
>> <t:test/>
>> <t:test/>
>> <t:test/>
>>
>> </body>
>> </html>
>>
>> The output is:
>> Looped references 1 2 3 Static references 1 1 1
>>
>> I know i could reset variables in a cleanup render method but shouldn't
>> the
>> component behave the same way inside or outside of a loop?
>> Many thanks,
>>
>> Jack
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
