Hi Igor,
Responses inline:
On Fri, May 15, 2009 at 3:47 PM, Igor Moochnick <igor.moochn...@gmail.com>wrote:
>
> You mean PACKAGE or MODULE? In fact I do use PACKAGEs.
I mean package.
>
>
> Because I'm actually using packages for my widgets and, in fact,
> that's what broken.
>
> This is how I've structured my code:
>
> com.myserver.client - all the usual client code
> com.myserver.client.widgets - here I put our custom widgets
> (and all the images related to them)
> com.myserver.client.widgets.images - this is where I WANT to put all
> the images so the upper level folder will be free
>
> Since, in Java, packages are directly related to the folder structure,
> the @Resource("images/Dialogue_Corner.gif") is broken and not working
> consistently across the OSes.
I know that if you use a backslash, that this works on Windows. However,
have you tested to see if this would work as-is in its current formulation
on Mac or Linux? The reason that I ask is that I suspect it would not. Even
though changing the forward slash to a backslash appears to fix the problem
on windows, it is an accident of the implementation of ImageBundleGenerator.
Here is the relevant chunk of code in ImageBundleGenerator:
// If the name has no slashes (that is, it isn't a fully-qualified
resource
// name), then prepend the enclosing package name automatically, being
// careful about the default package.
if (imgFileName.indexOf("/") == -1) {
String pkgName = method.getPackageName();
if (!"".equals(pkgName)) {
imgFileName = pkgName.replace('.', '/') + "/" + imgFileName;
}
}
So, you see, the code basically assumes that if there are any forward
slashes in the image name (where the image name is taken verbatim as the
value of the resource annotation), then it is assumed to be an absolute
reference. When you changed the slash to a backslash, the code here
determined that there were no forward slashes in the resource name, and
pre-pended the package name to the image file name. So, the fact that a
relative reference worked was accidental. Does that make sense?
>
> Thanks.
>
> On May 15, 3:30 pm, Rajeev Dayal <rda...@google.com> wrote:
> > You are correct - if you end up refactoring, you'll have to change the
> > references in the @Resource annotation. The only other way around this is
> to
> > place the images themselves in the same package as your ImageBundle, and
> > then you can use relative references.
> >
> > You can file a "Request for Enhancement" to support relative paths in
> > ImageBundle @Resource annotatios, if you'd like
> >
> > On Fri, May 15, 2009 at 1:53 PM, Igor Moochnick <
> igor.moochn...@gmail.com>wrote:
> >
> >
> >
> > > Interesting ... In fact I was actually trying to use the relative
> > > path.
> >
> > > The goal was to put the images (part of the application ImageBundles)
> > > with the classes/widgets that are using them and then extra "/images"
> > > folder (relative to the widget folder).
> >
> > > Then, if I put a full path, what are the best practices in
> > > refactoring? When I move the whole folder - all the full pathes will
> > > be broken.
> >
> > > Thanks for your responses.
> >
> > > On May 15, 1:45 pm, Rajeev Dayal <rda...@google.com> wrote:
> > > > Hi Igor,
> >
> > > > The problem is that the resource annotation will only understand
> either:
> >
> > > > 1) A file name relative to the package. This must only be a file
> name,
> > > not a
> > > > path
> > > > 2) A fully qualified path
> >
> > > > The problem is that you're using a relative path for the file, which
> will
> > > > not work. You have to use the fully-qualified form, with forward
> slashes.
> >
> > > > The fact that it works for Windows when using backslashes is an
> accident
> > > of
> > > > the implementation.
> >
> > > > Rajeev
> >
> > > > On Thu, May 14, 2009 at 12:46 PM, Igor Moochnick
> > > > <igor.moochn...@gmail.com>wrote:
> >
> > > > > This is the error I'm getting on the Jetty (hosted) server when
> > > > > opening my application:
> >
> > > > > [DEBUG] Loading an instance of module 'mymodule'
> > > > > [DEBUG] Rebinding com.mymodule.Myclient.Images
> > > > > [DEBUG] Invoking <generate-with
> > > > > class='com.google.gwt.user.rebind.ui.ImageBundleGenerator'/>
> > > > > [DEBUG] Analyzing method 'TopLeft' in type
> > > > > com.mymodule.Myclient.Images
> > > > > [ERROR] Unable to find image resource 'images/Dialogue_Corner.gif'
> > > > > [ERROR] Unable to load module entry point class
> com.mymodule.Myclient
> > > > > (see associated exception for details)
> > > > > [ERROR] Failure to load module 'mymodule'
> > > > > [ERROR] Deferred binding failed for 'com.mymodule.Myclient.Images';
> > > > > expect subsequent failures
> >
> > > > > On May 4, 5:21 pm, Rajeev Dayal <rda...@google.com> wrote:
> > > > > > Actually, the documentation says that GWT uses
> > > > > ClassLoader.getResource(..)
> > > > > > to locate images. As a result, the syntax that you use in the
> > > annotation
> > > > > > *should* be OS-agnostic. You should always use forward slashes (
> / )
> > > to
> > > > > > separate path components.
> >
> > > > > > Is that not working for you?
> >
> > > > > > On Fri, May 1, 2009 at 6:20 PM, Igor Moochnick <
> > > igor.moochn...@gmail.com
> > > > > >wrote:
> >
> > > > > > > I have a relative path use in the @Resource attribute on my
> image
> > > > > > > bundle. Apparently the direction of the slashes are important
> and
> > > > > > > depend on what OS I'm building my project.
> >
> > > > > > > On Windows it has to be "\" and on Linux - "/".
> >
> > > > > > > public interface Images extends ImageBundle
> > > > > > > {
> > > > > > > @Resource("images/Dialogue_Corner.gif")
> > > > > > > AbstractImagePrototype TopLeft();
> > > > > > > }
> >
> > > > > > > The documentation mentions that the GWT uses System.getResource
> > > method
> > > > > > > to locate the images.
> >
> > > > > > > Any idea how to make it OS independent?
> >
> > > > > > > BWT: if the application written correctly on the Windows, it
> should
> > > > > > > pick the Linux slash "/" with no problem, but, apparently, Java
> > > > > > > getResource is not the case.
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
