Event driven communication between independent GWT modules

[JEA]

I have a web site that has pages that each can contain a variety of
independent apps embedded in a different positions within an otherwise
conventional HTML page. Although independent, they can affect one
another. For example, there is a login box that authenticates a
user. Based on the user login status, the other apps may appear or
disappear or change their behavior. Since a user can log in or out at
any time, the apps should be able to detect the change when it happens
and modify their behavior appropriately. The login box doesn't know
what other apps are on the page so it can notify them directly. I
didn't code all the apps as part of one large app because I didn't
want them all to load for every page when only a small subset would be
visible.

My plan was to create some type of shared bulletin board object (maybe
a hidden div with custom attributes set) on which the login box would
post changes to the login status then fire a DOM event to notify
anyone who cares. The other apps would register listeners to receive
the change event and check for the status changes by looking at the
bulletin board, adjusting their behavior appropriately.

Problem is, I can't figure out how to implement this. I can see I can
use eventPreview to process a DOM event but I don't see a method that
lets a GWT module programatically fire an event on a DOM element.

Is this possible in GWT or GWT-ext? Perhaps there is an altogether
different and better way to achieve my intended effect.

-Joe

[walden]

Joe,

You don't need DOM events, per se. Use Observer Pattern. Your Login
module doesn't need to know who's subscribed. It just needs to
implement the Observable interface (register listeners, fire login
state change events). Your other modules are in fact dependent upon
Login. They need to know how to register listeners, receive events,
recognize Login events, and then I would suggest you let them probe
the Login module directly for login state.

If you look at how ChangeListener and SourcesChangeEvents work in GWT,
there are all the elements of the Observer pattern you need, and you
can copy that.

Walden

[Thomas Broyer]

On 4 nov, 13:11, walden <wmath...@aladdincapital.com> wrote:
> Joe,
>
> You don't need DOM events, per se.  Use Observer Pattern.  Your Login
> module doesn't need to know who's subscribed.  It just needs to
> implement the Observable interface (register listeners, fire login
> state change events).  Your other modules are in fact dependent upon
> Login.  They need to know how to register listeners, receive events,
> recognize Login events, and then I would suggest you let them probe
> the Login module directly for login state.
>
> If you look at how ChangeListener and SourcesChangeEvents work in GWT,
> there are all the elements of the Observer pattern you need, and you
> can copy that.

Walden, he has and wants (and needs?) distinct *applications* (not
only distinct *modules*), Java-GWT is not an option here.

@Joe: you'll have to implement such an observer/observable pattern in
pure JavaScript in your host page, and use JSNI in your applications
to register handlers/fire events.

[Brian]

I wanted to do something similar to having a bunch of independent
modules interacting on a page, but gave up, and stuck with the
monolithic app. I think you really need to analyze if it's worth
breaking up the app into modules and trying to work with all this glue
you'll need. For instance, there's quite an overhead in size for just
a hello,world gwt app. You'll be paying this overhead for each
module. Also, once the monolitic app is cached by the browser, it's
there until cleared, so there's basically no penalty for having the
app on multiple pages, even if it's not used "that much" (ie, not all
modules are visible). Also, you can break up your monolitic app so you
only create the classes needed in the given state, so you don't eat up
memory for modules you're not displaying, etc, etc. It just ended up
not making sense to break up the app --

What are the advantages to breaking the app into modules? Size?
Speed? In my case, size and speed were increased by keeping it all in
one app, and relying on browser caching.

[Brian]

Err, "size and speed were increased by keeping it in one app" should
have read, "size was decreased, speed was increased by keeping all the
modules in one app."

[walden]

@Thomas,

If you could define *application* then I could figure out if I can
make any sense of your comment. There may be confusion arising from
my sloppy use of the term 'module'. I was talking runtime
architecture, not code organization. So maybe I should have said
'component' instead. Anyway, to be clear, I was not talking about GWT
Modules. I was talking about components with state, optional user
interaction, and an event bus for implicit invocations triggered by
other components. I think that's what the OP was describing.

FWIW, I read the post below on monolithic solutions, and I concur with
that approach, which is consistent with what I was proposing.

Walden

On Nov 4, 9:50 am, Thomas Broyer <t.bro...@gmail.com> wrote:

