So how do I use the GWT with Gears?

[GWBasic]

I have a silly noob question...

How do I use the GWT with the Gears API?

Specifically, I'm interested in making the output of GWT's compiler
available offline. Because the filenames generated by the compiler
aren't known until *after* the application is compiled, it's
impossible to use a simple approach of hardcoding my filenames into my
GWT application. (EX, I can't hardcode a reference to
"B3B1E49B7F67A96D16BCC7564586D584.cache.js" because the filename isn't
known until after compilation.)

I really need keep everything simple at this point; I'd like to stick
to calling resourceStore.captureURL(...) inside of GWT code.

Is a compiled GWT application aware of its filenames? Is it possible
to obtain some kind of a list of filenames that I can iterate over
inside of the GWT?

For example, I'd like to know at runtime that
"B3B1E49B7F67A96D16BCC7564586D584.cache.js" is a file that belongs to
my application, so I can pass it to resourceStore.captureURL(...).

Again, I'm trying to keep everything simple.

Thanks!

[bly...@googlemail.com]

On Jul 16, 12:17 am, GWBasic <goo...@andrewrondeau.com> wrote:
> I have a silly noob question...
>
> How do I use the GWT with the Gears API?
> Specifically, I'm interested in making the output of GWT's compiler
> available offline. Because the filenames generated by the compiler
> aren't known until *after* the application is compiled, it's
> impossible to use a simple approach of hardcoding my filenames into my
> GWT application. (EX, I can't hardcode a reference to
> "B3B1E49B7F67A96D16BCC7564586D584.cache.js" because the filename isn't
> known until after compilation.)

Hardcoding is generally a bad idea, especially if you like to keep
things simple.

> I really need keep everything simple at this point; I'd like to stick
> to calling resourceStore.captureURL(...) inside of GWT code.
>
> Is a compiled GWT application aware of its filenames? Is it possible
> to obtain some kind of a list of filenames that I can iterate over
> inside of the GWT?

I guess not. You could browse the server's directories but that's not
a clean solution.

> For example, I'd like to know at runtime that
> "B3B1E49B7F67A96D16BCC7564586D584.cache.js" is a file that belongs to
> my application, so I can pass it to resourceStore.captureURL(...).

I wonder what you are trying to do. If you could specify what you like
to achieve somebody might help you.

[Sumit Chandel]

Hi GWBasic,

There are two ways to tell the LocalServer module to cache and serve
your resources.

The first method is to use the ResourceStore, which is the approach
you've described above. This would consist of calling
resourceStore.captureURL(...) and passing in the urls to the resources
you want to cache and serve. As you've discovered, the problem with
using this method for capturing GWT-generated files is that the actual
name of the files are unknown until after GWT-compilation.

If you were to say this is a cumbersome method to capture URLs, I
would agree with you :-) That's why I would recommend using the second
method for caching files to the LocalServer: using the
ManagedResourceStore.

With this method, you can simply specify the resources you wish to
cache in the manifest file. You will still need to run a
GWT-compilation to get the actual filenames, but now you just update
the manifest file with the generated resource names. This method is
also convenient for versioning your resources as you go through
revisions of your GWT code down the road.

Furthermore, you might find it worthwhile to create a little script
that could generate the manifest file after running your GWT
compilation. The manifest file format is very similar to JSON so it
should be quite easy to script.

Despite the manifest approach making things easier, however, there are
still issues with this method. Namely, if you script the manifest
file as I just described, you will end up with "*.cache.html" in the
file, which means that EVERY browser will download and store EACH
permutation, even the ones it will never use. This defeats some of
the purpose in having the multiple permutations in the first place.
You could write custom manifest files for each permutation, but then
you run into the problem of having to identify which manifest belongs
with which permutation.

These are all problems that we are aware of in the GWT/Gears library,
and we'll address them at some point in the future. Right now the
team is focused on 1.4, and so will be devoting more time to reaching
that milestone.

If you would like to go for the manifest file approach, I would
suggest you take a look at the ManagedResourceStore details at the
link below:

http://code.google.com/apis/gears/api_localserver.html#ManagedResourceStore

Although Gears is exposed as an API library for GWT, the functionality
is the same as what's described on the official Gears site.

Hope that helps,
-Sumit Chandel

[GWBasic]

Thanks. I ended up using the manifest approach. (I declare my
manifest after compiling.)

I was hoping I could do something that was much simpler; I'm really
just making a demo to explore what GWT and Gears are capable of. (I'm
not writing any production-grade code at this time.)

The demo is here: http://andrewrondeau.com/com.Memmexx.GearPod/GearPod.html
It's just a simple music demo; I used music that I have complete
copyright control over, although I must admid that I'm glad I chose a
career as a Software Engineer instead of as a musician!

> http://code.google.com/apis/gears/api_localserver.html#ManagedResourc...

[Miguel Méndez]

FYI, I created issue 6 yesterday to track this problem.  Feel free to updated with any suggestions, clarifications, etc.

Cheers,

--
Miguel