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.
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
On 3/28/07, Rebornspirit <maarten.vold...@gmail.com> wrote:
> 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.
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
> On 3/28/07, Rebornspirit <maarten.vold...@gmail.com> wrote:
> > 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.
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.
On Apr 4, 5:16 pm, "ekstesi" <ekst...@gmail.com> wrote:
> 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
> > On 3/28/07, Rebornspirit <maarten.vold...@gmail.com> wrote:
> > > 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.
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!
> 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
> > On 3/28/07, Rebornspirit <maarten.vold...@gmail.com> wrote:
> > > 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.
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.
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
On 4/4/07, Hugo Lima <lima_h...@hotmail.com> wrote:
