Re: Menu Item and MVP (2)
Thanks! That's exactly what I was looking for. I added a few things. I added 2 methods to the HasCommandHandlers interface: - void setHandlerEnabled(boolean isEnabled); - boolean isHandlerEnabled(); This way, my presenter can disable MenuItems using: display.getExportCmd().setHandlerEnabled(false); Cheers, 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 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.
Menu Item and MVP (2)
Hi,
This message was supposed to be an answer to the "Menu Item and MVP"
discussion. But it does not appear, I probably made a mistake, so I
put it here in a new discussion.
The initial message posted by "mic" was :
>> Just sharing some thoughts
>>
>> Would the MenuItem class need to implement HasClickHandler so that
>> when a MenuItem is clicked, the action can be handled in the
>> presenter. At this time, the MenuItem needs an object that implements
>> the Command interface, so the view seems to know about the presenter.
>> I would like to know what others think about this.
This is probably a late answer to the initial question.
Anyway, I've made a quite simple implementation that solves the lack
of something like a HasClickHandlers dedicated to MenuItem.
Here I give you the solution I've built.
First, we need something like a "HasCommandHandlers" interface instead
of HasClickHandler. This will allow the presenter to handle a click on
a MenuItem.
public interface HasCommandHandlers extends HasHandlers {
// equivalent to the addClickHandler in the HasClickHandlers
interface
public HandlerRegistration addCommandHandler(CommandHandler handler);
}
We create a CommandHandler interface only to stay in line with the
naming convetion for the handlers.
public interface CommandHandler extends Command {
// this interface is empty
}
The Presenter :
public interface Display {
HasCommandHandlers getMenu1();
HasCommandHandlers getMenu2();
...
}
public void build() {
view.gerMenu1().addCommandHandler(new CommandHandler() {
public void execute() {
// do what you need
}
});
}
...
}
So this is standard MVP implementation.
Now the View.
We have to create a subclass of MenuItem implementing
MenuPresenter.HasCommandHandlers, so we will have a MenuItem
implementing the HasCommandHandlers interface just like a PushButton
implements HasClickHandlers.
public class MyMenuItem extends MenuItem implements
HasCommandHandlers {
//
// extends MenuItem
//
public MyMenuItem(String text) {
super(text, (Command)null);
}
// ---
// implements HasCommandHandlers
// ---
@Override
public HandlerRegistration addCommandHandler(CommandHandler
handler)
{
// call MenuItem setCommand() as the CommandHandler is
a Command !
setCommand(handler);
return new HandlerRegistration() {
@Override
public void removeHandler() {
// remove the command
MyMenuItem.this.setCommand(null);
}
};
}
@Override
public void fireEvent(GwtEvent event) {
// do nothing because we do not receive events
}
}
The view as usual implements MenuPresenter.Display.
This seems to me a quite simple and straight solution.
Your comments are welcome !
HTH
Yves
--
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.
Re: Menu Item and MVP
Thomas,
I need to think more about this approach. Ray mentioned in his talk
about having too many events and performance. Does your approach not
lead to that?
-mic
On Apr 1, 3:16 am, Thomas Broyer wrote:
> On Apr 1, 1:15 am, Nathan Wells wrote:
>
> > Thomas,
>
> > I've heard of your approach before, but I'm not clear on the
> > implementation... are you passing the presenter itself into the view?
> > or are you passing instances of event handlers? The difference seems
> > trivial, but in practice (as I imagine it, anyway) seems large:
>
> >http://etherpad.com/sIAaiCfuiG
>
> > Let me know what you think. I would assume the first way is what your
> > referring to in your comment above, which implies that it is a View
> > layer responsibility to deal with HandlerRegistrations and the like.
> > Is that correct?
>
> Yes. It makes a few things much easier for me:
> - I can use @UiHandler in the view, which makes the whole thing more
> readable (on the down-side, I used to create a class that implement
> all required handlers instead of using an anonymous class per handler;
> UiBinder doesn't do this optimization (yet?) with @UiHandlers)
> - I can use event delegation in the view
> - The view methods are more "consistent" (get/setUserName and
> setUserNameEnabled(boolean), vs. getUserName->get/setText and
> setUserNameEnabled(boolean); this elad people to ask for a HasEnable
> interface, which wouldn't solve anything as you'd still need
> getUserName->HasText and getUserNameEnablable->HasEnable), even more
> when also dealing with non-widget UI elements: I implemented a login
> form with a in the HTML page which action="" is set to callback
> a GWT method ($wnd.__form_callback = $entry(vi...@onsubmit())) and
> had to create a dummy HasClickHandlers to return as the
> "HasClickHandlers submitButton()"; with a Listener is way easier: the
> onSubmit just calls back the listener.submit().
> - I have one "screen" where the user can add files to upload, each
> "file" is a line composed of a FileUpload and a "cancel" button next
> to it that removes the "line" from the screen (and therefore "cancels
> the file" before the form is submitted), already uploaded files
> (unpredictable number) are shown as a label with a "delete" button
> next to it. Add to this that files are grouped into dynamic,
> unpredictable "groups". Previously, I did everything with a
> SelectionEvent where the value was something like "add: group>", "cancel:", or "delete:" (I use event
> delegation in the view). Now, instead of firing a SelectionEvent with
> a specific value, I just call the listener's addFile(String group),
> cancelFile(String fileId) or deleteFile(String fileId).
> Sure I could have defined new events instead of doing it all through a
> SelectionEvent but it wouldn't have make things much easier, with more
> files to maintain.
>
> As for the implementation, I currently have something like:
> public class FooPresenter {
> @ImplementedBy(FooView.class)
> public interface Display {
> void setListener(Listener listener);
>
> void setThisVisible(boolean visible);
>
> void setThatEnabled(boolean enabled);
> }
>
> public interface Listener {
> void save();
>
> void close();
> }
>
> private class Handlers implements PlaceHandler,
> SomeOtherBusEventHandler, Listener {
> ...
> }
>
> @Inject
> public FooPresenter(Display view, EventBus bus) {
> Handlers handlers = new Handlers();
> bus.addHandler(PlaceEvent.getType(), handlers);
> bus.addHandler(SomeOtherBusEvent.getType(), handlers);
> view.setListener(handlers);
> }
>
> ...
>
> }
>
> public class FooView implements FooPresenter.Display {
> @UiField Button save;
> @UiField Button close;
>
> private FooPresenter.Listener listener;
>
> ...
>
> public void setListener(FooPresenter.Listener listener) {
> assert listener != null;
> this.listener = listener;
> }
>
> @UiHandler("close")
> void onCloseClick(ClickEvent event) {
> listener.close();
> }
>
> @UiHandler("save")
> void onSaveClick(ClickEvent event) {
> listener.save();
> }
>
> }
>
> I'm using a Listener *interface* so the view doesn't have direct
> dependencies on the presenter's behavior (I could therefore mock a
> Listener and make a small app to "manually test" my view without
> actually having any presenter, event bus, etc.)
>
> I decided to switch to this design instead of HasXxxHandlers when I
> saw Ray's work on RequestFactory: """In the Wave style: the view
> (editor) has a single listener for its semantic operations."""
> The main difference is that I do not have an interface for each
> presenter with its impl class (interface FooPresenter / class
> FooPresenterImpl implements FooPresenter, FooPresenter.Listener) so my
> presenter class doesn't itself implement the listener interface (it
> would also "pollute" its public API, which is not a problem in Ray's
> case where no other object has a direct dependency on t
Re: Menu Item and MVP
Ian,
I feel the Google IO MVP approach is good because interfaces are used
to abstract the interaction between view and presenter. IMHO, the view
containing the presenter or the presenter knowing about the view makes
replacing presenters and views extremely difficult especially if you
do want to target desktop and mobile apps.
-mic
On Mar 31, 6:34 pm, Ian Bambury wrote:
> I've been looking into this for a chapter in the new edition of GWT In
> Action, here's where I'm at.
>
> The Google I/O approach to MVP has never sat well with me because, apart
> from the fact that the interface can get out of hand, it just seems wrong
> that the interface specifies that the view must, say, have something
> clickable and not leave the implementation to the view.
>
> So what I'm playing about with right now is (for the example you gave).
>
> There would be a couple of interfaces HasClose and HasSave which would be
> along the lines of
>
> public interface HasSave
> {
> void save();
>
> }
>
> There would be a couple of corresponding CloseHandler and SaveHandler
> classes e.g.
>
> class SaveHandler implements ClickHandler
> {
> private HasSave presenter;
>
> public SaveHandler(HasSave presenter)
> {
> this.presenter = presenter;
> }
> @Override
> public void onClick(ClickEvent event)
> {
> presenter.save();
> }
>
> }
>
> The presenter looks like this
> class Presenter implements HasSave, HasClose
> {
> View view;
>
> public Presenter(View view)
> {
> this.view = view;
> }
> @Override
> public void save()
> {
> view.setText("Save");
> }
>
> @Override
> public void close()
> {
> view.setText("Close");
> }
>
> }
>
> and the view like this
>
> class View extends FlowPanel implements HasText
> {
> Label label = new Label();
> public View()
> {
> Presenter presenter = new Presenter(this);
> add(new Button("Open", new SaveHandler(presenter)));
> add(new Button("Close", new CloseHandler(presenter)));
> add(label);
> }
> @Override
> public String getText()
> {
> return label.getText();
> }
> @Override
> public void setText(String text)
> {
> label.setText(text);
> }
>
> }
>
> in the AppController or onModuleLoad method, you'd just have the line
>
> RootPanel.get().add(new View());
>
> Does that make sense? Feel free to ask but I'm still not too far forward
> with this approach yet.
>
> For a tiny project, it's a bit of work (unless you have already written the
> interfaces and handler classes for some other project) but it does keep
> everything well organised in larger projects.
>
> Ian
>
> http://examples.roughian.com
>
> On 1 April 2010 00:15, Nathan Wells wrote:
>
> > Thomas,
>
> > I've heard of your approach before, but I'm not clear on the
> > implementation... are you passing the presenter itself into the view?
> > or are you passing instances of event handlers? The difference seems
> > trivial, but in practice (as I imagine it, anyway) seems large:
>
> >http://etherpad.com/sIAaiCfuiG
>
> > Let me know what you think. I would assume the first way is what your
> > referring to in your comment above, which implies that it is a View
> > layer responsibility to deal with HandlerRegistrations and the like.
> > Is that correct?
>
> > On Mar 31, 8:14 am, Thomas Broyer wrote:
> > > On Mar 31, 8:07 am, mic wrote:
>
> > > > Just sharing some thoughts
>
> > > > Would the MenuItem class need to implement HasClickHandler so that
> > > > when a MenuItem is clicked, the action can be handled in the
> > > > presenter. At this time, the MenuItem needs an object that implements
> > > > the Command interface, so the view seems to know about the presenter.
>
> > > > I would like to know what others think about this.
>
> > > I've recently migrated from views with many HasXxxHandlers getters to
> > > views with a setListener method that the presenter "injects" into its
> > > view. The listener defines "callback methods" such as save(), close(),
> > > italicize(), bold(), delete(), etc.
> > > It makes unit tests waaay easier to write (you don't have to mock each
> > > HasXxxHandlers, capturing each added XxxHandler, eventually mocking
> > > the XxxEvent, etc.) and in your case would make things easier: the
> > > Command is an implementation detail of the view.
>
> > --
> > 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.
--
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...@
Re: Menu Item and MVP
Nathan,
I think it does not clearly separate out the View and Presenter using
interfaces. This is the reason why I moved away from using menus.
I would prefer if there was a HasMenuItemClicked which returns the
menu item and the presenter would have code like
this.display.getABCMenuItem().addClickHandler() ( new ClickHandler() {
public void onClick(MenuItemClickEvent event) {
doAction();
}
});
I think this is much cleaner...
mic
On Mar 31, 5:05 am, Nathan Wells wrote:
> I created an "EventFiringCommand" class for instances like this.
> Basically, you put the event bus and the event to fire (or the code to
> generate the event) in the command. The Command should be a presenter-
> layer object, since it has no need to know about the view (and should
> be easy to unit test).
>
> Theoretically, you could just make inner classes in a Presenter for
> each Command you write. It all depends on how you want to organize
> your code and the needs of your specific project.
>
> On Mar 31, 12:07 am,mic wrote:
>
> > Just sharing some thoughts
>
> > Would the MenuItem class need to implement HasClickHandler so that
> > when a MenuItem is clicked, the action can be handled in the
> > presenter. At this time, the MenuItem needs an object that implements
> > the Command interface, so the view seems to know about the presenter.
>
> > I would like to know what others think about this.
>
> > -mic.
--
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.
Re: Menu Item and MVP
On Apr 1, 1:15 am, Nathan Wells wrote:
> Thomas,
>
> I've heard of your approach before, but I'm not clear on the
> implementation... are you passing the presenter itself into the view?
> or are you passing instances of event handlers? The difference seems
> trivial, but in practice (as I imagine it, anyway) seems large:
>
> http://etherpad.com/sIAaiCfuiG
>
> Let me know what you think. I would assume the first way is what your
> referring to in your comment above, which implies that it is a View
> layer responsibility to deal with HandlerRegistrations and the like.
> Is that correct?
Yes. It makes a few things much easier for me:
- I can use @UiHandler in the view, which makes the whole thing more
readable (on the down-side, I used to create a class that implement
all required handlers instead of using an anonymous class per handler;
UiBinder doesn't do this optimization (yet?) with @UiHandlers)
- I can use event delegation in the view
- The view methods are more "consistent" (get/setUserName and
setUserNameEnabled(boolean), vs. getUserName->get/setText and
setUserNameEnabled(boolean); this elad people to ask for a HasEnable
interface, which wouldn't solve anything as you'd still need
getUserName->HasText and getUserNameEnablable->HasEnable), even more
when also dealing with non-widget UI elements: I implemented a login
form with a in the HTML page which action="" is set to callback
a GWT method ($wnd.__form_callback = $entry(vi...@onsubmit())) and
had to create a dummy HasClickHandlers to return as the
"HasClickHandlers submitButton()"; with a Listener is way easier: the
onSubmit just calls back the listener.submit().
- I have one "screen" where the user can add files to upload, each
"file" is a line composed of a FileUpload and a "cancel" button next
to it that removes the "line" from the screen (and therefore "cancels
the file" before the form is submitted), already uploaded files
(unpredictable number) are shown as a label with a "delete" button
next to it. Add to this that files are grouped into dynamic,
unpredictable "groups". Previously, I did everything with a
SelectionEvent where the value was something like "add:", "cancel:", or "delete:" (I use event
delegation in the view). Now, instead of firing a SelectionEvent with
a specific value, I just call the listener's addFile(String group),
cancelFile(String fileId) or deleteFile(String fileId).
Sure I could have defined new events instead of doing it all through a
SelectionEvent but it wouldn't have make things much easier, with more
files to maintain.
As for the implementation, I currently have something like:
public class FooPresenter {
@ImplementedBy(FooView.class)
public interface Display {
void setListener(Listener listener);
void setThisVisible(boolean visible);
void setThatEnabled(boolean enabled);
}
public interface Listener {
void save();
void close();
}
private class Handlers implements PlaceHandler,
SomeOtherBusEventHandler, Listener {
...
}
@Inject
public FooPresenter(Display view, EventBus bus) {
Handlers handlers = new Handlers();
bus.addHandler(PlaceEvent.getType(), handlers);
bus.addHandler(SomeOtherBusEvent.getType(), handlers);
view.setListener(handlers);
}
...
}
public class FooView implements FooPresenter.Display {
@UiField Button save;
@UiField Button close;
private FooPresenter.Listener listener;
...
public void setListener(FooPresenter.Listener listener) {
assert listener != null;
this.listener = listener;
}
@UiHandler("close")
void onCloseClick(ClickEvent event) {
listener.close();
}
@UiHandler("save")
void onSaveClick(ClickEvent event) {
listener.save();
}
}
I'm using a Listener *interface* so the view doesn't have direct
dependencies on the presenter's behavior (I could therefore mock a
Listener and make a small app to "manually test" my view without
actually having any presenter, event bus, etc.)
I decided to switch to this design instead of HasXxxHandlers when I
saw Ray's work on RequestFactory: """In the Wave style: the view
(editor) has a single listener for its semantic operations."""
The main difference is that I do not have an interface for each
presenter with its impl class (interface FooPresenter / class
FooPresenterImpl implements FooPresenter, FooPresenter.Listener) so my
presenter class doesn't itself implement the listener interface (it
would also "pollute" its public API, which is not a problem in Ray's
case where no other object has a direct dependency on the Impl class,
only on the presenter interface).
In a new project we're starting, I might reconsider this approach
though, and introduce an interface vs. impl class dichotomy all over
the place.
Something to be aware of though: the Listener approach puts a bit more
responsibility into the view than the HasXxxHandlers approach, but
it's so much easier to work with (and write unit tests) that's I think
it's worth it.
--
You re
Re: Menu Item and MVP
That first button should say "Save" - It's late here :-) -- 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.
Re: Menu Item and MVP
I've been looking into this for a chapter in the new edition of GWT In
Action, here's where I'm at.
The Google I/O approach to MVP has never sat well with me because, apart
from the fact that the interface can get out of hand, it just seems wrong
that the interface specifies that the view must, say, have something
clickable and not leave the implementation to the view.
So what I'm playing about with right now is (for the example you gave).
There would be a couple of interfaces HasClose and HasSave which would be
along the lines of
public interface HasSave
{
void save();
}
There would be a couple of corresponding CloseHandler and SaveHandler
classes e.g.
class SaveHandler implements ClickHandler
{
private HasSave presenter;
public SaveHandler(HasSave presenter)
{
this.presenter = presenter;
}
@Override
public void onClick(ClickEvent event)
{
presenter.save();
}
}
The presenter looks like this
class Presenter implements HasSave, HasClose
{
View view;
public Presenter(View view)
{
this.view = view;
}
@Override
public void save()
{
view.setText("Save");
}
@Override
public void close()
{
view.setText("Close");
}
}
and the view like this
class View extends FlowPanel implements HasText
{
Label label = new Label();
public View()
{
Presenter presenter = new Presenter(this);
add(new Button("Open", new SaveHandler(presenter)));
add(new Button("Close", new CloseHandler(presenter)));
add(label);
}
@Override
public String getText()
{
return label.getText();
}
@Override
public void setText(String text)
{
label.setText(text);
}
}
in the AppController or onModuleLoad method, you'd just have the line
RootPanel.get().add(new View());
Does that make sense? Feel free to ask but I'm still not too far forward
with this approach yet.
For a tiny project, it's a bit of work (unless you have already written the
interfaces and handler classes for some other project) but it does keep
everything well organised in larger projects.
Ian
http://examples.roughian.com
On 1 April 2010 00:15, Nathan Wells wrote:
> Thomas,
>
> I've heard of your approach before, but I'm not clear on the
> implementation... are you passing the presenter itself into the view?
> or are you passing instances of event handlers? The difference seems
> trivial, but in practice (as I imagine it, anyway) seems large:
>
> http://etherpad.com/sIAaiCfuiG
>
> Let me know what you think. I would assume the first way is what your
> referring to in your comment above, which implies that it is a View
> layer responsibility to deal with HandlerRegistrations and the like.
> Is that correct?
>
> On Mar 31, 8:14 am, Thomas Broyer wrote:
> > On Mar 31, 8:07 am, mic wrote:
> >
> > > Just sharing some thoughts
> >
> > > Would the MenuItem class need to implement HasClickHandler so that
> > > when a MenuItem is clicked, the action can be handled in the
> > > presenter. At this time, the MenuItem needs an object that implements
> > > the Command interface, so the view seems to know about the presenter.
> >
> > > I would like to know what others think about this.
> >
> > I've recently migrated from views with many HasXxxHandlers getters to
> > views with a setListener method that the presenter "injects" into its
> > view. The listener defines "callback methods" such as save(), close(),
> > italicize(), bold(), delete(), etc.
> > It makes unit tests waaay easier to write (you don't have to mock each
> > HasXxxHandlers, capturing each added XxxHandler, eventually mocking
> > the XxxEvent, etc.) and in your case would make things easier: the
> > Command is an implementation detail of the view.
>
> --
> 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.
>
>
--
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.
Re: Menu Item and MVP
Thomas, I've heard of your approach before, but I'm not clear on the implementation... are you passing the presenter itself into the view? or are you passing instances of event handlers? The difference seems trivial, but in practice (as I imagine it, anyway) seems large: http://etherpad.com/sIAaiCfuiG Let me know what you think. I would assume the first way is what your referring to in your comment above, which implies that it is a View layer responsibility to deal with HandlerRegistrations and the like. Is that correct? On Mar 31, 8:14 am, Thomas Broyer wrote: > On Mar 31, 8:07 am, mic wrote: > > > Just sharing some thoughts > > > Would the MenuItem class need to implement HasClickHandler so that > > when a MenuItem is clicked, the action can be handled in the > > presenter. At this time, the MenuItem needs an object that implements > > the Command interface, so the view seems to know about the presenter. > > > I would like to know what others think about this. > > I've recently migrated from views with many HasXxxHandlers getters to > views with a setListener method that the presenter "injects" into its > view. The listener defines "callback methods" such as save(), close(), > italicize(), bold(), delete(), etc. > It makes unit tests waaay easier to write (you don't have to mock each > HasXxxHandlers, capturing each added XxxHandler, eventually mocking > the XxxEvent, etc.) and in your case would make things easier: the > Command is an implementation detail of the view. -- 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.
Re: Menu Item and MVP
On Mar 31, 8:07 am, mic wrote: > Just sharing some thoughts > > Would the MenuItem class need to implement HasClickHandler so that > when a MenuItem is clicked, the action can be handled in the > presenter. At this time, the MenuItem needs an object that implements > the Command interface, so the view seems to know about the presenter. > > I would like to know what others think about this. I've recently migrated from views with many HasXxxHandlers getters to views with a setListener method that the presenter "injects" into its view. The listener defines "callback methods" such as save(), close(), italicize(), bold(), delete(), etc. It makes unit tests waaay easier to write (you don't have to mock each HasXxxHandlers, capturing each added XxxHandler, eventually mocking the XxxEvent, etc.) and in your case would make things easier: the Command is an implementation detail of the view. -- 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.
Re: Menu Item and MVP
I created an "EventFiringCommand" class for instances like this. Basically, you put the event bus and the event to fire (or the code to generate the event) in the command. The Command should be a presenter- layer object, since it has no need to know about the view (and should be easy to unit test). Theoretically, you could just make inner classes in a Presenter for each Command you write. It all depends on how you want to organize your code and the needs of your specific project. On Mar 31, 12:07 am, mic wrote: > Just sharing some thoughts > > Would the MenuItem class need to implement HasClickHandler so that > when a MenuItem is clicked, the action can be handled in the > presenter. At this time, the MenuItem needs an object that implements > the Command interface, so the view seems to know about the presenter. > > I would like to know what others think about this. > > - mic. -- 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.
Menu Item and MVP
Just sharing some thoughts Would the MenuItem class need to implement HasClickHandler so that when a MenuItem is clicked, the action can be handled in the presenter. At this time, the MenuItem needs an object that implements the Command interface, so the view seems to know about the presenter. I would like to know what others think about this. - mic. -- 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.
