Comment by a.revolution.ultra.blue:
One hack I was using to get modules to "speak through compilations" was
using Ray's exporter. Basically, common functions like custom dialogs that
cover the screen... If I want them to look nice, but be accessible before
I ever access Widget code, I use
Comment by Evelyne24:
Hi,
I have a question regarding Code Splitting + DI with Guice/Gin. I have a
module that looks like this:
public class Module {
private Thing thing;
private Provider provider; // Guice
@Inject
public Module(Thing thing, Provider pr
Comment by cromwellian:
Not currently. GWT Exporter was created under the paradigm that it only
exports what is explicitly requested, or what is absolutely necessary. I
felt at the time that 'inheriting' annotations could lead to a lot of
bloat, as well as asking the TypeOracle to give yo
Comment by lineman78:
I have used Ray's GWT Exporter and I believe that you could use this to
achieve what you want with plugability while also allowing the compiler to
do it's optimizations. One thing I haven't experimented with that Ray
would have to answer is if you could add the export
Comment by hbrucejohnson:
@brett: What Ray said. Also, we don't want to create the web equivalent of
DLL Hell, which is a very easy situation to get into. Finally, and most
importantly, runtime modularity simply has a really high performance cost
because HTTP round-trips over the internet a
Comment by cromwellian:
I'm not a GWT team member, but I'll comment. It's not just pruning unused
methods. It also affects obfuscation and a number of other things that
make 'separate compilation/linkage' a difficult prospect.
In order for N different separately compiled programs to be linke
Comment by brett.wooldridge:
Just a message to the Google GWT team that while I appreciate the
theoretical utility of pruning unused methods, especially as applicable to
the GWT core UI classes themselves, the applicability to end-user code is
likely much less.
I routinely run dead code an
Comment by hauke.kopf:
We are also searching for solution to dynamically extend the GUI produced
via GWT.
Regarding Cromwellian's comment about the compiler optimizations and the
static analysis of what code parts are "live" or "dead", I would say that
what we want is something like JARs fo
Comment by m.zdila:
cromwellian: I don't understand how could the RPC solve my problem.
Maybe what I would like to have is currently very complicated in the GWT. I
am accepting it and can live with that.
Long time ago I was using DOJO and I was dynamically loading the views to
the workspace
Comment by cromwellian:
The problem is, if you support separate compilation, the compiler can no
longer make assumptions about which methods in your code base are 'live'
(are going to be called) and which are 'dead' (are never called), it would
be forced to include them on the chance that
Comment by m.zdila:
@br: We can compile together the client code for all the current modules,
but it would not be very OSGi conforming. For example, imagine that some
client bought our product including only some of the modules. It would not
be very clean to include client code for all the
Comment by br...@google.com:
@m.zdila: Right now, so many of GWT's biggest speed benefits are a direct
result of monolithic compilation of modules, so adding features to
encourage runtime modularity is not something we're really considering
anytime soon. While we understand the desire to no
Comment by m.zdila:
Hello.
This is certainly a nice feature, but one not requiring a monolithic
compile would be that just great.
Our application is built on top of OSGi. When a new module is added a new
menu item appears in the GUI to access that module GUI (under different
URL).
Curren
Comment by m.zdila:
Hello.
This is certainly a nice feature, but one not requiring a monolithic
compile would be that just great.
Our application is built on top of OSGi. When a new module is added a new
menu item appears in the GUI to access that module GUI (under different
URL).
Curren
Comment by JasonThrasher:
Above: "The -soyc flag is currently only available on the GWTCompiler entry
point, not the new Compiler entry point."
On the current GWT 2.0 HEAD off of SVN, -soyc are supported for the
Compiler. Also, -aux has been removed, being replaced by -extra.
For more inf
Comment by JasonThrasher:
Above: "The -soyc flag is currently only available on the GWTCompiler entry
point, not the new Compiler entry point."
Is this still true? It seems that the new Compiler takes the -soyc flag,
and the old GWTCompiler does not take the -aux flag. But I don't see any
Comment by JasonThrasher:
Above: "The -soyc flag is currently only available on the GWTCompiler entry
point, not the new Compiler entry point." Is this still true? It seems that
the new Compiler takes the -soyc flag, but I don't see any output
generated, other than messages saying that the
Comment by JasonThrasher:
Above: "The -soyc flag is currently only available on the GWTCompiler entry
point, not the new Compiler entry point."
Is this still true? It seems that the new Compiler takes the -soyc flag,
but I don't see any output generated, other than messages saying that the
Comment by rj...@google.com:
I'm afraid not. runAsync still relies on a monolithic compile.
For more information:
http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Comment by mirceade:
I know this must sound dumb:
If I have a pre-compiled core module and want to compile and add an
extension module on the fly (WITHOUT the core module's source code being
available) will this feature make it possible?
For more information:
http://code.google.com/p/google
Comment by adam.tacy:
A suggestion for the common coding patterns: I've found that I needed three
cases more often than not and so extended the ModuleClient? interface as
follows:
{{{
public interface ModuleClient {
void onLoad(Module instance);
void onAlreadyLoaded(Module instance
Comment by adam.tacy:
A suggestion for the common coding patterns: I've found that I needed three
cases more often than not and so extended the ModuleClient interface as
follows:
public interface ModuleClient {
void onLoad(Module instance);
void onAlreadyLoaded(Module instanc
Comment by inventoriffic:
This looks amazing.
For more information:
http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--
23 matches
Mail list logo
