Updating properties in server-side code

How does one "register" a property as something to be monitored by the UpdateManager? While implementing the server-side components for EchoPoint, I ran into this issue with updates to properties not being sent over by the sync service. The only way to force an update of the client seems to be to do a full re-render by removing the component from its parent and re-adding. The components I am dealing with do not receive updates from the client, but are updated as the result of action handling (eg. HttpPane updating its URI).

Can you give some more

Can you give some more detail? All properties that are changed through Component.setProperty() should be picked up by the UpdateManager and sent down to the client. If you use the system property syncdump=true, do you see that the property update is missing?

No, there is not much

No, there is not much information in the server message. The property is set using the usual routine:

  public void setURI( String uri )
  {
    setProperty( PROPERTY_URI, uri );
  }

You can view a test file here. At the very end of the file is the even listener with the replace and add code necessary to get the change required.

The response message after button click is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<cmsg xmlns="http://www.nextapp.com/products/echo/svrmsg/clientmessage.3.0">
<dir proc="CFocus">
<focus i="c_10"/>
</dir>
<dir proc="CSync">
<e i="c_10" t="action"/>
<p i="c_9" n="text">http://sptci.com/</p>
</dir>
</cmsg>
<?xml version="1.0" encoding="UTF-8"?>
<smsg xmlns="http://www.nextapp.com/products/echo/svrmsg/servermessage.3.0" i="3">
<libs/>
<group i="init"/>
<group i="update">
<dir proc="CSyncUp">
<up i="c_echopointUnitTestHttpPane"/>
</dir>
<dir proc="CFocus">
<focus i="c_10"/>
</dir>
</group>
</smsg>

My client sync peer code for renderUpdate is as:

renderUpdate: function( update )
  {
    var property = update.getUpdatedProperty( echopoint.HttpPane.URI );
    if ( property )
    {
      this.component.set( echopoint.HttpPane.uri,  property.newValue );
      this._iframe.src = this.component.get( echopoint.HttpPane.URI );
    }
  },

I tried without checking the update.getUpdatedProperty also with same results. The equivalent test for client-side application works fine.

You should not have to call

You should not have to call this.component.set manually, the new value is already set. Just using
this._iframe.src = property.newValue; should do the trick. Server-side looks fine, the update is sent down. Check if property.newValue contains the expected value. If all looks okay, try reproducing this in standalone HTML/JS, particularly updating the src attribute of the iframe-element.

The equivalent test code for

The equivalent test code for the client-side component work fine. You can see the test JS code here. Tracking this a bit further, it appears that my renderUpdate is not being called at all when run as a server-side application. An alert message at entry of renderUpdate does not fire.

What's the name of the

What's the name of the property? In the server output, we see 'text'. I expected something like 'uri'.

Edit: I reviewed your source, the server-side property should be 'uri' to match the client.

Which file did you notice

Which file did you notice the discrepancy in? My HttpPane.java has

public static final String PROPERTY_URI = "uri";

The text property in the message is from the client message (the text of the TextField used to update the URI), right?

You are right, I looked at

You are right, I looked at the wrong file. One last guess: try renaming the setter to setUri(). I think Echo uses the bean conventions to determine the available properties. If this does not help, set a breakpoint in UpdateManager.processComponentPropertyUpdate and see if that code is even reached.

Case did it

The change of case to setUri did it. I don't remember if update worked with the old EPNG component, but it used upper case URI which I preserved. Thanks for your help.

Rakesh

Back in the Echo2 days,

Back in the Echo2 days, developers had to specify which properties to sent down themselves. So case didn't really matter there. I'm not too familiar with the bean-spec, I don't know if setURI should have worked.

Glad you solved it.

I had the similar problem

I had the similar problem previously, after changin the case, it worked fine but it took a lot of time to find this out.

Regards,
Pawan