OSGi Application nested submodule messaging

[Joseph Lust]

Question to the forum. We are rewriting our 120K line GWT application to run on an OSGi architecture so that we no longer deploy a megawar file and can update individual parts of the application (currently 25 modules, will be 85 in a year) UI and services without affecting others. We've created an OSGi container that can bundle GWT applications and dynamically load/unload their RPC serialization files, but we're not done yet.

Problem:

We use a core application loading screen from which users go to submodules. We are using the design of a Header/Foot and center container here. The Header/Foot are part of the core application and we use the center pane to load the submodule in an iFrame. The rub: we need to pass some state information from the opened submodule back to the core application so that the Header/Footer views in the core application can be updated with Header/Footer customizations from the submodule.

While I know I could just make the Header/Foot part of the submodule, and then just open a new .html page to load the submodule, there are many buttons and services in the Header/Footer that don't make sense to replicate in each submodule. Further, if we update the Header/Footer, we don't want to have to redeploy each submodule to make them match.

Potential messaging mechanisms:

• Pass messages via Cookie with polling (ugly)
  
• Have iFrame parent poll for changes in iFrame DOM (or JSNI method in iFrame like getHeaderState())
  
• Update page URL with hashed state information (not so good, finite data limit)
  

I'd rather not have to poll at intervals and the URL mechanism seems like an anit-pattern. Has anyone else solved this problem before? Thx.

Sincerely,

Joseph

P.S. I'll attach a diagram later tonight. Seems you cannot add a picture w/o using G+ and like many companies we block social media access. :(

[Jens]

I guess I would publish a JS API in the parent core application via JSNI and then call the API methods from your submodule iFrame (via top.apiMethodName() ) when they have loaded and need to customize the header/footer. This would be your second solution but the other way around which avoids polling and makes the code in your submodule may look more obvious about whats happening.

Alternatively there is something called Window.postMessage() which allows you to post message events between pages of different domains.

Browser support: http://caniuse.com/#search=postmessage

Mini Example/Documentation: https://developer.mozilla.org/en-US/docs/DOM/window.postMessage

In combination with AutoBeans for serialization/deserialization Window.postMessage maybe also works well (if you dont need support for IE6/7) and you probably need to write less JSNI code.

-- J.

[Joseph Lust]

Thanks Jen's, I'll give the JSNI and postMessage() methods a try.

Sincerely,

Joseph

[Alfredo Quiroga-Villamil]

Assuming the amount of JS to export is not a lot, I also see exporting
JS and exposing it as a very viable alternative as Jen previously
pointed out.

Something else that comes to mind, a lot more involved I must admit is
to use a server-push approach. The header/footer module keeps an open
connection with the backend. The backend receives a notification that
something changed and pushes back to the UI where the header/footer
module makes the appropriate changes. This eliminates the need to
poll.

I think the exported JS exposed via JSNI it's the simplest and
probably one of the cleanest ways to get this done but wanted to throw
this other approach out there.

Best regards,

Alfredo

> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-web-toolkit/-/4tNAb73e9P8J.
>
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-tool...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.



--
Alfredo Quiroga-Villamil

AOL/Yahoo/Gmail/MSN IM: lawwton

[Joseph Lust]

Thanks Alfredo. I'll try the intra-browser communication for now as it will hopefully take the least overhead.

Sincerely,

Joseph