> > Even if the code is not being compiled together, it seems like a library > module could be created that could then be shared by all widgets in this > scenario. Someone please correct me if I'm wrong.
I think so too, but then you will need something to communicate between every module using JSNI... Cheers, On Wed, Dec 15, 2010 at 3:18 PM, Brian Kardell <bkard...@gmail.com> wrote: > Thanks David. > > I'll say that before posting anything on here I spent hours searching > through these groups and found a lot of people looking for some kind of > reuse very much related to this same kind of problem - but nothing > especially helpful in the way of a solution... It almost seems like it > should be doable with just a little bit more the compiler side or something. > > Is the compiler source available? I have looked briefly into linkers, but > I fear that the big hangup for us is really the base stuff which probably > isn't addressable from the linkers. Any advice on somewhere I can follow up > with those kinds of interests? > > -Brian > > > > On Wed, Dec 15, 2010 at 3:08 PM, David Chandler <drfibona...@google.com>wrote: > >> Fair enough, bkardell. GWT cannot optimize code that cannot be >> compiled together. If it's a requirement for you that each widget is a >> separate JavaScript, then you'd have to compile a few and see whether >> the GWT optimizations such as dead code elimination outweigh the >> effects of compiling multiple times the commonly used parts of the >> shared libraries. >> >> GWT's sweet spot, IMHO, is building rich Internet applications that >> feel like a desktop app but run in a browser. GWT can break the app >> into multiple pieces using code splitting (runAsync), but if the >> pieces aren't part of the same compile as in your case, that won't >> help. >> >> /dmc >> >> On Wed, Dec 15, 2010 at 2:31 PM, bkard...@gmail.com <bkard...@gmail.com> >> wrote: >> > Ok, a few things. >> > >> > 1) Thanks for the response. >> > 2) Please have some patience, I'm really trying my best to communicate >> > what seems to me a perfectly rational question that I feel like I am >> > directing at exactly the right people. If I come across unclearly, I >> > will be more than happy to try to clarify. >> > 3) The examples that both @clintjhill and I gave specified that these >> > are disparate code bases that _can not_ be compiled together. It is >> > possible to specify things that can and can't be used, even an API - >> > but they aren't owned by the same entity... That's really why I tried >> > to use "something like" iGoogle as an example because it's sort of the >> > most analogous thing I can think of... It's a Mashup situation where >> > there can potentially be many, many components shoved together from >> > disparate (but trusted) sources. If I recall, I think that the gadget >> > container actually _does_ provide some common API for tabs and rpc and >> > things... I'm not sure if that's re-incuded every time, but that's the >> > idea - do we have to reinclude it every time? I think that >> > @clintjhill's example is more literal/concise so if you are more >> > comfortable with that, the only addition I would like to make is that >> > it is perhaps a little too small (not just repeated, but repeated >> > potentially many, many times) to demonstrate my concern.... >> > 4) Note the end of the question above "... if the GWT team had such a >> > problem at hand - would they choose GWT" is followed immediately by >> > "... and if so, how would they deal with the implications spelled out >> > above?" >> > >> > I just want to say... There are languages and tools that I use, that I >> > _love_ in fact, which would just be the wrong choice if that's not the >> > problem space that they are focused on solving. I think, if I had no >> > desire to use GWT - why would I be asking...right? >> > >> > -- >> > 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<google-web-toolkit%2bunsubscr...@googlegroups.com> >> . >> > For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> > >> > >> >> >> >> -- >> David Chandler >> Developer Programs Engineer, Google Web Toolkit >> http://googlewebtoolkit.blogspot.com/ >> >> -- >> 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<google-web-toolkit%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> > -- > 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<google-web-toolkit%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- Christian Goudreau www.arcbees.com -- 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.
