Re: undefined.cache.js when starting GWT app in web mode?

If you compile in PRETTY instead of DETAILED, it won't intern those strings, but still will leave the output mostly readable (just no packages).

Without seeing the rest of the structure of the module files, it is hard to speculate, but we're using more or less the same idea successfully, though we're doing it backward. Inside of GXT we defined a broader set of user agents, and then distill down to just the 6 (as of gwt 2.4, 2.5) permutations that GWT itself supports. This takes over GWT's own property-provider and uses ours instead. The chief difference is that user.agent already has a property-provider, but we're trying to instruct it which property to use instead.

In lieu of your full module/setup, here's a quick sample I threw together that seems to do more or less what you are requiring, and seems to fail in the same way:

<module rename-to="test">
  <inherits name="com.google.gwt.core.Core" />

  <define-property name="foo" value="a, b, c" />

  <define-property name="bar" value="x, y" />

  <set-property name="bar" value="x">
    <any>
      <when-property-is name="foo" value="a" />
      <when-property-is name="foo" value="b" />
    </any>
  </set-property>
  <set-property name="bar" value="y">
    <when-property-is name="foo" value="c" />
  </set-property>

  <property-provider name="foo"><![CDATA[return window.location.query;]]></property-provider>

  <entry-point class="path.to.client.Test" />
</module>

public class Test implements EntryPoint {
  @Override
  public native void onModuleLoad() /*-{
    console && console.log && console.log('loaded successfully');
  }-*/;
}

The foo provider is compiled out as expected:
  providers['foo'] = function(){
    return window.location.search[1];
  }

but bar gets a default handler, one that clearly doesn't make sense here:
  providers['bar'] = function(){
    return __gwt_getMetaProperty('bar');
  }

By adding <set-property name="bar" value="x" />, the code works, but it doesn't correctly select a y value when it should (the permutation selector code is just gone).

Through any case where bar is present in the selector, I continue to see this block:
      unflattenKeylistIntoAnswers(['x', 'a', 'gecko1_8'], '20D7C847BEB9A7D69CDF024B3FA7AE54');
      unflattenKeylistIntoAnswers(['x', 'b', 'gecko1_8'], '20D7C847BEB9A7D69CDF024B3FA7AE54');
      unflattenKeylistIntoAnswers(['y', 'c', 'gecko1_8'], '20D7C847BEB9A7D69CDF024B3FA7AE54');
      unflattenKeylistIntoAnswers(['x', 'a', 'ie9'], '2F5083A323F0E99E2BC83F08F6D97D35');
      unflattenKeylistIntoAnswers(['x', 'b', 'ie9'], '2F5083A323F0E99E2BC83F08F6D97D35');
      unflattenKeylistIntoAnswers(['y', 'c', 'ie9'], '2F5083A323F0E99E2BC83F08F6D97D35');
     //etc
demonstrating that the 'collapsing' work is being done - there is never a x-y, nor a y-a/y-b line. From this, I'm suspecting that the design of this feature is to minimize permutations, not remove selector scripts altogether - from http://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties,

"This alternateFeatures property is called derived because its value can be determined solely from other deferred-binding properties. There is never a need to execute a property provider for a derived property. Moreover, derived properties do not expand the permutation matrix and have no deployment cost."

Misleading, not not actually inaccurate - there *isn't* a need to execute the property provider, but the current implementation seems to still do it anyway, and fails when it cannot be done. The only advantage we are getting out of conditional properties is the minimized set of permutations.

On Monday, October 28, 2013 11:23:02 AM UTC-5, Ed wrote:

I didn't think it would help, but I just added a default browser.engine property to the BrowserEngine.gwt.xml file, just below the <define-property...:

<set-property name="browser.engine" value="webkit" /> <!-- provide a default as last resort -->

Strange enough this does help, as it does starts now.

The code to determine the strong name has changed to:

 strongName = answers[computePropValue($intern_47)][computePropValue($intern_58)];

As you can see the "browser.engine" property has been removed as argument. Before it was:

 strongName = answers[computePropValue($intern_47)][computePropValue($intern_48)][computePropValue($intern_59)];

Why this difference?

btw: it seems to work in both chrome/FF.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.