Ray,

At UI-binding time, I don't know the values for the two params I need
to pass to my Applet. Actually, I do know them, but they come from the
URL query string and can't be passed to GWT.create().

My current working theory on the IE issue though is this:

* The moment UiBinderUtil.fromHtml() inserts the HTML into the DOM, an
instance of the ActiveX plugin is instantiated.
* Since I have not yet provided the values for my params, the plugin
gets whatever is there at that time (in my case, empty strings).
* Although the HTML is then removed from the DOM, because JavaScript
still has a reference to it, it isn't garbage collected, and thus the
ActiveX instance remains running, detached from the page.
* When the HTML is eventually re-inserted in it's final location, the
plugin is re-attached as well, with the wrong param values.
* I suspect IE does not allow changes to the attributes and children
of an <object> tag once activated, or at least the changes are not
propagated to the instance of the plugin that is already running.

This would explain why IE8's Developer Tools showed the correct DOM
structure, but the plugin did not have the correct values.

To test this, I tried adding an <object> tag to the page without a
classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" attribute at UI-
binding time. My thinking was that this would prevent the plugin from
activating until I inserted the <object> where I wanted it and added
the missing attribute. Unfortunately, that just caused the plugin to
never start.

If my theory here is correct, there would only seem to be one
reasonable solution to this: place the necessary param values into the
HTML before UiBinderUtil.fromHtml adds the text to the DOM (and parses
it). For that to work, there would have to be a way to alter the
ui.xml dynamically at runtime, using a templating mechanism of sorts.
It could be something as simple as the String filtering methods that
Dojo offers:
http://api.dojotoolkit.org/jsdoc/1.3.2/dojo.string.substitute

According to the documentation I found here:
http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html#Using_a_widget
It would seem that constructor arguments can only go one way: from the
XML to a Java class. Maybe I missed something - is there a way to use
values on the Java class in the ui.xml? A templating mechanism of
sorts? If so, perhaps I could do something like:
<param name="uri" value="${uri}" />

(Perhaps that isn't such a nutty idea, you know?)




On Dec 14, 6:13 pm, Ray Ryan <rj...@google.com> wrote:
> If you're still game, you could debug UiBinderUtil.fromHtml itself. Perhaps
> we're discovering interesting side effects of attaching and detaching
> <object> dom objects?
>
> Another thought: are the lost param objects the ones that you tried to put
> ui:fields on? Those will be the ones with id='" + domId1 + "' fragments in
> them.
>
> On Tue, Dec 15, 2009 at 3:25 AM, jarrod <jarrod.carl...@gmail.com> wrote:
> > Ray,
>
> > Good suggestion. I checked it out, but here's what I found:
>
> > * The generated code (UploaderWidgetImplIE_BinderImpl.java) does
> > contain all of the HTML necessary. Here is an excerpt:
>
> > ...
> > com.google.gwt.dom.client.ObjectElement f_object1 =
> > (com.google.gwt.dom.client.ObjectElement) UiBinderUtil.fromHtml
> > ("<object classid='clsid:8AD9C840-044E-11D1-B3E9-00805F499D93'
> > codebase='http://java.sun.com/update/1.6.0/jinstall-6u16-windows-
> > i586.cab#Version=6,0,0,1' height='350' name='Uploader'
> > width='100%'><param name='code'
> > value='org.jets3t.apps.uploader.Uploader.class'> <param
> > name='codebase' value='.'> <param name='archive' value='uploader-0.7.1-
> > signed.jar,jets3t-0.7.1-signed.jar,jets3t-gui-0.7.1-signed.jar,commons-
> > codec-1.3-signed.jar,commons-httpclient-3.1-signed.jar,commons-
> > logging-1.1.1-signed.jar'> <param name='type' value='application/x-
> > java-applet;version=1.6'> <param name='scriptable' value='false'>
> > <param name='mayscript' value='false'> <param id='" + domId0 + "'
> > name='uri' value=''> <param id='" + domId1 + "' name='token' value=''>
> > No Java Support.</object>");
> > ...
>
> > * The innerHTML alone isn't the problem. It must be with the way GWT
> > is handling it. To test this, I ran the following successfully in IE8
> > (where the GWT code fails):
>
> >        <div id="uploader"></div>
>
> >        <script type="text/javascript">
> >          var template = '\
> > <object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"\
> >    name="Uploader" width="100%" height="350"\
> >    codebase="http://java.sun.com/update/1.6.0/jinstall-6u16-windows-
> > i586.cab#Version=6,0,0,1">\
> >    <param name="code"
> > value="org.jets3t.apps.uploader.Uploader.class" />\
> >    <param name="codebase" value="." />\
> >    <param name="archive"\
> >        value="uploader-0.7.1-signed.jar,jets3t-0.7.1-
> > signed.jar,jets3t-gui-0.7.1-signed.jar,commons-codec-1.3-
> > signed.jar,commons-httpclient-3.1-signed.jar,commons-logging-1.1.1-
> > signed.jar" />\
> >    <param name="type" value="application/x-java-applet;version=1.6" />
> > \
> >    <param name="scriptable" value="false" />\
> >    <param name="mayscript" value="false" />\
> >     <param ui:field="uriParam" name="uri" value="foo" />\
> >    <param ui:field="tokenParam" name="token" value="bar" />\
> >    No Java Support.\
> > </object>';
> >          document.getElementById('uploader').innerHTML = template;
> >        </script>
>
> > When assigning the innerHTML all at once as above, it seems to run
> > fine.
>
> > I suppose as a next step I could try building the HTML
> > programmatically, or just doing like above and slapping a big string
> > into place...
>
> > Any other ideas?
>
> > On Dec 13, 4:43 pm, Ray Ryan <rj...@google.com> wrote:
> > > Thanks for the interesting use case!
>
> > > I suspect you're discovering limitations in IE's innerHTML support, but
> > > that's just a guess. The first thing to do is look at the generated
> > > implementation of UploaderWidgetImplIE.Binder, and see if the missing
> > bits
> > > are missing there too.
>
> > --
> >http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to