Brainstorm thread - GWT driven client side MVC framework

[Rebornspirit]

Hi, all

I've been working with GWT for several weeks now and I would like to
have a discussion about how a GWT/AJAX based MVC framework can be
designed. I guess more people out there have already formed some ideas
about how to communicate between different - let's call it - views.
Perhaps you would like to share some thoughts, some concepts that you
have tried but have failed because of the asynchronous nature and you
would like to share so others will not make the same mistake.

So for example what would be a good approach to communicate between
the following views (just a silly example):

- search page - on enter we lookup the corresponding data and show the
- result page - clicking on a single line leads us to the
- detail page of a customer

You all know this basic example, but how do we pass parameters along
the different views, just call a corresponding method on the some
controller bound to the next view which will take care of it, or make
something more abstract, like you would have for example in Spring
MVC, a dispatcher, a view resolver, a ModelAndView object which
contains for example the ID of the customer (Map entry) which will be
passed to the customer detail screen? I'm just starting with this
latter approach, can't say much about it, just started working with it
an hour ago :-)

And what about externalizing the flow?

The thing is, how can we build large business applications, that have
some kind of process flow abstraction, lets call it MVC? Perhaps such
a MVC framework could be a nice GWT subproject ;-)

I look forward to your replies, I'll post my experience with my
approach by the beginning of next week.

Grtz

[Maarten Volders]

I thought this would be an interesting thread, but it seems I'm kinda wrong again :-)

I'm still curious on how people are dealing with communication between composites in big applications, are you using a generic (MVC like) approach so that all composite views are unaware of each other or you just call other composite views directly to call them and to inject data to them and don't care about entangling everything?

Grtz

[ekstesi]

This is along the lines of the questions we are asking in another
thread.

I was starting to imagine the best way to consider this for efficiency
might be :

the Entrypoint, launches the Search page composite.

This composite has some basic UI logic, this may be for doing some
sort of fancy client side UI magic that doesn't require any server
intelligence

I thought of the idea of a very thin UI controller that manages all
composites..

so the entry point actually loads the UI controller which knows to
load the search screen first.

Then when user enters text , the UI controller perks up and knows to
do some rpc stuff to maybe request search matches passed to a
serverside controller.
objects are passed back from the server controller to the UI
controller which knows how to present the payload, in this case, this
could be async for auto-completing the text in the search field and
showing a count of matches for that term. just like google suggest.

When the user actually submits a real request. the UI controller again
talks to the server sidecontroller...and now the serverside controller
tells the UI controller to repaint the composites for the new screen,
and I assume some sort of cleanup for memory

from here I think the process is the same. I call this pattern fat n
skinny : )

What do you guys think of this ?

Would this make sense...

my goals are.

- UI should be super thin
- UI should be smart enough to control its widgets based on user
interaction without going back to the server
- the UI should ultimately be controlled from the server in terms of
rebuilding composites
- the server should do all heavy processing
- should be the smallest transports for requests and payloads over
rpc,, so they are light and fast ( is this what beans are for ?)

please let me know what is wrong with this... as we are considering
building a large app with ideas from this.

thanks

On Mar 29, 10:32 am, "Maarten Volders" <maarten.vold...@gmail.com>
wrote:

> I thought this would be an interesting thread, but it seems I'm kinda wrong
> again :-)
>
> I'm still curious on how people are dealing with communication between
> composites in big applications, are you using a generic (MVC like) approach
> so that all composite views are unaware of each other or you just call other
> composite views directly to call them and to inject data to them and don't
> care about entangling everything?
>
> Grtz
>

[mP]

As a wild generalisation, I would go so far as too say there is no
need for traditional MVC in a GWT application. I guess the real
question is why is a controller needed ? I cant think of a use case
where a controller would benefit a GWT app.

[Maarten Volders]

Hi,

for the moment I'm doing a prototype that tries to provide a very thin client UI layer. I'm wrapping things up, still having some issues with controlling the history, but I'll post something by the beginning of next week. In short:

- Each 'page' you see is called a View, the class View is just a wrapper of a composite with some extra feature for showing and hiding the View
- Each View is unaware of any other View, all flow between Views is controlled by Spring Webflow, and utilizes also the History which allows you to use the browser navigation buttons back and forward and still being able to work with the flow engine
- When the application starts - onModuleLoad - I load some module configuration needed to get started (defined in the Spring context configuration)
- The module configuration also contains the initial flow (Spring Webflow flow id) I want to start
- The flow id is passed to my FlowExecutor, onSuccess I return the name of the next View and the model (if any) = ModelAndView object
- All Views are mapped to a view name on startup, I pass the ModelAndView object to my client side Dispatcher which resolves the View based upon the View name, triggers the rendering of the View - hiding any other View being show - and showing the new View, and also applies the model
- All inner View communication, like when you press the search button on the search page - is handled by the View itself using listeners, I found it too much overhead to externalize this inner page flow, but you can figure out something where you can use Spring webflow also for inner View communication

- Now when you have all the search results and click and an item the FlowExecutor gets triggered (passing the flowexecutionkey, itemid, floweventid)
- The serverside flow engine gets triggered and returns the View name of the next View ( i.e. personDetail)
- The flow engine also looks up the initial data to show the page, in this case the item based upon the item id and puts it back on the model (I only retrieve the data I need to initially view the page, all others things are the responsibility of the View itself and should be done async)
- The dispatcher receives the ModelAndView data and dispatches to the correct View and passing / requesting to apply the model

I hope I wrote everything down in the right sequence, don't have much time now :-) But let me hear your opinions

It is just a first try :-)
But it is nice to have Views which are all independent of each other, or even have a client which has no hardcoded data in it for controlling 'flow'. I really hate to see too much hardcoded stuff on the client, because eventually it is all JavaScript, not some server side code!

Grtz

[Hugo Lima]

If i understand, you don't want to hard code all of the application's
flow in either client or server sides, you could build some kind of
state machine with the help of a database, that configures the user's
possible interactions, and then have
a client side controller that calls a RPC to ask for a new state (I've
seen other posts regarding this subject).
But this decoupling of the flow from the code has nothing to do with
keeping the ui thin (like ECHO2), because you must hard code all of
the"views" ui building logic in the client. What i am saying is you
don't hard code the flow, but you must hard code the all of the
state's change logic(e.g when the server says the new state is
"CustomerData" the client must render the "CustomerData" view).
If all the views have the knowledge of where to get their's data (e.g.
RPC calls), then when a state change occurs the new view can simply
query the source for new information (e.g.
RPC::getCustomerData(customerId)).
You could implement this in a single application/module.

[Hugo Lima]

Hi, Maarten.

I'm sorry i didn't read you last post.
That is a great idea, i think you are on the right track.

[Maarten Volders]

hi Hugo,

well... it is just a first attempt, I'm still not sure if it is a good idea to also externalize all 'inner view' communication. Perhaps it will just make things harder :-) Perhaps I'll do some testing on this in the upcoming weeks...

Grtz