wow - thanks for all the info! love that the compiler changes the name of the source each time - that will come in handy.
On Feb 11, 6:33 am, Eric Ayers <[email protected]> wrote: > 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 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 [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 -~----------~----~----~----~------~----~------~--~---
