Resizing display regions in a complex ui

[Anders]

Hi,

Reading Thomas Broyer's post 'GWT 2.1 Activities – nesting?
YAGNI!' (check it out here http://tbroyer.posterous.com/archive/9/2010)
really cleared things up with regards on how to handle more complex ui
designs. Abandoning the concept of nesting and going for a couple of
activity mappers to show/hide display regions as needed. But, after
some experimentation on my own I was left with one question that I
couldn't find a good answer to.

In the post Broyer mentions briefly that the display regions in the
layout needs resizing to fill the empty spaces and says the following:
'Now, here's how you could do it without nesting, just showing hiding
display regions when needed (and resizing the others to always fill
the same dimensions)'.

My question is therefore where in the code you do the actual resizing
of the display regions? If I understood the post correct the views
themselves should not have any explicit knowledge of sizing, but
rather just adapt to the size of the display region.

[Thomas Broyer]

On Tuesday, July 12, 2011 11:52:27 AM UTC+2, Anders wrote:

Hi,

Reading Thomas Broyer's post 'GWT 2.1 Activities – nesting?
YAGNI!' (check it out here http://tbroyer.posterous.com/archive/9/2010)

Direct link: http://tbroyer.posterous.com/gwt-21-activities-nesting-yagni

 

really cleared things up with regards on how to handle more complex ui
designs. Abandoning the concept of nesting and going for a couple of
activity mappers to show/hide display regions as needed. But, after
some experimentation on my own I was left with one question that I
couldn't find a good answer to.

In the post Broyer mentions briefly that the display regions in the
layout needs resizing to fill the empty spaces and says the following:
'Now, here's how you could do it without nesting, just showing hiding
display regions when needed (and resizing the others to always fill
the same dimensions)'.

My question is therefore where in the code you do the actual resizing
of the display regions?

It really depends how you're building your layout. If using <div>s and FlowPanel/SimplePanels and the like with CSS, and using "fluid layout", you don't have to do anything. Same if you're using a DockLayoutPanel (I keep talking about "LayoutPanel" in the post, but was actually thinking about DockLayoutPanel).

If using anything else that requires "manual resizing", you'll have to do it in your "layout view", and it can quickly get complicated (as soon as you have 2 regions that can be hidden/resized independently of each other, computing the size of the other regions becomes non-trivial). Using the same approach as DockLayoutPanel's internals is best IMO: use Scheduler#scheduleFinally to schedule a "relayout" whenever a region changes, and in the "relayout" code, you know nothing else will change so you can safely compute the sizes of the visible regions. DockLayoutPanel makes it really much easier if you can use it.

If I understood the post correct the views
themselves should not have any explicit knowledge of sizing, but
rather just adapt to the size of the display region.

Yes (note, though, that the "should" here is my own opinion, YMMV)

[Anders]

Thanks for the quick reply! Sounds like the DockPanelLayout is the way
to go. In my little proof-of-concept app I got lost in what you
described as the 'non-trivial size computation' using just a
LayoutPanel with manual resizing. Hence the question here!

Keep up the good work with your blog!

On Jul 12, 3:14 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> On Tuesday, July 12, 2011 11:52:27 AM UTC+2, Anders wrote:
>
> > Hi,
>
> > Reading Thomas Broyer's post 'GWT 2.1 Activities – nesting?

> > YAGNI!' (check it out herehttp://tbroyer.posterous.com/archive/9/2010)

[Mauro Bertapelle]

you may find this thread interesting:
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/ba4b88d2d54b0cd/97157d8e649c716e

[Anders]

Thanks! Looking at your code example cleared up the sizing issues.
Dunno if it's the best implementation but I ended up making an app
controller class that handles the application layout, and is used to
hook up the different mappers in the entry point class:

public class AppControllerImpl implements AppController {

private static class LayoutHandler implements
PlaceChangeEvent.Handler {

private AppController app;

public LayoutHandler(AppController app) {
this.app = app;
}

@Override
public void onPlaceChange(PlaceChangeEvent event) {
Place place = event.getNewPlace();

if (place instanceof HomeScreenPlace) {
app.setHomeScreentLayout();
} else if (place instanceof DetailsPlace){
...
} else if (place instanceof SettingsPlace) {
...
} else {
app.setHomeScreenLayout();
}
}
}

private DockLayoutPanel container = new DockLayoutPanel(Unit.PCT);
private SimplePanel header = new SimplePanel();
private SimplePanel side = new SimplePanel();
private SimplePanel main = new SimplePanel();
private SimplePanel footer = new SimplePanel();

public AppControllerImpl(EventBus eventBus) {

container.addNorth(header, 25);
container.addWest(side, 25);
container.addSouth(footer, 25);
container.add(main);

eventBus.addHandler(PlaceChangeEvent.TYPE, new LayoutHandler(this));

}


@Override
public DockLayoutPanel getAppContainer() {
return container;
}

@Override
public AcceptsOneWidget getHeaderDisplay() {
return new AcceptsOneWidget() {
@Override
public void setWidget(IsWidget activityWidget) {
Widget widget = Widget.asWidgetOrNull(activityWidget);
header.setVisible((widget != null));
header.setWidget(widget);
}
};
}

...

@Override
public void setHomeScreenLayout() {
container.setWidgetSize(header, 25);
container.setWidgetSize(footer, 0);
container.setWidgetSize(side, 25);
}

...

}


The app controller is used as follows in the entry point:

public void onModuleLoad() {

ClientFactory factory = GWT.create(ClientFactory.class);
EventBus eventBus = factory.getEventBus();
PlaceController placeController = factory.getPlaceController();
AppController appController = factory.getAppController();

// Start ActivityManager for all display regions with the
ActivityMapper
HeaderActivityMapper headerMapper = new
HeaderActivityMapper(factory);
ActivityManager headerManager = new
ActivityManager(headerMapper, eventBus);

headerManager.setDisplay(appController.getHeaderDisplay());

...

// Start PlaceHistoryHandler with the
PlaceHistoryMapper
AppPlaceHistoryMapper historyMapper=
GWT.create(AppPlaceHistoryMapper.class);
PlaceHistoryHandler historyHandler = new
PlaceHistoryHandler(historyMapper);
historyHandler.register(placeController, eventBus,
defaultPlace);


RootLayoutPanel.get().add(appController.getAppContainer());
historyHandler.handleCurrentHistory();

}


On Jul 12, 4:33 pm, Mauro Bertapelle <mauro.bertape...@gmail.com>
wrote:
> you may find this thread interesting:http://groups.google.com/group/google-web-toolkit/browse_thread/threa...