xs linker does not support all GWT features?
Jonas Huckestein
does anybody know why the xs linker does not support code-splitting?
Are there any other features that are not fully supported?
I am currently trying to build a framework that allows for easy wave
gadget development in GWT (including side-by-side testing of gadgets
in hosted mode). Given the shortcomings of the gwt-gadget linker
(which produces only one huge code file instead of one for each
permutation), we were trying to figure out what else we could do over
at the wave dev group. (you can follow the discussion here:
http://groups.google.com/group/google-wave-api/browse_thread/thread/2b009cd96032d33e
)
It would be nice to get some statement on this from a googler. Since
Wave is developed using GWT I would like to be able to develop
extensions using GWT, as well.
Cheers,
Jonas
--
Jonas Huckestein
http://thezukunft.com
Brendan Kenny
> Hi everybody,
>
> does anybody know why the xs linker does not support code-splitting?
> Are there any other features that are not fully supported?
>
> I am currently trying to build a framework that allows for easy wave
> gadget development in GWT (including side-by-side testing of gadgets
> in hosted mode). Given the shortcomings of the gwt-gadget linker
> (which produces only one huge code file instead of one for each
> permutation), we were trying to figure out what else we could do over
> )
>
> It would be nice to get some statement on this from a googler. Since
> Wave is developed using GWT I would like to be able to develop
> extensions using GWT, as well.
>
> Cheers,
> Jonas
>
> --
> Jonas Huckesteinhttp://thezukunft.com
Hi Jonas,
Yes, the iframe (std) linker was the only official primary linker set
up to handle code splitting. I only use that linker and haven't dug
too deeply, so I don't know if that was done because of a fundamental
problem, for performance/efficiency reasons, or if was just left as an
exercise to developers since there wasn't much of a call for it.
If it's one of the latter two, it shouldn't be hard to adapt code from
the iframe and selectionscript linkers and incorporate it into a
version of the xs linker. If you aren't already familiar with it, the
key method is doEmitCompilation() in SelectionScriptLinker.
CompilationResult artifacts have a String array of the js code
associated with that permutation, each entry containing a code
fragment. The linker prepares the primary fragment to load correctly,
but subsequent fragments are just output directly to a matching
subdirectory.
http://www.google.com/codesearch/p?hl=en#A1edwVHBClQ/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
http://www.google.com/codesearch/p?hl=en#A1edwVHBClQ/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
Brendan Kenny
I'll forward this on to everyone.
Shortly after I wrote that post it was discussed on the Contributors
list that there was indeed a fundamental issue preventing the xs
linker from working with code splitting, but that a patch was in the
works. The fix landed on trunk in March
but I'm not sure if that made it into 2.0.4 (or whatever) or if it
will be released with 2.1.
On Tue, Jun 29, 2010 at 12:58 AM, Danny Goovaerts
<danny.g...@gmail.com> wrote:
> I have exactly the same request,i.e. use the xs linker together with
> code splitting (I use code splitting to chunk up a rather large
> application (800k), but even then it is advantageous to have caching
> of the js modules when using
> https).
> DId anyone try to make the changes mentioned below? Did you succeed?
>
>
> Thanks in advance,
>
> Danny
>
> On 12 feb, 01:30, Brendan Kenny <bcke...@gmail.com> wrote:
>> On Feb 11, 3:52 pm, Jonas Huckestein <jonas.huckest...@me.com> wrote:
>>
>>
>>
>>
>>
>> > Hi everybody,
>>
>> > does anybody know why thexslinker does not supportcode-splitting?
>> > Are there any other features that are not fully supported?
>>
>> > I am currently trying to build a framework that allows for easy wave
>> > gadget development in GWT (including side-by-side testing of gadgets
>> > in hosted mode). Given the shortcomings of the gwt-gadget linker
>> > (which produces only one huge code file instead of one for each
>> > permutation), we were trying to figure out what else we could do over
>> > at the wave dev group. (you can follow the discussion here:http://groups.google.com/group/google-wave-api/browse_thread/thread/2...
>> > )
>>
>> > It would be nice to get some statement on this from a googler. Since
>> > Wave is developed using GWT I would like to be able to develop
>> > extensions using GWT, as well.
>>
>> > Cheers,
>> > Jonas
>>
>> > --
>> > Jonas Huckesteinhttp://thezukunft.com
>>
>> Hi Jonas,
>>
>> Yes, the iframe (std) linker was the only official primary linker set
>> up to handlecode splitting. I only use that linker and haven't dug
>> too deeply, so I don't know if that was done because of a fundamental
>> problem, for performance/efficiency reasons, or if was just left as an
>> exercise to developers since there wasn't much of a call for it.
>>
>> If it's one of the latter two, it shouldn't be hard to adapt code from
>> the iframe and selectionscript linkers and incorporate it into a
>> version of thexslinker. If you aren't already familiar with it, the
>> key method is doEmitCompilation() in SelectionScriptLinker.
>> CompilationResult artifacts have a String array of the js code
>> associated with that permutation, each entry containing a code
>> fragment. The linker prepares the primary fragment to load correctly,
>> but subsequent fragments are just output directly to a matching
>> subdirectory.
>>
Jay
like to track when and if this fix makes it into a release, but
couldn't find anything by searching on "xs linker" and "code
splitting"
On Jul 3, 12:31 pm, Brendan Kenny <bcke...@gmail.com> wrote:
> Not sure if you meant to write just to me or reply to the list, but
> I'll forward this on to everyone.
>
> Shortly after I wrote that post it was discussed on the Contributors
> list that there was indeed a fundamental issue preventing the xs
> linker from working with code splitting, but that a patch was in the
> works. The fix landed on trunk in March
>
> but I'm not sure if that made it into 2.0.4 (or whatever) or if it
> will be released with 2.1.
>
> On Tue, Jun 29, 2010 at 12:58 AM, Danny Goovaerts
>
cretz
mentions it's already in trunk and will likely make the 2.1 final
release.