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 <ianbamb...@gmail.com> 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 <nwwe...@gmail.com> 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 <t.bro...@gmail.com> wrote:
> > > On Mar 31, 8:07 am, mic <mina...@gmail.com> 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<google-web-toolkit%2bunsubscr...@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.
