Well, I pretty much agree with Eric. I believe the event should'nt depend on the listeners, rather it should be defined in consideration of the presenter that fires it. The attributes stored in the event are the ones that make sense in its own context (that helps a lot I know ^^). In your registration example, I'd fire a RegistrationSubmittedEvent that holds all the details of the registration. No need to create a data object, your event is your data object. However, you can instantiate model objects in the presenter and hold these objects in the event instead of duplicating instantiation code all over the listeners. But in that case, be careful, your model objects are shared and shouldn't be edited (consider making them immutable).
I hope that helps ! On 20 juil, 18:07, mk <[email protected]> wrote: > In case future presenter 3q requires a specific information which is > not sent in the old event thrown by presenter 1. > Than in future, we have to add that specific information in the event > thrown by presenter 1 .. right ? > > I mean information passed in the event is limited by what is required > by listening presenters?. > > For eg a registration view may have different textboxes for first > name, address etc and the intial event may only be thrown with the > information that "submit button is clicked". And later on for future > presenter 3q we may have to add first name in the event thrown by > presenter 1. > > Do you create event in the first place with all the information > available to accomodate all future presenters? > Do you create a "Value object" to pass this heavy weight information > from one presenter to another? > > Thanks in adv....Plz respond.... > > On Jul 20, 8:21 am, Eric <[email protected]> wrote: > > > > > On Jul 19, 9:04 pm, mk <[email protected]> wrote: > > > > Thanks a lot. > > > > Now if there are three DIFFERENT presenters (say 2a,2b,2c) listening > > > event from 1st presenter. > > > Than do 1st presenter has to create event with all the appro. values > > > required by 2a,2b,2c presenters? > > > In fact, you shouldn't be thinking about presenters 2a, 2b, or 2c > > when writing presenter 1. Presenter 1 should just fire change > > events when its data changes. Presenters 2a, 2b, 2c, and future > > presenters 3q and 7f should simply add event handlers to > > presenter 1 and pick out the information they need. > > > Eric -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
