http://gwt-code-reviews.appspot.com/1370808/diff/1010/gadgets/src/com/google/gwt/gadgets/linker/installGadgetsScript.js
File gadgets/src/com/google/gwt/gadgets/linker/installGadgetsScript.js
(right):

http://gwt-code-reviews.appspot.com/1370808/diff/1010/gadgets/src/com/google/gwt/gadgets/linker/installGadgetsScript.js#newcode38
gadgets/src/com/google/gwt/gadgets/linker/installGadgetsScript.js:38:
script.src = $wnd.gadgets.io.getProxyUrl(filename);
I think I see what you are suggesting.  You are saying I modify the
xsilinker and add a hook, then use the hook.  If I hurry, that could
make it into 2.3, right?  Because galgwt users in general only use
released versions of GWT.  (In fact, I got an earful for suggesting that
some changes would only work with 2.2.0 and beyond!)

On 2011/03/10 20:51:20, unnurg wrote:
It seems heavy handed to me for you to maintain whole copies of
installScriptEarlyDownload and loadExternalStylesheets.js just to make
this one
line switch in each of them.  Also - in order to make devmode work, I
think
you'll need to do this switch for line 45 of permutations.js (where we
reference
the devmode.js file).

At a minimum, I think you want to override permutations.js and update
the
devmode.js and md5.js paths there, rather than overriding this file
and updating
the md5.js filepath here.

What I think is a better long term solution, would be the following:

  - Add a function called getFullUrl(path) {  return
__MODULE_FUNC__.__moduleBase
+ path; }  to the xsiframe linker.  For now, it's probably convenient
enough to
add that function to computeScriptBase.js if you don't want to set up
a whole
new .js include.

- Do a code search to find all the places where the linker does a
__MODULE_FUNC__.__moduleBase + something, and replace it with a
getFullUrl(something); call (I believe there's only 3 places where we
do that,
and all 3 are the places you need to override anyway.

- In your overridden computeGadgetsBase.js file, override the
getFullUrl()
function to do the getProxyUrl() call rather than appending the path
to the
moduleBase


Does that sound like it would work?  It covers all the changes that I
noticed in
these files, although it's possible that I missed something.  It's a
little more
upfront work, but I think that long term, it'll make maintaining this
linker a
lot easier...

http://gwt-code-reviews.appspot.com/1370808/diff/1010/gadgets/src/com/google/gwt/gadgets/linker/processGadgetsMetas.js
File gadgets/src/com/google/gwt/gadgets/linker/processGadgetsMetas.js
(right):

http://gwt-code-reviews.appspot.com/1370808/diff/1010/gadgets/src/com/google/gwt/gadgets/linker/processGadgetsMetas.js#newcode33
gadgets/src/com/google/gwt/gadgets/linker/processGadgetsMetas.js:33: *
place in the gadget linker to propagate gadget logic.
(not an exact copy, see below)

On 2011/03/10 20:51:20, unnurg wrote:
So the problem with putting this here is that now you're maintaining a
copy of
all of the processMetas logic, and if that changes, you won't get
updates.
Would it make more sense if we put in an "arbitrary JS" hook into the
xsiframe
linker, so you could just override that (which would be empty by
default) rather
than the processMetas JS?

http://gwt-code-reviews.appspot.com/1370808/diff/1010/gadgets/src/com/google/gwt/gadgets/linker/processGadgetsMetas.js#newcode41
gadgets/src/com/google/gwt/gadgets/linker/processGadgetsMetas.js:41: //
hack! assumes the installLocation() is window
On 2011/03/10 20:51:20, unnurg wrote:
Why would you not get rid of this hack and just call
getInstallLocation() here?

oops, thanks.

http://gwt-code-reviews.appspot.com/1370808/diff/1010/gadgets/src/com/google/gwt/gadgets/linker/processGadgetsMetas.js#newcode78
gadgets/src/com/google/gwt/gadgets/linker/processGadgetsMetas.js:78: var
prefs = new $wnd.gadgets.Prefs();
note that this is also a change from the processMetas logic, so I'd
still have to either override the whole file or add some way that the
process metas logic could process data either from meta tags or gadget
prefs.

http://gwt-code-reviews.appspot.com/1370808/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to