Hi, > Anyway the confusion is that each time I call getBinding().getObject() > I noticed that I get an object with a different address.
I am not sure why that would happen on a single machine (do you use OGNL?), but in a cluster that would obviously be true -- the objects will be different on different machines, as they have to go through serialization and deserialization. In general (this does not refer only to Tapestry, but to pretty much everything) using == rather than .equals() is a bad idea. > However if I call a setter on the parameter this change has > dissapeared the next time I call getBinding().getObject(). Please call getBinding().setObject() after you make the change. This may be related to the issue mentioned above. Tapestry needs to be notified that something has changed. If it is not, it will not update the object in the session and your changes would be lost. If the object was the same, you may go by without that notification, as the object would be changed anyway. But the prudent thing is to _always_ notify Tapestry that a modification has occurred. That guarantees that your code will work on a variety of App Servers, and in a cluster. Again, this is not so much a Tapestry-specific issue. Hope this helps, -mb ----- Original Message ----- From: "Robert" <[EMAIL PROTECTED]> To: "Tapestry users" <[email protected]> Sent: Tuesday, July 05, 2005 10:36 AM Subject: Re: Binding confusion > Robert wrote: > > > Hi! > > I am having some questions regarding to bindings. > > > > It seems my questions are not answered on both the mailing list and > forum which makes me worry about continuing to use tapestry. > I am curious why not. Is it because > 1) The question is too difficult > 2) This has been asked many times before and people are bored to answer > it again > 3) My question is not formulated correctly and therefore incomprehensible > 4) Something else > > > > I have a component with one parameter which is a complex object that > > includes some setters. I have set the direction to custom. I have done > > it because I need to access it before the render phase. And also > > because I can implement the methods to access the parameter myself and > > avoid to use abstract classes (bad design in my opinion). > > > > Anyway the confusion is that each time I call getBinding().getObject() > > I noticed that I get an object with a different address. They do have > > the correct values set by the page that created this parameter. > > However if I call a setter on the parameter this change has > > dissapeared the next time I call getBinding().getObject(). > > > > I have avoided this problem by using an instance field with the > > parameter type and set it the first the the parameter is accessed. > > This works fine for the pre-render and render phase. > > > > The problem I am having now is with the combination of cleaning up the > > parameter and making changes available in an action (long after the > > render has finished). > > > > Maybe a little bit of pseudo-code will make things more clear want I > > would like... > > > > *Code:* > > > > private MyObject param; > > private MyObject getParam() > > { > > if (param == null) > > param = getBinding().getObject(); > > return param; > > } > > > > protected renderComponent() > > { > > getParam().setValue(1); > > .... > > } > > > > public action() > > { > > int x = getParam().getValue(); > > } > > > > > > > > My questions are: > > 1) Is it possible to keep the update in the object without having an > > instance variable? > > 2) How and when can I cleanup the instance variable (set it to null)? > > If I do it in cleanupAfterRender it means that the update is not > > available in the action handler. > > 3) Will the component object that is used for the action not always > > the same object used to render? And therefore instance variables > > should not be trusted between those phases? > > > > Any background information related to these topics is very welcome to > > increase my knowledge about Tapestry. > > > > TIA! > > Robert. > > > > > --------------------------------------------------------------------- > 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]
