Howto load extra modules during runtime (pluggable framework question, not about initial download size)
Rebornspirit
I'm starting to work on a pluggable framework based upon OSGi and GWT,
the goal is to be able to dynamically load extra GWT modules during
runtime. So when the application starts the entrypoint module gets
loaded from then on people can browse the repository to install new
modules during runtime, so a user clicks on a module he wants to
install, and this gets loaded on the server using OSGi. Now the big
question is what about the GWT files? How can I load other GWT data
during runtime?
If I have the GWT .cache.html file names can I just load the correct
one by adding a new script tag during runtime, and by doing so loading
all the data that is contained within the .cache.html.
Grtz
Maarten
mumuri
Maarten Volders
So what is the status on loading dynamic modules? Is it feasible, because the postings above ( http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/43bc53829f2bee11/f0d8a494ae54ae19?lnk=gst&q=dynamic+loading+working&rnum=1#f0d8a494ae54ae19) gave me an unsure feeling about using GWT for a pluggable framework application which is OSGi based? Is anyone doing this, any ideas, issues... on this topic? Can it be done? What are the possible solutions? Workarounds? Suggestions?
We are starting with a big open source project with a pluggable framework (OSGi) as it backbone, so the the fact that GWT can be used or not has a very large impact! I just finished a small/medium sized commercial applications fully based on GWT, I'm so convinced about its power that I would be very disappointed that for this open source project I would not be able to use this technology!
I guess this topic will come up more and more because with the upcoming Springframework OSGi implementation a new era in software development is at hand!
Especially I would like to hear from the GWT team, is this something that is considered in the design or something that is in the pipeline?
Grtz and keep up the good work :-)
M.
krispy
http://code.google.com/p/google-web-toolkit/issues/detail?id=620
It's been planned, so I'm assuming that the GWT team means to look at
this more in depth after 1.4 is Final. This would be a very nice
feature to have, and it's been talked about multiple times on the
forums here. There's leeway on how far you want to take it - I
personally don't feel that taking it as far as dynamic class loading
is a good idea. However, making a pluggable architecture where
multiple modules can be separated at compile time and then lazily
loaded seems extraordinarily feasible - it just requires making
separate files based on a flag in your module file. I wrote about it
here:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/7e4860e4b6982db4
The difficulty is that since the compiler obfuscates everything, if
you wanted to lazy load modules, right now they'd have to be compiled
together every time a change was made (in order to link everything
fluidly). Otherwise, there's a lot of problems since namespaces could
overlap if you missed compiling certain plugins - I haven't thought
about it as much as others, most likely, but if you could somehow
maintain constant mappings of variable names while compiling this
might work (but probably produces a lot of code bloat).
Really, I'd just like to split my application up into separate module
files that could loaded later - I'd never need to compile modules
apart from the whole of my app. If you wanted plugins that you could
pull from anywhere without needing to compile against some kind of
core application, it would probably be a lot uglier, IMO. But I'm
definitely not the expert on these things.
-krispy
On Jun 19, 2:48 pm, "Maarten Volders" <maarten.vold...@gmail.com>
wrote:
> for some reason I cannot reply to the mentioned postings, so here it goes:
>
> So what is the status on loading dynamic modules? Is it feasible, because
> the postings above (http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...)
> gave me an unsure feeling about using GWT for a pluggable framework
> application which is OSGi based? Is anyone doing this, any ideas, issues...
> on this topic? Can it be done? What are the possible solutions? Workarounds?
> Suggestions?
>
> We are starting with a big open source project with a pluggable framework
> (OSGi) as it backbone, so the the fact that GWT can be used or not has a
> very large impact! I just finished a small/medium sized commercial
> applications fully based on GWT, I'm so convinced about its power that I
> would be very disappointed that for this open source project I would not be
> able to use this technology!
>
> I guess this topic will come up more and more because with the upcoming
> Springframework OSGi implementation a new era in software development is at
> hand!
>
> Especially I would like to hear from the GWT team, is this something that is
> considered in the design or something that is in the pipeline?
>
> Grtz and keep up the good work :-)
>
> M.
>
> On 6/19/07, mumuri <topfl...@gmail.com> wrote:
>
>
>
> > perhaps this can help you :)
>
> >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
Maarten Volders
I've added my use case to the issue report, hope they figure out something cool soon ;-)
Has anyone got a good workaround until something final comes out, just to get the idea working more or less... well just the concept, third party providers will have to wait until this issue is fixed.
Grtz
M.
krispy
I was thinking tonight, and it occurred to me that what a plugin
really wants to be is a Javascript API that can be accessed by 3rd
party developers, correct? But the power of GWT is in wanting to do
this in Java, with all the good things that GWT offers along the way.
Then I realized that there is already a way to do this with GWT - you
can, right now, create pluggable applications for the use of 3rd party
developers! Bear with me while I spill my brains.
There are two interesting use cases for me concerning loading modules
at runtime:
1) Having parts of an application that need to be lazy loaded - as I
posted before, this can be solved simply by compiling the entire
application, but having GWT separate out the various modules that need
to be loaded separately. No problems there with namespaces/obfuscated
names, because the GWT compiler has already linked the modules before
separating them. All that's being done is separating the single,
monolithic Javascript file into several smaller files.
2) Writing an application that is complete in and of itself, but which
can have additional modules created at a later date and added to the
system. Here comes the issue with obfuscated code - since the module
is just loaded, it could possibly overwrite obfuscated names, etc. but
the bigger problem is, how does the additional module communicate with
the already written code?
What I'm talking about right now is use case 2 - I've thought of two
solutions:
a) 3rd party developers must get a hold of the core application and
compile their plugin against it. This would require a compiler change
so that the namespace of the new module is completely separate from
the core application (the core always retains the same variable names,
etc and the new module doesn't conflict with other new modules).
b) Create an API in Javascript that will contain non-obfuscated names
for functions, variables, etc. The plugins would have JSNI methods
which assumed the API was available for their own use, and call that
API in their code to link into the core application.
Choice (b) was what I was hinting at above - it seems like the most
straightforward way to me. But, I realized tonight, the tools already
exist to do this! Enter Ray Cromwell's Exporter API:
http://code.google.com/p/gwt-exporter/
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/7057ef4c0789ceac/8f677d1d2992372a#8f677d1d2992372a
>From what I understand, it basically creates a Javascript API for you
using GWT generators so that other developers can hand write
Javascript code to interact with your own. From what I've seen, you
just put annotations at the top of your Java class, add a call to
GWT.create() in your entry point, and that's it. It's very simple to
use, and he explains some of it here:
So, then all you'd have to do to make a pluggable framework, is use
Ray's Exporter, generate your Java names into Javascript, publish an
API, and then let any developers who want to create a plugin just
follow your API. Of course this would be simpler if you didn't have
to write Javascript to access the API, but rather could just write
Java code in GWT to access it. It just so happens that Bob Vawter on
the GWT team is busy working on a GWT addition that will allow you to
seamlessly integrate Javascript libraries without JSNI:
http://gwt-api-interop.googlecode.com/svn/trunk/README
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/4d24156e607170f6/7d7692e770efc170
Basically, you create interfaces in Java with annotations that define
what the Javascript library API looks like. So, what you could do is
export your plugin API through the GWT Exporter from Ray, then take
Bob's importer and create a JAR with wrappers around the Javascript
calls so that plugin developers can write seamless Java code. Voila!
Of course, Bob's stuff is very experimental at this point, but
hopefully will make it into a future version of the GWT framework -
but just think, you could probably automate the whole export/import
process by creating a generator that writes the source for the Java
wrappers around the exported components - you'd just have to extend
Ray's Exporter a little bit ...
Sorry that this post is extremely long - I was just excited to share
my thoughts on how you could create a plugin architecture like this
with existing projects! I think this is as close to "dynamic module
loading" as we're probably going to get.
-krispy