Thanks Jason, I understand what you are getting at, and I have come across this before, but hadn't considered using it here.
I'm using this project as an opportunity to learn and to see how 'right' I can get it. If someone were paying me, then I wouldn't be so fussy, but my feelings are this: The MenuItem's presenter (and it's not GWT's MenuItem) should deal with user gestures from the MenuItemView - I like the simplicity of 'Click->fire event' and I don't like the idea that MenuItem+MenuItemView would not be a stand-alone unit and would rely on parent widgets to sort out what is going on. If the MenuItem presenter isn't going to do anything except pass through a reference to the MenuItemView, and the MenuItemView is going to hold the place token field, then why don't I just say to hell with it and get the MenuPanel to send Labels to the MenuPanelView. It would save all that faffing about. I think I'd like to stick with the MenuItem presenter firing an event if I can, and see if I can come up with a 'politically correct' answer to this. I'm sure there must be someone out there, or something on the web which can tell me how to do it, or explain why it's not possible, or give me a better solution altogether. If I find something, I'll post it. Thanks again, Ian http://examples.roughian.com 2009/9/3 Jason A. Beranek <[email protected]> > > Ian, > > Ok, I think I understand what are trying to do. Let me expand a bit on > the addMenuItem( Object i..); example in something a little less > abstract. First, I'm assuming your MenuItem is not equivalent to the > GWT MenuItem class, if it is the solution would be different. Note, I > don't have a full example so mileage may very. The approach is meant > to deal with MVP of list type interfaces, where the list items (i.e., > MenuItem) bubble events up to a list presenter (i.e. MenuPanel). > > The example assumes that instead of each MenuItem reporting > PlaceChange events, MenuItem selection events are bubbled from the UI > up to the MenuPanel presenter (through its view) and the MenuPanel > presenter fires the PlaceChange event. Effectively, a MenuItem's > display becomes a simple widget within MenuPanel's view and doesn't > require its own presenter (the presenter's work is handled by > MenuPanel's presenter). > > First, some simple setup: > > public class MenuPanel { > > interface Display { > > void addMenuItem( String label, String token ); > > HasSelectionHandlers<String> getMenuItemSelectionButton(); > > void clearMenuItems(); > } > > ... > > } > > The above class shows a possible piece of the MenuPanel display > interface. I am assuming in the above that a MenuItem takes a label > that defines how the UI displays the object and the token as you > describe above for the associate place/location when the item is > clicked. In this example, the MenuPanel presenter determines the menu > items required for the current place and calls addMenuItem to tell the > MenuPanel view the MenuItem widgets to construct in the UI. The > clearMenuItem method can be used clear the MenuItems to rebuild the > specific items when the page changes. Notice that I included another > Display method called "getMenuItemSelectionButton()", this returns an > object the MenuPanel presenter can add a handler to so it can detect a > MenuItem selection event. Here's an example of the bindDisplay method: > > void bindDisplay( Display display ) { > this.display = display; > > //Listen for a token selection when the user picks a MenuItem > display.getMenuItemSelectionButton().addSelectionHandler( new > SelectionHandler<String>() { > > > public void onSelection( SelectionEvent<String> event ) { > > //Call MenuPanel private method to fire PlaceChangeEvent on > EventBus, selected item represents the Place token > doPlaceChange( new PlaceChangeEvent( event.getSelectedItem() ); > > }); > ... > } > > With the above in place, the MenuPanel view becomes responsible for > translating the user input on MenuItems (such as a native Click > event) into a logical SelectionEvent > > The above approach breaks down if the list items require a lot of data > to build or if the list items require additional logic beyond the > scope of the containing presenter. As I said in my previous post, this > approach also suffers from similar interface management problems as > DTOs. > > -Jason > > On Sep 2, 7:44 pm, Ian Bambury <[email protected]> wrote: > > Hi Jason, > > Thanks for the reply and suggestions. > > > > My idea was to have the MenuPanelView have a factory method for > > MenuItemViews. > > > > The MenuPanel presenter has to determine what menu items are required > > depending on whether the user privileges. > > > > I don't really understand how your addMenuItem( Object i.... ); method > would > > work. > > > > I can't really have each view just create its own presenter (as a general > > principle) as far as I can see. What I want to end up with is a menu item > > which fires a PlaceChange event when it is clicked - for this it needs a > > token, for example GWT/Panels/SimplePanel (where GWT is an item in the > > top-level menu, Panels is an item in the GWT menu, and SimplePanel is a > > final page of information to be displayed). > > > > Each menu would set itself up if required by listening for a PlaceChange > > event, and if a page recognised it was needed, it would display itself. > > > > This, though, means that the MenuPanel needs to do a bit of setting up > for > > the menu items and associated pages. > > > > It isn't actually quite the mess it probably sounds. All the hard work is > > done in a hierarchy of a few abstract classes, so to create a new menu, > all > > you really need to is specify the menu text and the page it refers to, > But I > > do get the feeling I'm stretching the MVP pattern well out of shape in > order > > to get it all to work. > > > > Ian > > > > http://examples.roughian.com > > > > 2009/9/3 Jason A. Beranek <[email protected]> > > > > > > > > > Ian, > > > > > When you mention your current solution fetches the MenuItem view from > > > the MenuPanel view, do you mean the MenuItem view(s) are already in > > > the MenuPanel view or do you mean the MenuPanel view acts as a factory > > > for MenuItem views? I have been experimenting a bit with the former, > > > though I imagine the latter would work. One approach I've also tried > > > for list based structures that might work for your list of Menu Items > > > is to make a function on the display interface to add the data > > > elements to build the MenuItem view from primitives: > > > > > interface MenuIPanelView { > > > void addMenuItem( Object i.... ); > > > } > > > > > This presents a similar mapping problem to managing DTOs if the data > > > your are representing in the view changes or the underlying model > > > object populating that data changes, but it is an option (especially > > > if the individual MenuItem's events could be bubbled up to the > > > MenuPanel and reduce code size). > > > > > The above are more what I've thought about or tried, and I don't claim > > > to be any expert. I've been trying to figure if there is some magic > > > approach that makes composition work, however I haven't seen a clear > > > winner yet. I hope we'll get from Ray Ryan's sample code when he's > > > able to put it together. Most non-GWT examples I've looked at seem to > > > imply that you don't directly instantiate the presenter, but that the > > > presenter is created when the view is constructed (and the view is > > > passed as an argument to the presenter at that time). For some reason, > > > this just feels wrong to me, though I can't put my finger on why this > > > bidirectional coupling would be an issue since the view is already > > > tightly coupled to the presenter. I don't know how well such an > > > approach would work with dependency injection or UI binder (my gut > > > feel is it wouldn't really). > > > > > I'll be interested to see anyone else's thoughts. > > > > > -Jason > > > > > On Sep 2, 1:22 pm, Ian Bambury <[email protected]> wrote: > > > > Hi all, > > > > > > I have a question for the GWT-MVP experts out there. If there is a > more > > > > suitable forum, please let me know. > > > > > > I have a menu panel which contains a flowpanel for menu items, and > > > another > > > > flowpanel where the required page will display itself when the > associated > > > > menu item is clicked. > > > > > > The MenuPanel presenter is creating menu items and sending the > MenuItem > > > > views to the MenuPanel view to be added. > > > > > > The problem is this: If there are a number of possible MenuPanel > views, > > > then > > > > the MenuPanel presenter can't know which MenuItem view it should > create > > > > (blue, green, red, text-based, image-based, therefore presumably each > > > > MenuPanel view should decide. > > > > > > The MenuPanel view can't be the creator of the MenuItems because it > > > doesn't > > > > know which menu items should be created (for example, you might be > > > allowed > > > > to see admin menu items or not - this kind of logic should not be in > the > > > > view). > > > > > > So my current solution is to get the MenuPanel presenter to fetch the > > > > MenuItem view from the MenuPanel view. > > > > > > Now, if you are still following me, is this what I should be doing? > Or > > > have > > > > I completely lost the plot somewhere along the line? > > > > > > Although there are endless (generally slightly contradictory) > > > explanations > > > > of MVP (and please note that I don't think I need another explanation > of > > > > that), there isn't anything I can find that explains how to nail > together > > > > the various self-contained MVP widgets - at least, not in a way that > > > allows > > > > an event bus to operate. > > > > > > Ian > > > > > >http://examples.roughian.com > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
