Directory detection in nocache.js

[Russell]

My GWT/forplay project has stopped working. The project/
project.nocache.js file makes the browser request md5hash.cache.html,
rather than project/md5hash.cache.html. (It tries to load from one
directory too high.) This results in a 404, of course. I have seen
this across browsers, and even across servers.

Can anybody with nocache.js knowledge take a guess at why it now fails
to point the browser to the right place for the cache.html file?

Thank you,

Russell

[Russell]

I think this might be a GWT issue. I've tracked it as far as the
removal of tryMarkerScript() from computeScriptBase.js r10045:

http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js?r=10045

If I add that function back in, everything works fine. I'm not sure
why the other methods of directory detection aren't working, but I
assume there was a reason this function was present in the original
code. The code review on r10045 raises some questions that haven't
been answered; I guess I don't understand the Google review process.

Thanks.

[unnurg]

Hi Russel - tryMarkerScript was removed from the new xsiframe linker.
It's still present in the old, default linkers, but the new xsiframe
linker needs to support Late Loading by default, which crashes when
you do a document.write() and so we decided to remove this detection.
Apologies that the comments didn't make it into the review thread, it
was a rather lengthy discussion that we ended up having offline with
various members of the team.

I believe that you saw the break recently, because ForPlay was
recently switched from the old linker to one of the new xsiframe based
ones (I believe it uses the direct_install one, or the xsiframe one).
I believe that switch was made because the new linker also supports
CrossSite by default, and ForPlay needed this functionality.

Note that if you don't do anything fancy, the other mechanisms should
catch the right path, so in *most* cases, tryMarkerScript is not
needed. However, if you've renamed something and none of the other
functions are triggering, then the easiest thing is to simply set a
base or meta tag that will make sure that computeScriptBase works.

I've also added Fred to the thread, since I don't know that much about
ForPlay, and he's the one that switched ForPlay to the new linker, so
he may have additional info and/or corrections.

- Unnur

On Jun 16, 8:55 am, Russell <seventysev...@gmail.com> wrote:
> I think this might be a GWT issue.  I've tracked it as far as the
> removal of tryMarkerScript() from computeScriptBase.js r10045:
>

> http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/c...

>
> If I add that function back in, everything works fine.  I'm not sure

> why the other methods ofdirectorydetectionaren't working, but I

[Fred Sauer]

I'll add some context:

ForPlay has an optional AppCacheLinker, which extends the DirectInstallLinker.
ForPlay's SVN repository has a pair of svn:externals links, so it can track changes in GWT trunk linker changes, since the latest DirectInstallLinker fixes have not yet been released into a GWT SDK.

If your ForPlay project does not need the AppCacheLinker your .gwt.xml file need to contain a linker override, i.e. something like this:

  <add-linker name="appcachelinker"/>

--

Fred Sauer

Developer Advocate

Google Inc.

1600 Amphitheatre Parkway

Mountain View, CA 94043
fre...@google.com

[Russell]

Thanks for replying!

I think I was on the wrong track, but your comments were still
helpful. Now I realize the reason I saw a change in my project is NOT
the missing detection method, but rather that computeScriptBase() no
longer sets base directly.

So even if the detection routines work (which they do for me now), the
base is never set, because whatever is calling them (the linkers I'm
using?) ignores the return value, expecting it to set the variable
directly.

Russell