Thanks for the comments Alex and Robert,
I'm aware that this decoupling is against GWT's philosophy.
The reason I'm still trying to keep it separate is because these are
actually separate projects (each game) with different developers
working on each part with separate svn code repos. The game code
changes very rapidly. The pseudo code I mentioned in the post was just
a crude illustration of the logic, although the design would be
something more polymorphic.
The portal's fundamental requirement is to be not only be able to
dynamically load each game on-demand, but also to be able to send game
client commands viz. launch, play, pause, quit, add-player, and, also
have game server side control e.g register-checkpoint-callback, fetch-
progress-report. I have the flexibility to have all games run off the
same Tomcat server process along with the portal, but I'd like to keep
their entry points and services separate from the portal's. The client
side communication between portal and game should NOT be over HTTP,
similarly server side communication between portal and game should NOT
be over the wire. So it is in fact a tight/native portal-to-game
integration that is needed.
So what I'm really asking here is just project code modularisation. As
in, I just need the flexibility to be able to develop code
independently and be able to integrate the games when deploying the
portal. The games need to be able to run in their own entry points so
their devs can test them out independently without needing the portal.
And I should be able to fetch the latest code for all games and test
the portal. Rebuilding/redeploying all the code is not a major concern
for us.
---- Some deeper design details ----
For the game plugin interface I have defined a client side interface
(IPortalGameClient) and server side interface (IPortalGameServer) to
abstract out all client and server communication between portal and
game. Any game that wishes to plug into the portal needs to implement
the client and server interfaces. On the portal client side a
GameProxy (which also implements the IPortalGameClient) is used to
talk to the Game client that can handle failure-retries, caching, etc.
The portal needs to do the heavy lifting of managing sessions, player
logins, check-pointing, resuming after failure, etc.
------------------------------------
Whew! I rambled on there .. sorry bout that. Appreciate any help on
figuring this out.
thanks,
-Gautam.
On Jul 8, 3:33 am, Alex Dobjanschi <alex.dobjans...@gmail.com> wrote:
> So you want to have a single app (your dashboard, but independently develop
> each game as a totally separated gwt app, is that right? Total flexibility,
> no?
>
> First, there have been countless questions about how to communicate between
> 2 (supposedly) independent GWT apps.
> Secondly, this design, despite being flexible in theory, is by far tight in
> practice. Imagine you want to add a 3rd game, you will have to do another IF
> and full build of the dashboard, just to show it up.
>
> What I recommend is have a lightweight dashboard, with just a GameData
> widget (that contains the link to the actual JS, an image, etc). When you
> click on one, you should either navigate (be redirected) to an Url, OR
> inject the JS and have it look for a specific contained (like <div
> id="gameSpace">).
>
> Regards,
> Alex
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
