Thanks for your feedback, Thomas. It gave me lots of food for thought. This is new territory for me and so I wanted to explore your suggestions before responding.
So far, I've been able to get something working using the single HasSelectionHandlers<String> approach you described. The approach I took was to have my View: a) extends Composite b) implements HasSelectionHandlers<String> c) can implement addSelectionHandler(...) by simply calling Widget.addHandler(handler, SelectionEvent.getType()) because Composite extends Widget d) inherits an implementation of fireEvent(...) from Widget c) have various SelectionEvent.fire(this, "targetObject:userAction") calls throughout my code invoked in response to ClickEvents arising from "user action" widgets (simple Label) Does that sound about right? It's working fine and I can see how I could replace the <String> with <Pair> in the HasSelectionHandlers<I> interface to improve type safety and avoid string parsing. But I'm unclear as to how the "action-specific" strategy (ex. HasSelectionHandlers<X> getDiscard()) would work in terms of the View implementation. What would actually be returned to the Presenter? In other words, what would the SelectionHandler<X> to be added to? There is no widget that aggregates all of the 'discard' widgets and so I'm left wondering what would implement the HasSelectionHandlers<X> interface. A custom collection-type class? Please let me know if my question has been lost in this admittedly convoluted phrasing. Thanks again for your help. Jeff On Jan 11, 5:46 pm, Thomas Broyer <t.bro...@gmail.com> wrote: > On 9 jan, 01:16,JeffIrving<jeffirvin...@gmail.com> wrote: > > > Hello everyone. > > > I'm hoping to elicit some suggestions regarding how to apply an MVP > > design to my particular application. My situation is that I have some > > tabular model data that includes row-specific user actions (ex. > > 'discard', 'reprocess', 'submit', etc.) that are ultimately presented > > as widgets (ex Label) to which action-specific ClickHandlers should be > > attached. Getting the model into the view has been discussed in other > > postings and I'm leaning towards passing in the model objects directly > > rather than having the Presenter decompose them into more generic > > elements. But I'm totally at a loss as to how the Presenter.Display > > interface should be structured to retrieve the row-specific user > > actions in a way that allows me to attach the correct ClickHandler > > logic. > > We use SelectionEvents in this case. There are several ways to chose > from: > - use an HasSelectionHandler per action where X is either an object's > identifier or an object itself, we chose to use identifiers): > public HasSelectionHandler<X> getDiscard(); > public HasSelectionHandler<X> getReprocess() > ... > - use a unique HasSelectionHandler<X> where X is either a String > composed of the action and the object's identifier (e.g. discard:1, > reprocess:2, ...) or a Pair object with getAction() and getTargetObject > () > > > I've looked at the "Contacts" example and it was very helpful to > > demonstrate how to determine which row/Contact was clicked. But the > > same ClickHandler logic is applicable to each row. In my case, each > > displayed "user action" requires unique processing. > > In our case, the ClickEvent-to-SelectionEvent is handled by the view > (as well as the row-index-to-item-identifier mapping, which somehow > breaks the MVP design pattern too), the presenter only deals with > SelectionEvents. > > You can keep using the Contacts same approach and just add a method to > retrieved the action too: > public int getClickedRow(ClickEvent event); > public String getClickedAction(ClickedEvent event); > or similarly to what I proposed above: > public Pair<String,ModelObject> getClickedAction(ClickEvent event); > where Pair could be a Map.Entry or whatever.
-- 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.
