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 concepts. note that I got feedback that two types of > place events that i implemented here are not necessary and that one would be > sufficient, but i haven't had the time to refactor yet. it should however > capture the essence of what a place service does. I too am waiting for 2.1 > to settle and see where Google wants to go with that, in the mean time this > is a production system description: > > http://code.google.com/p/handlebars/wiki/PlaceServiceOverview > > 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, > >> I checked this URL > >>http://code.google.com/webtoolkit/doc/latest/ReleaseNotes.html, > >> for GWT 2.1 but didnt find much information about Activities. Is it > >> explained somewhere else. Can you share such info/link so i can look > >> into it dont reinvent everything. I am about to start implementing > >> "switch view only when ready" pattern but if its present in 2.1 then i > >> would love to use it instead of writing my own. > > >> Thanks, > >> Ravi. > > >> On Jun 17, 10:59 am, Thomas Broyer <t.bro...@gmail.com> wrote: > >> > On 16 juin, 15:31, Tristan <tristan.slomin...@gmail.com> wrote: > > >> > > sounds like you're reinventing the place service, with event bus, with > >> > > local cache rpc service, but doing it in a new, innovative, complex > >> > > and if the code grows on you perhaps unintelligible way. if you're the > >> > > only one who will support this ever, that may work. otherwise i would > >> > > seriously look into a bunch of mvp-like frameworks out there and look > >> > > at how place services/managers, local caches, and event buses are > >> > > implemented. you don't need to use the framework, but the concepts are > >> > > very helpful to organize the code. they're straightforward and most > >> > > people understand the design. > > >> > Sure Ravi is "reinventing" the "place service" here. Sure he should > >> > move its "cache" to a "local cache rpc service". But the main issue > >> > with his code is that he has a "synchronous method" which has to do > >> > something "asynchronous". > > >> > Now, most "place services & MVP" implementations I've seen don't use > >> > the "switch view only when ready" pattern. The "activities" coming > >> > into GWT 2.1 do that however. > > >> -- > >> 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<google-web-toolkit%2Bunsubs > >> cr...@googlegroups.com> > >> . > >> For more options, visit this group at > >>http://groups.google.com/group/google-web-toolkit?hl=en. > > > -- > > 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<google-web-toolkit%2Bunsubs > > cr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. -- 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.
