This would work, except for backwards compatibility. If we put in this
change, then all of those people that were using fully-qualified names
without the leading slash would run into problems. Another way to handle
this might be to add another piece data to the annotation to indicate that
the path is relative as opposed to absolute.
Or, we could maybe go with your suggestion, but then have a fallback
algorithm - if there is no leading slash, assume that the path is relative
to the package. If no resource can be found, assume that it's absolute.
On Fri, May 15, 2009 at 4:11 PM, Igor Moochnick <igor.moochn...@gmail.com>wrote:
>
> It does, actually, makes scene.
>
> If I may, I'd like to suggest the way to fix it. Usually when the path
> starts with "/" (slash) it considered to be an ABSOLUTE path, but, if
> it does't, it considered to be a RELATIVE one. So the code can be
> changed like this [pseudocode]:
>
> if (imgFileName.starts_with("/"))
> {
> // USE THE PATH AS AN ABSOLUTE ONE
> }
> else
> // RELATIVE PATH IN ANY OTHER CASE
> {
> String pkgName = method.getPackageName();
> if (!"".equals(pkgName)) {
> imgFileName = pkgName.replace('.', '/') + "/" + imgFileName;
> }
> }
>
> How about this?
>
> On May 15, 4:03 pm, Rajeev Dayal <rda...@google.com> wrote:
> > 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
-~----------~----~----~----~------~----~------~--~---
