I haven't used gwt-exporter, or any non-trivial JSNI, so what I'm about
to say may be rubbish.
http://code.google.com/p/gwt-exporter/
If you want multiple gadget-like things to work together that have been
compiled separately, you could:
(1) Put each gadget-like thing into its own project
(2) Use gwt-exporter to create a javascript API
(3) Compile your gadget-like thing, and publish the resulting javascript
with its API.
(4) Create a GWT wrapper that uses JSNI to talk to the javascript API,
creating a GWT Java API
(5) Distribute the javascript compiled in (3) together with the java
source code for the wrapper you created in (4)
Then somebody could pull many of these gadget-like things together in a
big mashup.
If you wanted to add these gadget-like things together at *runtime*, you
could do that if you just rely on the javascript API. If you're happy to
GWT-compile the mashup, then you could use the GWT java wrappers so that
the mashup could avoid JSNI, relying on the wrappers doing JSNI for you.
However:
(a) I don't know what, if any, bootstrapping you'd need to do for each
of the gadget-like things.
(b) You might suffer from some duplication that a monolithic compile
could optimize away. But you could provide common services into another
gadget-like thing, and let other gadget-like things call its GWT wrapper.
(c) All this might be made to work, but there may be a better way that
doesn't involve GWT
(d) I've no idea how you'd debug it as a whole
Paul
On 14/12/10 21:57, bkard...@gmail.com wrote:
GWT's monolithic compile makes for really efficient JavaScript/
Resource downloads. In terms of providing a solution to the sort of
"traditional" kinds of web app problems, it's hard to argue that GWT
couldn't optimize whatever a developer would write because developers
write for flexibility - whereas the compile is about "there is 1 use
at the end of the day and everything else is just noise".
I'm sort of wondering though, are there classes of problems that GWT
is admittedly not a good fit for (specifically, according to the GWT
team itself) specifically because of that approach?
It's kind of hard to explain a concrete example, but let's try this:
If every gadget for iGoogle had to be developed in GWT - each iGoogle
gadget would contain everything that it needed and rely on nothing
shared, despite the fact that most gadgets would (according to the
compile reports) potentially share as much as 99% of their
dependencies. Simply because they are disparate compiles, the
compiler's view into the world is just too small...
Hypothetically speaking, if the average gadget were something like
50k, and something like 48k of that was just "core stuff", this
implies that a page with 10 gadgets would be something like 500k (of
just script), but 480k of that was largely just "repeated" core code.
I suppose it guarantees that things won't "break" to an extent with
versioning, but wouldn't it be more efficient in this hypothetical
example to have coded the flexibility into the gadget "container"
once? In other words - if the core were provided and the gadgets
merely used it, the total size of the page would be 68k instead of
500... Right? And the more gadgets are there, the bigger the
"savings".
In this kind of case - would the GWT team say "GWT is the right
choice" or no?
--
You received this message because you are subscribed to the Google Groups "Google
Web Toolkit" group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
