Modify the property of an object via Deferred Binding

[jonl]

I am using DeferredBinding to create the instance of an interface.  Now there is a property on the instance that is instantiated that I would like to change for every object created of that type via the GWT.create() call.  Is there a way in the <replace-with> settings to do this, without overriding the class?  Or is there a way to read a property defined in the .gwt.xml using the <set-property> tag at runtime?

[Ignacio Baca Moreno-Torres]

I think that you need to use a Generator. http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsDeferred.html#generator

[Jens]

Ignacio is right. Use a Generator that generates an implementation of your interface and implements the interface methods based on some property value (generators have access to properties). If your implementation is generally the same except some small changes then you can also create an abstract class that implements your interface and then generate a sub class which only implements the property specific changes.

Since properties only exist at compile time you need to generate property specific code. You can not do that at runtime.

-- J.

[jonl]

I was hoping for something other than a generator.  I only need to change one property after instantiation, and only sometimes, at this point and it seems like a lot of work to write a generator to do that.  I'd likely just create an override of the class at this point and update the rebind that already exists.

It would be awesome if the gwt compiler would support something along these lines:

<replace-with class="com.my.FavoriteImplementation">

<when-type-is class="com.SomeInterface"/>

                <set-object-property type="boolean" value="false" name="turnFeatureOn"/>

                <set-object-property type="string" value="MyPrimaryStyle" name="defaultStyle"/>

                <set-object-property name="complexProperty" provider="com.my.ComplexPropertyProvider"/>

</replace-with>

This might actually reduce the need for custom generators and make customization via GWT.create a bit more powerful.

[Jens]

It would be awesome if the gwt compiler would support something along these lines:

<replace-with class="com.my.FavoriteImplementation">

<when-type-is class="com.SomeInterface"/>

                <set-object-property type="boolean" value="false" name="turnFeatureOn"/>

                <set-object-property type="string" value="MyPrimaryStyle" name="defaultStyle"/>

                <set-object-property name="complexProperty" provider="com.my.ComplexPropertyProvider"/>

</replace-with>

This might actually reduce the need for custom generators and make customization via GWT.create a bit more powerful.

What about:

public abstract class AbstractImplementation implements SomeInterface {

  public AbstractImplementation(boolean turnFeatureOn, String defaultStyle, ComplexProperty complexProperty) {

     // store as fields

  }

} 

public class FavoriteImplementation extends AbstractImplementation {

  

  public FavoriteImplementation() {

    super(false, "MyPrimaryStyle", new DefaultComplexProperty);

  }

}

public class SometimesDifferentImplementation extends AbstractImplementation {

  

  public FavoriteImplementation() {

    super(true, "MySecondaryStyle", new CustomComplexProperty);

  }

}

<replace-with class="com.my.FavoriteImplementation">

  <when-type-is class="com.SomeInterface"/>

</replace-with>

<replace-with class="com.my.SometimesDifferentImplementation">

  <when-type-is class="com.SomeInterface"/>

  <when-property-is name="sometimes" value="different" />

</replace-with>

-- J.

[Jonathon Lamon]

Sure, thats one way to do it and I know that is the pattern in most uses of the rebinder mechanism, but to me, it almost seems to be an anti-pattern that is neglecting the power that exists under the hood.  The reason is that you aren't really creating a new implementation of the logic, so i feel that having to create a class to set a property is a bit redundant/ridiculous.

I could see if you programmatically caused the object to be replaced and GWT did not provide for any kind of property configuration already that having it done all in code would be sound a sound process.  However, gwt provides facilities for setting compiler and configuration properties that could be leveraged and seeing as you have to maintain the rebinding and the class that overrides the properties and the class that is the actual implementation, I think the simplification is to allow setting properties of rebound objects through the rebind process.  Then you only have to maintain the .gwt.xml where the rebind occurs, then the interface, then 1..x implementations of logic instead of y * (1...x) implementations of logic -> property configurations.  It would also make rebound classes more reusable in that if both you and I wanted to set the property on a rebound object, we both wouldn't have to override the class in the same manner in order to do so.

Jonathon Lamon
Principle Software Engineer
Perceptronics Solutions Inc.
Tel  703-485-2922
Cell 269-205-4649
www.percsolutions.com

-- J.

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/_MBUHniKSI8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jens]

The reason is that you aren't really creating a new implementation of the logic, so i feel that having to create a class to set a property is a bit redundant/ridiculous.

Yeah maybe my example is a bit off. I think in reality I would have created a configuration interface that has getters for each config value and then provide different implementations of that configuration interface. Then I would pass in that configuration to the real class that contains the logic. IMHO that feels a lot better to me since you don't end up with empty sub classes only to call a super constructor with different parameters. It is also a lot more descriptive.

For such configuration classes, writing a generator is really easy. GWT actually has a generator that kind of does what you want. Take a look at UserAgentGenerator which generates an implementation of UserAgent. The generator code that produces UserAgent.getCompileTimeValue() is exactly what you need to generate a configuration class that simply returns compile time XML property values.

-- J.

[Jonathon Lamon]

I am no stranger to generators and/or annotation processors.  I think, if that is "really easy" then what I am proposing is the equivalent of "a goldfish could do it" (this is a favorite saying of one of my professors in college, the one that taught mainframe assembly).  

The generator that uses the compile time file feels like a better solution, but I think that something that does that for you should be part of the framework.

I think I will go that route though and when it's good enough, maybe I'll offer it up as a patch.  Was just hoping that there was already something in place that I was missing.

Jonathon Lamon
Principle Software Engineer
Perceptronics Solutions Inc.
Tel  703-485-2922
Cell 269-205-4649
www.percsolutions.com

--