Hi Thomas,
Thanks for the reply and apologies for the delay, I must have missed the
email notification re: your reply.
Well its great to hear that it is already solved via the xsiframe linker,
but not a total loss, I learned a good deal about how the IFrame linker
currently works ;)
I gave the xsiframe linker a try with the following results:
- I had to deal with the xsiframe linker not supporting <script /> tags
(the Piriti library I use for JSON serialization has a script tag in its
*.gwt.xml module files); the workaround for this is well documented but
something to consider when rolling this linker out as the default
(potentially a breaking change).
- I was unable to get this working in Firefox v24 on Win7 64bit but was
unable to get it working in Google Chrome v30.0.1599.101 m... *have you
tried this on Chrome recently*? I actually saw a similar behavior to
what I reported with my own solution (once, i was not able to re-create)
which was that it would fail unless the gwt.codesvr without the module name
was also in the URL.
The reason I'm working on this is primarily for "Portal" type
functionality; is there any work on the roadmap related to getting GWT to
play nicely inside a portal-type environment where:
1. Multiple GWT applications can be rendered on a single page and
debugged individually (looks like xsiframe linker is getting us there).
2. Multiple instances of the same GWT application can be rendered on the
same page but with different "bootstrap params"; e.g. being able to pass in:
- Preferences to tell instance X of the widget to display a graph
over 12 months and instance y to display a graph over 3 months
- The div that the GWT application should attach itself to.
Thanks in advance.
Cheers,
Jamie
On Wednesday, October 9, 2013 8:50:45 AM UTC+1, Thomas Broyer wrote:
>
> Too bad you started investing time in a solution to a problem that's
> already solved!
>
> You first have to use the xsiframe linker (which BTW is not a bad idea; I
> think we should make it the default linker in some future release), then
> just use gwt.codesvr.myModule instead of gwt.codesvr, where myModule is the
> name of your module (same name as the folder and nocache.js)
>
> See https://code.google.com/p/google-web-toolkit/issues/detail?id=2079#c21
>
> On Tuesday, October 8, 2013 7:07:40 PM UTC+2, Jamie Cramb wrote:
>>
>> Hi all,
>>
>> I have a page which has multiple GWT applications running on it. When it
>> comes to development mode / debugging from eclipse (using the dev mode
>> plugin in chrome) we start to hit issues because if we put the
>> "gwt.codesvr" param in the URL then all of the GWT applications on the page
>> will try to debug and will fail (because the debugger we have running only
>> has the source code for one of the applications in its classpath).
>>
>> My goal is to update the implementation of the bootstrapping process for
>> dev mode to achieve the following:
>>
>> 1. Externalize the decision on which GWT applications on a page
>> should debug based on some other JS function that is resident on the page
>> so it can be controlled via a custom mechanism / server-side decision.
>> 2. Have the ability to assign a custom "$hosted" URL (e.g.
>> "localhost:9997") for each of the GWT applications on a page that should
>> be
>> debugging.
>>
>> I have achieved the first goal by:
>>
>> - Providing my own primary linker (an extension of the IFrameLinker)
>> that overrides the location of the selection script template so that it
>> uses my modified selection script
>> - Making my modified selection script provide a custom
>> "isHostedMode()" implementation that calls out to a JS function that is
>> resident on the host page for the decision of whether or not to go into
>> dev
>> mode:
>>
>> function isHostedMode() {
>>> $wnd.shouldDebug('__MODULE_NAME__');
>>> }
>>
>>
>> I thought I was close to achieving my second goal by:
>>
>> - Using the same primary linker to override the hosted.html location
>> with my own custom hosted.html page.
>> - Making my hosted.html pickup the $hosted URL from a global var
>> resident in the host page instead of trying to pick it up from the
>> "gwt.codesvr" param:
>>
>> $hosted = decodeURIComponent(parent.debugHostUrl);
>>
>>
>>
>> However, I get a failure (return false) from the following line of code
>> unless I have the "gwt.codesvr" param in the URL:
>>
>> if (plugin.connect(url, topWin.__gwt_SessionID, $hosted, $moduleName,
>>> $hostedHtmlVersion)) { ... } else { ...}
>>
>>
>> On debugging the code everything looks fine going into the
>> plugin.connect() call.
>>
>> Does anyone know:
>>
>> 1. If there is a better approach to achieving my goals?
>> 2. If the dev mode plugin is hard coded in someone to expect the
>> "gwt.codesvr" param to be in the URL even though the $hosted var is
>> passed
>> in on the call to connect?
>>
>>
>> Thanks in advance.
>>
>> Cheers,
>> Jamie
>>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
