Thanks Eric! for the time being it sounds like the solution for me is just some textual post-processing outside of the GWT.
Right now I'm just trying to wrap my head around the GWT - it always takes a moment when trying to dive in head first with a new tool. As for CSS I'm actually pretty minimalist myself and am just starting to delve into that as well - the main reason being that's what's necessary to skin the GWT widgets. I don't think I have anything new to add feedback wise at this point, but know that I think the GWT is a great tool and I'm really looking forward to using it specifically on the gadgets front. Like any gadgeteer out there I think the main things I consider when developing a gadget is that it's fairly lightweight - given that it's being loaded on a page with a lot of other stuff going on. And secondly that there is a little direct interaction with my server as possible. The google proxy is amazing, and being careful to design/code in a way that makes full use of it is a requirement given my hosting situation. Thanks for all the work with the gadgets gwt library - it took me a moment - but once I got it setup I was impressed with the way it bypassed google's caching mechanism. I only half understand what's going on: maybe if you have a moment you can provide some insight. So the first thing you do is upload your compiled code. Then according to the docs: For most changes, you can make changes to your Java code and use the Refresh button on the hosted mode browser to see your changes I tried this - and it works! How exactly is it working? I assume the GWT browser does a fancy switch where it has the running gadget mapped to the local resource. When you say most changes - what is a change that wouldn't work with a simple refresh? And then is the answer to re- compile and re-upload? Also - since the project spans multiple files - when caching there is the whole sync issue - Am I understanding it correctly that the main problem is if you upload a new version of your code and the google proxy refreshes the cache on your files at different times you may end up with new code referring to the old code and vice versa? Historically if I've had such a problem I would create version 2 of my gadget as follows: Updating the main gadget spec (xml) with the same filename as the v1 - in the spec where external resources were identified I would rename them possibly with a _v2 in the file name. The result is that when I upload v2 I don't overwrite any of the dependencies. So while the spec remains cached it's dependencies are available even if they get refreshed first. Then when the spec gets refreshed it pointing at the new v2 files that will get cached the first time they are requested. Is there some other way that most people operate? If not I would think it would be useful to include that sort of versioning into the compiler. Obviously in development you don't want to create tons of redundant files. But if the compiler could take a flag that would indicate to append a token to the end of dependent files and source them as such from the main file - that would be cool! Anyway, there's a lot of traffic on this group - I'm going to do my best to keep up with it and as with everything experience is the best teacher so wish me luck ;) btw - thanks for pointing out the incubator - looks like a great resource. Quick question - how bleeding edge is the incubator library? In terms of chance of encountering bugs and frequency of updates to the library. On Feb 6, 8:04 am, Eric Ayers <zun...@google.com> wrote: > I just wrote the FAQ item yesterday, so I haven't a chance to explore > a lot of different options. > > If you want to go the absolute path way, you could also use an > external script that does some text processing (perl, python, sed) to > substitute variables into your css from before deploying it. > > Another way to solve this is to use the Stylesheet Injector (currently > in the incubator) and processing the stylesheet text and doing some > substitution with _IG_GetCachedUrl(). > > I would appreciate feedback on these or other options for making > stylesheets work better with gadgets. This is a place where GWT could > add a lot of value. > > > > On Fri, Feb 6, 2009 at 1:51 AM, chip <ginga.gadg...@gmail.com> wrote: > > > ;) > > > In the FAQ it explains how GWT references a CSS file with relative > > image paths. > > > When the GWT app in question is a gadget it is hosted through a proxy > > by the gadget container and all the relative image paths break. > > > There are two issues here. > > > 1) It would be nice if there was a way to indicate where the final > > home of the images would be so that the GWT compiler could build > > absolute paths > > > 2) It would be even better if the reference to the images were wrapped > > in calls to _IG_GetCachedUrl() - I'm not sure if this is possible with > > an external CSS file, but I know it can be done when the CSS is > > inline. > > > Any info on if these issues are being addressed? > > > Any thoughts on solutions/hacks in the meantime? > > > I guess worst case I can just inline the CSS manually - but hey, I'm > > lazy :) > > > thanks for the help/info! > > -- > Eric Z. Ayers - GWT Team - Atlanta, GA USAhttp://code.google.com/webtoolkit/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
