On Wed, Feb 11, 2009 at 6:12 AM, chip <[email protected]> wrote: > > 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?
Since you are running in hosted mode, we re only using the deployed code for what is in the gadget specification (the gadget.xml) and for serving external resources (images, css files and the like) Everything else is coming out of your local workspace, and running from the Java class files and JSNI that is a part of your source. So if you change the source code, for the most part, you only need to 'refresh' the hosted mode browser so it rescans your source & class files. If you make a change that impacts the gadget spec or resources, you'll have to stop, compile the app, and re-deploy it to your remote host. > 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? This isn't much of a problem with the code parts of your project. Each time you compile your project, the code is generated as a 'unique' name, so your old app and new app should get along fine. Just upload the new files in the same directory and shouldn't have to worry about it too much. You can go back and clean up old .nocache.js files later. One thing you do have to be careful of is the caching of images. If update an image and leave the name the same, obviously that could cause problems serving up the older version of your app. > > 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. Exactly. > 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. I know that the trunk of incubator its intended to stay current with the latest releases of GWT, which today is 1.6.0. The pieces of the incubator that are kind of like little independent parts - they are just bundled together into one library for ease of maintenance. Thus, they are at different levels of maturity. > On Feb 6, 8:04 am, Eric Ayers <[email protected]> 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 <[email protected]> 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/ > > > -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
