Hi Paul,
We discussed this via IM but for the benefit of other readers I'll
summarize it here... The samples in the gwt-platform are relatively
simple and meant more as a showcase of the different features than as
full applications. On the other hand my (main) side-project,
PuzzleBazar (http://cod
I have totally restructured my app to follow the "page setup by event"
type idea that you've suggested in your email. I have been through all
four samples in the samples repo but can't answer my own question.
I have set up based on the "nested sample" but now I have a
HeaderPresenter like you have
Thanks so much for this answer. I have printed it and pinned it up
right beside my screen so will be referring to it often until these
concepts become solid in my mind. I think the largest mind gap here
for me is the concept that a presenter's view is used to fill the
whole screen, and then it has
I answer to this earlier, but it somehow got gobbled by Google Groups.
If you see it around, let me know. ;)
Re: Complex widgets and PresenterWidgets
You're exactly right. PresenterWidgets are GWTP's way of doing a
complex widget with a nice testable class. Your PresenterWidget has
all the widget
Ok, I didn't implement it this way, but would prefer to.
At the moment I have 3 mother-sized presenters + views. These have
EventBus injected into them by gwt-platform. Then the widgets that are
"owned" by this view are then constructed manually. I think I can
still test them atomically but I'm no
Yeah, the one problem with UiBinder and MVP is this pattern collision
UiBinder says, "view are directly attached to views".
MVP says, "view's are attached to presenters, if you want to chain views the
presenters control this".
Consequently, you can't get UiBinder to create your @UiFields (i.
In gwt-platform (http://code.google.com/p/gwt-platform/) we use gin to
inject the EventBus to whoever needs it. The framework is designed
such that only the presenters communicate on it.
In your example, the gwt-platform way would be to create a
PresenterWidget for WidgetA and another for WidgetB.
I looked into that, and (unless I'm wrong), I think that
@UiField(provided=true) will cause the UiBinder to look in the .ui.xml
file for argument to satisfy Foo. In my case I am trying to "inject"
an EventBus into the widget, not a visual element.
On Jun 24, 2:18 am, Filipe Sousa wrote:
> I belie
I believe you can use @UiField(provided=true):
@UiField(provided=true) Foo foo
@Inject
UserDashboard(Foo foo) {
this.foo = foo
}
On Jun 23, 10:03 pm, Paul Schwarz wrote:
> To answer my own question:
>
> 1. Gin can be used to inject the EventBus into the View as well as the
> Presenter, so n
To answer my own question:
1. Gin can be used to inject the EventBus into the View as well as the
Presenter, so now our View has a reference to the EventBus
2. In order to give the EventBus to the Widgets "owned" by the View
those Widgets will require a constructor argument which will be the
Even
Working with the MVP pattern, or more like the VP pattern at this
point, I have:
MainPagePresenter
MainPageView
WidgetA
WidgetB
... so imagine that WidgetA and WidgetB will be attached to
MainPageView.
Using Gin I have an EventBus injected into the MainPagePresenter. I
can then add click handlers
11 matches
Mail list logo