[walden]

Brian,

I think it should be made clear that GWT Modules are reuse packagings,
just like Java classes, and don't even imply a runtime application
architecture. The only reason for breaking code into Modules is to
reuse it by inheritance rather than duplicating code.

Walden

> > > to register handlers/fire events.- Hide quoted text -
>
> - Show quoted text -

[Brian]

I was thinking about this a little more, and threw around a couple
ideas where "it would be nice" to break a monolithic-at-runtime
application into runtime modules (analagous to breaking an .exe into a
bunch of .dll's).

How much javascript can a browser deal with? If there's some maximum
size an application can reach before a browser has problems using it,
it'd be nice to break the application into runtime chunks and bring
them in as needed.

Administration screens -- I don't bundle admin functionality into an
app, but it would be nice, based on user permissions, to just add the
Admin panel to the application. Instead, it's a whole separate app
(not that big of a deal, really).

Anyway, although I said just make a monolithic application as I
believe it's the right thing most of the time, not knowing if there's
an application size upper-limit size makes me wonder.

[Isaac Truett]

Brian,

It sounds to me like the scenarios you describe here would be
addressed by the runAsync work currently underway. The runAsync
feature will allow the developer to indicate portions of code that can
be lazily loaded from the server as needed. The compiler takes care of
separating and ensuring that things get loaded in the proper order.
You can learn more about it by searching the contributor's forum.

- Isaac

[Brian]

Sounds interesting, thanks for the head's up.

On Nov 4, 5:30 pm, "Isaac Truett" <itru...@gmail.com> wrote:
> Brian,
>
> It sounds to me like the scenarios you describe here would be
> addressed by the runAsync work currently underway. The runAsync
> feature will allow the developer to indicate portions of code that can
> be lazily loaded from the server as needed. The compiler takes care of
> separating and ensuring that things get loaded in the proper order.
> You can learn more about it by searching the contributor's forum.
>
> - Isaac
>

[Thomas Broyer]

On 4 nov, 21:28, walden <wmath...@aladdincapital.com> wrote:
> @Thomas,
>
> If you could define *application* then I could figure out if I can
> make any sense of your comment.  There may be confusion arising from
> my sloppy use of the term 'module'.  I was talking runtime
> architecture, not code organization.

I'm using the term "application" for the GWT module to be run against
the GWTCompiler and/or the output after running it; and "module" for
GWT modules (gwt.xml and associated resources and code; things that
you can inherit in other modules and/or applications).

If you have distinct applications ("compiled GWT modules"), you cannot
use Java/GWT to make them talk to each other (you cannot just
implement Observable/Observer –the Java interfaces–); hence my "Java-
GWT is not an option here".

Hope I'm clearer.

[JEA]

Thanks to everyone who contributed their comments on this problem. It
has been tremendously educational for me. This is my first crack at
using GWT.

To clarify, I am trying to send event messages between separately
compiled GWT mini-apps on one page, not just separate modules. As was
suggested in this thread, I've found it an intractable problem without
resorting to pure javascript plumbing and it sounds like I may not be
doing myself any good anyway as far as speed and size are concerned,
at least until I am talking about quite a few different mini-apps.
Maybe be the time I reach that point, the runAsync feature will be
available and solve that problem, too.

As much as anything, it just felt *wrong* to be carrying around from
page to page a bunch of app code that would be used on only one or two
of the pages, but maybe I just need to get over that and get on with
the project.

Joe

[walden]

Joe,

"Aha! moment": GWT is not Java.

Walden

[francescoNemesi]

Hello,

I've been doing exactly what JEA asks using GWTx (http://
code.google.com/p/gwtx/)... it extends GWT to use
java.beans.PropertyChange* which implement all that's needed for the
Observer and clientside MVC patterns. As an example for JEA's request
you could implement a "user" model that sends a "userLogged"
PropertyChange event; all registered views (the apps, in his case) to
this event would then update accordingly.

To manage which apps can/can't be displayed an idea would be to use a
static singleton registry-like class...

A very good source of information for propertyChange support and best
programming practices, and my bible for GWT, is the book "GWT in
practice" by Cooper/Collins on Manning.

Hope this helps,
Francesco

P.S. It woud be great if GWT implemented natively the java.beans
package....