So I will just adress things you see as a benefit, ie decoupling of server calls from presenters / views and decoupling views from presenters.
First, though, I think you shouldn't call it MVP. In my opinion it seems that what you're doing is MVC where the model is helped out by RPC. There is already so much variety in the meanings of this (MVP, MVC, etc...), especially with Activities and Request Factory coming into the picture that terminology is becoming important. Not because I don't know what you're describing, but because someone new to the frameworks will get thoroughly confused. As for the benefits of what you offer, i.e. the decoupling points. Multiple frameworks out there already accomplish decoupling. Combine the fact that those benefits already exist in frameworks out there today with the concern you raised: "At some point you may forget that who is handling these vents and how the data is reaching from server to view etc, basically you wont be able to just Ctrl + click to traverse the code tree in eclipse or netbeans. Code reading may be bit difficult. If someone can write a plugin for such code readability like Spring plugin then it will be very nice." That fact alone would make me want to never ever learn what you have to offer. This is almost getting into the realm of product development :) ie. as a customer what benefits do I get from your framework? I think you have some interesting ideas about the richness of event interactions, but after reading your proposal I still don't feel a compelling reason to write yet another framework. Where do you feel is the crucial difference / benefit in comparison? I'm not familiar with all of these frameworks, but here are some to compare to: gwt-presenter: http://code.google.com/p/gwt-presenter/ gwt-dispatch: http://code.google.com/p/gwt-dispatch/ gwt-platform: http://code.google.com/p/gwt-platform/ handlebars: http://code.google.com/p/handlebars/ I'm sure there are a lot more, these are the ones that immediately come to mind. On Jun 17, 2010 12:03 PM, "Ravi Sharma" <ping2r...@gmail.com> wrote: Hey guys, I have been thinking about all this MVP architect(i am new to it) and history management and show on ready pattern etc and came up with following design/idea. Lets see if it will work and feel free to comment on it. 1) Something happens on UI(Some User activity like mouse click, keyboard press etc) 2) Raise an EVENT with required data from UI. something like CLIENT_EVENT_% or VIEW_EVENT%(i.e.CLIENT_EVENT_PROFILE_LINK_CLICKED) , basically i want to have separate naming convention for all client/UI events. 3) Presenters will be listening to these events. On Getting a event presenter can do following things 3.1) Create a history token and in history handler raise event to get data from server SERVER_EVENT_GET_DATA (Optional, if you want to keep history) 3.2) or directly raise event (i.e.SERVER_EVENT_GET_DATA) to get data from server. (If You don't want to keep history) 4) Different Data Handlers or Presenter it self will be listening to these events SERVER_EVENT_% and make the server call. 5) once server call returns raise another event like DATA_MODEL_SUCCESS %/DATA_MODEL_ERROR% with data/error returned by Server. 6) Presenter or View(I will prefer it to go to View, although it may break classic MVP) will be listening to these events(DATA_MODEL%) and will display the view/error accordingly. Now if we want to use Client side cache in this flow then handlers of events(at step 4) like SERVER_EVENT_GET_DATA / SERVER_EVENT_% can first check in Cache, if found then raise the same event(DATA_MODEL_SUCCESS%) as it will be raised by server returned asyncallback functions. So what we will achieve here. Our server RPC call will stay independent of cache/view/presenter etc. Our View stay independent of cache or server calls even independent of presenter too.. I would make my view listen to events and show the data. Our Presenter dont need to know server call details, in case you are planning to implement the separate data handlers which can use cache as well as RPC. Downside 1) For one user action i will be raising 3 Events like CLIENT_EVENT_% and then SERVER_EVENT_% and then DATA_MODEL_SUCCESS%/DATA_MODEL_ERROR %. So need to do lots of efficiency check, but good things is how many clicks a user can click on an application on browser which is running on atleast P4 machine, 1GHZ. 2) At some point you may forget that who is handling these events and how the data is reaching from server to view etc, basically you wont be able to just Ctrl + click to traverse the code tree in eclipse or netbeans. Code reading may be bit difficult. If someone can write a plugin for such code readability like Spring plugin then it will be very nice. 3) One day you decide not to use cache, just remove it without affecting any other code. Basically everything in pluggable/ unpluggable 4) One day you feel like creating same application for Mobile or new web look create ur view again. This is what MVP gives. Basically i am quite excited about using this new MVP archt. and History and event bus(I Love Eventbus, it solves me lot of things and long chains of async calls and also it gives me opportunity to make client side calls asynch(i.e. if i find that data is present in cache then i raise the event and view/presenter handler will be called in async was as if server has returned) happy coding guys. Feel free to comment. Thanks, Ravi. On Jun 17, 1:45 pm, Tristan Slominski <tristan.slomin...@gmail.com> wrote: > here's an example i wrote that walks through place service, hope that helps > with place service c... > 2010/6/17 Jaroslav Záruba <jaroslav.zar...@gmail.com> > > > > > I searched too but have found only this: > > >http://code.google.com/p/google-web-toolkit/source/browse/branches/2.... > > <http://code.google.com/p/google-web-toolkit/source/browse/branches/2... .>It > > seems to be missing in 2.1 m1 yet. > > > On Thu, Jun 17, 2010 at 12:30 PM, Ravi Sharma <ping2r...@gmail.com> wrote: > > >> Hi Thomas, > >... > >> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com><google-web-toolkit%2Bunsubs cr...@googlegroups.com> > >> . > >> For more options, visit this group at > >>http://groups.google.com/group/google-web-tool... > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com><google-web-toolkit%2Bunsubs cr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit... -- 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-tool...@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.
