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
-~----------~----~----~----~------~----~------~--~---
