Layout Handling with gwt-presenter-replace ?
Michael Weisser
today I had a closer look at your puzzlebazar application. I looked
at the mentioned revision r3 (Refactored GreetMvp) and your current
trunk version... And I also browsed around at the TeamScape
application found under http://borglin.net/gwt-project
Puuuhhhh... Now first I need to sort out my thoughts....
But I am still unsure of what is the best approuch to implement the
application layout (e.g. TopPanel, StatusPanel, Navigation-Tree,
Center Content-Panel, etc.) and the place where and how to update the
different panels.
As far as I understood the (gwt-presenter-replace)
"BasicPresenter.revealDisplay" (or onRevealDisplay()) is a place where
you can control this. A simple but non-practical solution could be to
get always the Root-Panel, remove all components there and add the
presenter.getDisplay().asWidet on it.
In your trunk version I see that you define new Events like
NewMainContentEvent, NewCenterContentEvent that get fired in your
revealDisplay() method and then get handled by AppPresenter and
SplitMainPresenter.
Are you happy with this solution of firing those events?
Maybe a stupid question but instead of using the Event-System could it
also be a feasable way to inject an ApplicationLayout class in your
Presenter Implementations? The ApplicationLayout class could provide
methods like "setCenterContent", "setMainContent", ... that could be
used within Presenter.revealDisplay() directly...
It is just an idea because even with firing new LayoutEvents the
Presenter itself must know which parts / panels of the application he
wants to update, or?
- Or do i miss something?
- Or what other benefits does the event mechanism provide?
So the whole topic is not that easy and in the TeamScape example
Andreas Borglin used a completely different approuch of handling
layouts... His Presenters can contain a "WidgetProperties" object
that contain layout information like NORTH-Position, CENTER-Position,
etc. and his BaseClass is listening on the "PresenterRevealedEvent"
which invoke a special "showWidget" method that know how to handle the
WidgetProperties information.
So at the moment I am still confused...
Thanks and Kind Regards
Michael
PhilBeaudoin
> But I am still unsure of what is the best approuch to implement the
> application layout (e.g. TopPanel, StatusPanel, Navigation-Tree,
> Center Content-Panel, etc.) and the place where and how to update the
> different panels.
>
> As far as I understood the (gwt-presenter-replace)
> "BasicPresenter.revealDisplay" (or onRevealDisplay()) is a place where
> you can control this. A simple but non-practical solution could be to
> get always the Root-Panel, remove all components there and add the
> presenter.getDisplay().asWidet on it.
The way I do this is that every presenter has a number of "holes" in
which it can display other presenters on request. Each of these holes
is associated with a specific message on the event bus. These messages
contains the (child) presenter that wants to be displayed. When the
presenter receives one of these messages it removes the content from
the "hole" and adds the child presenter. In this way a loosely-coupled
hierarchy of presenters can easily be created: events will ripple up
the hierarchy making sure every presenter is inserted in a "hole"
within its parent presenter.
The top-level presenter (AppPresenter) is always visible, and so I
never have to access the root panel directly.
> In your trunk version I see that you define new Events like
> NewMainContentEvent, NewCenterContentEvent that get fired in your
> revealDisplay() method and then get handled by AppPresenter and
> SplitMainPresenter.
>
> Are you happy with this solution of firing those events?
These are essentially the events I describe above. Up until now, this
as worked very well for me.
> Maybe a stupid question but instead of using the Event-System could it
> also be a feasable way to inject an ApplicationLayout class in your
> Presenter Implementations? The ApplicationLayout class could provide
> methods like "setCenterContent", "setMainContent", ... that could be
> used within Presenter.revealDisplay() directly...
I considered doing something like this. Namely, injecting parent
presenters within child presenters and using method-calling instead of
events. This probably would have worked, but the resulting design was
more strongly coupled and I like the event passing better.
One thing that did not work for me, however, is the initial gwt-
presenter design, where container-presenters have a list of their
child presenter. Not only is this a strongly coupled design, but its
coupled in the wrong direction for my needs. Specifically, I need to
be able to use Code Splitting on child presenters, but injecting them
in this way means that all presenters have to been instantiated before
the AppPresenter can be.
> It is just an idea because even with firing new LayoutEvents the
> Presenter itself must know which parts / panels of the application he
> wants to update, or?
>
> - Or do i miss something?
> - Or what other benefits does the event mechanism provide?
As I said, the parent presenter knows its "holes" but doesn't know
what goes there. The event mechanism makes it easy to change which
hole a child presenter, or even at which level of the presenter
hierarchy it is. The only thing you need to change is the event the
child presenter fires.
> So the whole topic is not that easy and in the TeamScape example
> Andreas Borglin used a completely different approuch of handling
> layouts... His Presenters can contain a "WidgetProperties" object
> that contain layout information like NORTH-Position, CENTER-Position,
> etc. and his BaseClass is listening on the "PresenterRevealedEvent"
> which invoke a special "showWidget" method that know how to handle the
> WidgetProperties information.
I didn't look at the TeamScape example too much, so I can't really
comment on this.
PhilBeaudoin
I have made a major revision to the way presenter and sub-presenter
work. In the new version (r43), Presenter that can contain sub-
presenters declare a number of Slot classes. A Slot has a method to
set its content, that is, which presenter should be displayed in it.
Slots are injected directly in sub-presenters. When the subpresenter
is revealed, it simply adds itself to its parent Slot: no more message
passing.
I also found a problem with PresenterPlace#onBind. In the previous
version, there was a single type of PresenterRevealed event. Each
PresenterPlace intercepted it and compared the event's presenter to
its own by calling myPresenter.get(). The problem is that calling
myPresenter.get() instanciates the Presenter. In practice, it means
that sending a single PresenterRevealed event instantiates all the
presenters of the application! This is not acceptable for my
situation, since some of my presenters are quite heavy (moreover, I
want to code split them).
My solution was to build a light-weight structure around each
presenter, which I call a PresenterWrapper. It's a bit tricky and I'm
not 100% satisfied with the solution. I'm thinking of combining
PresenterWrapper and Place somehow, possibly dropping message passing
altogether between Presenter's and Places, and relying on method calls
instead. If you have any comment on this, I would love to hear them.