Client plugin architecture with GWT
Andrej
do you have any comments on web client plugin architecture with GWT
without recompilation?
for example:
each directory will contain one gwt module (plugin), main gwt module
(plugin manager) will load plugins and use them.
to implement following, gwt module_a should be able to access module_b
api during runtime... and currently this is not possible, right?
Reinier Zwitserloot
Your strategy would mean methods which are not used by a given app are
still loaded. That's wasted bandwidth. That will result in jokes like
the digg homepage, which downloads 3MB worth of javascript, half of
which is never used.
cignini
web based.
Currently I'm working to design an architecture that joins the
metaphore behind the Eclipse-RCP and the potential of GWT.
With this framework, named GWT-RCP, shortly I'll starting a big
project where I hope to test the qualities of a plugin architecture
with GWT.
Marco
On May 16, 11:08 pm, Andrej <ahars...@gmail.com> wrote:
Reinier Zwitserloot
On May 17, 11:58 am, cignini <cign...@gmail.com> wrote:
> I retain that is a good solution for a client application that must be
> web based.
You mean like how GWT produces client apps that are web based?
cignini
responsibilities in different plugins permits to simplifies team work
development and large reuse of plugins in different situations.
A view that display contents of a User contained in one plugin used in
an application A that performs some activity is reusable in an
application B in just simple few clicks.
Marco
Reinier Zwitserloot
sentiment.
Let me explain:
GWT supports the idea of plugins, project separation, and isolation of
modules extremely well.
It's just that the gwt COMPILER takes all these separated things and
efficiently packs them into as small a monolothic javascript file as
it can manage. Consider it a web-page load optimizer on steroids. The
end result is completely irrelevant for programmers; the only major
difference is that GWT forces you to distribute your libraries and
plugins as source. If you think there's a market for that when the
penalty is 10x larger JS files, go right ahead, but... just no.
Everything you mentioned is possible in GWT *NOW* without your idea of
a plugin system.
Andrej Harsani
Do you have any documentation of your gwt plugin framework?
Yes plugin architecture is very usefull. good non-web examples are eclipse or firefox.
I need it because I want to allow 3rd party developers to create plugins into my new
GWT application.
A.
Andrej Harsani
the only major
difference is that GWT forces you to distribute your libraries and
plugins as source. If you think there's a market for that when the
My gwt-application use php and it is not possible to recompile it on the fly in case customer download new plugin
at customer location becase java is missing on many hosting.
a.
cignini
into a GWT based application.
Currently the first results are good but as you can imagine this
requires a lot of work and blood.
We are thinking to distribute this project as opensource but this is
not a one day decision ;-)
Marco
p.s. to Reiner: think we didn't understood ourselves: I agree on what
you said!...but the specs of our project doesn't include dimension of
compiled JS (at least at the moment).
On May 17, 3:13 pm, "Andrej Harsani" <ahars...@gmail.com> wrote:
> Hi Marco,
> Do you have any documentation of your gwt plugin framework?
>
> Yes plugin architecture is very usefull. good non-web examples are eclipse
> or firefox.
>
> I need it because I want to allow 3rd party developers to create plugins
> into my new
> GWT application.
>
> A.
>
> On 5/17/07, cignini <cign...@gmail.com> wrote:
>
>
>
>
>
> > I retain that this is a good solution because separate
> > responsibilities in different plugins permits to simplifies team work
> > development and large reuse of plugins in different situations.
> > A view that display contents of a User contained in one plugin used in
> > an application A that performs some activity is reusable in an
> > application B in just simple few clicks.
>
> > Marco
>
> > On May 17, 12:11 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > > On May 17, 11:58 am, cignini <cign...@gmail.com> wrote:
>
> > > > I retain that is a good solution for a client application that must be
> > > > web based.
>
> > > You mean like how GWT produces client apps that are web based?
>
> --
> Best regards,
> Andrej Harsani
> Quality Unit
Andrés Testi
were forum admin can upload third party modules without recompiling
the sources.
krispy
you'd have to modify the compiler code some, but only to take separate
modules and separate them into different .js or .html files. The file
sizes, when taken all together, would be the same size as the original
monolithic one - because all you'd do is take out the common code
(which would have some bootstrap logic to decide when to inject the
other scripts). The number of server requests increases, because you
have to inject each separate file - but that seems almost not worth
worrying about if you aren't doing it on initial startup. Maybe one
of the GWT developers could comment? Maybe adding a command line
switch to the compiler to separate modules? And then maybe an extra
property inside of the module xml config files to specify that those
modules should be in separate files? (so that some stuff gets combined
and some stuff doesn't)
I think that for the amount of work it would take, it would create a
huge benefit to a lot of developers in:
1) separation of logic
2) initial startup complexity and load time (deferred loading of
modules)
3) some users might not need all of the plugins, therefore actually
saving them bandwidth
4) security - some users might not be allowed to see all of the
plugins (or even the obfuscated source for them)
-krispy
cignini
to work in this direction.
Marco
krispy
focused on making web pages easy to create (in that you don't worry
about cross-browser incompatibilities) and fast to run (in that
everything is obfuscated and heavily optimized). Anything that
contradicts the speed issue seems to be put on the back burner - which
I think is a good idea nearly all of the time. In this one case,
though, I think we as developers need to be given the option to
sacrifice a little of the speed/bandwidth for greater flexibility -
don't make it the default or anything like that, but at least give us
the option. I think it's an easy stepping stone once 1.4 is Final -
I'd just like to hear what Miguel, Dan, Bruce, et. al have to say
about it (because I highly regard and respect their opinions on this).
-krispy
Andrej
from google can comment.
main question is if something like this is possible at all (because of
one of the main
compiler design goal - js optimalization),
and if yes if they plan to do it.
a.
On May 17, 4:40 pm, krispy <cplum...@integrity-apps.com> wrote:
Andrés Testi
module, the linker binds the module dependencies (I.E. core
dependencies) and generates a new monolithic cache file with all JS
code needed. This doesn't runs faster than a traditional full compiled
GWT application, but it's faster than other solutions (dojo,
script.aculo.us, etc..)
krispy
I think that's far down the road from here and has a lot more
complications. I know that there have been plenty of other posts on
this subject. What we're advocating is that the compiler link all of
your code at once, like it does now (core module and plugin module[s])
and then separate the plugins on the server into different sources.
My concern is that it SEEMS simple enough - the question is, are there
complications that need to be addressed that we're missing? That is
what we need feedback about.
-krispy
krispy
marked as "Planned" :
http://code.google.com/p/google-web-toolkit/issues/detail?id=620
I've added a link to this topic and a comment - I think they tried to
discuss the idea before but too many other things were going on then.
-krispy