[email protected]
[Top] [All Lists]

RE: Foreach-Troubles

Subject: RE: Foreach-Troubles
From: "Reinhold Gruber"
Date: Mon, 4 Apr 2005 12:13:15 +0200
I'm pasting the source-code of my component. I hope that clarifies what
im trying to achieve.

public abstract class CreditRenderer extends BaseComponent implements
PageDetachListener {

        public abstract Credit getCredit();
        public abstract void setCredit(Credit credit);
        public abstract CoDebtorship getCoDebtorship();
        public abstract void setCoDebtorship(CoDebtorship d);
        private FormattedCredit formattedCredit;
        public CreditRenderer() {
                System.out.println("****CreditRenderer created");
        public FormattedCredit getFormat() {
                if(formattedCredit == null)  {
                        if(getCoDebtorship() != null) {
                                formattedCredit = new
                        else {
                                formattedCredit = new
                return formattedCredit;
        public void pageDetached(PageEvent event) {
                formattedCredit = null;
        public void renderComponent(IMarkupWriter w, IRequestCycle c) {
                super.renderComponent(w, c);
                formattedCredit = null;

CreditRenderer.jwc is only using the FormattedCredit-Object which
contains some formatting-logic already used in JSPs which I tried to
reuse in this component. As you can see I worked around the problem by
this ugly renderComponent-ReImplementation. But I doubt that this is
best practice.
I know that I would not have this kind of problem if I would inject the
FormattedCredit instead of Credit or CoDebtorship. But I wanted to
encapsulated the corresponding instantiation logic in this component.

Any proposals or advices highly appreciated.

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Monday, April 04, 2005 11:54
To: Tapestry users
Subject: RE: Foreach-Troubles

Look at it this way, why should there be 3 instances of the same
component? I mean, it does not make sense from Tapestrys view to
instantiate the same Class 3 times when one time is enough. The
assumption then is that a component is stateless, it is responsible for
rendering data injected to it through the parameter bindings.
This is similar to the flyweight design pattern.
I suggest you move the lazy initialization of properties out of
CreditRenderer and put it into the actual data object
I hope I understood your problem correctly.

>Both ways are possible. I tried your suggestion. There is still only
>CreditRenderer-Instance which is rendered 3 times.
>Reinhold, clueless
>> I have the following in a page template:
>> <loop jwcid="[email protected]" source="ognl:person.ownCredits">
>>         <span jwcid="@CreditRenderer"
>> credit="ognl:components.ownCredits.value"/>
>> </loop>
>> person.ownCredits is an array with 3 items.
>> CreditRenderer.renderComponent(..) is called 3 times,
>> but always on the same CreditRenderer-Instance!!. I verified this by
>> putting a System.out.println() in the Default-Constructor of
>> CreditRenderer.
>> This issue causes problems because I lazy initialize some properties
>> CreditRenderer and reseting them by implementing PageDetachListener.
>> Reinhold

To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

[email protected]----
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

<Prev in Thread] Current Thread [Next in Thread>