Vaadin 7 UI navigator field

Vaadin 6 / 7 / 8
1

In the documentation at https://vaadin.com/book/vaadin7/-/page/advanced.navigator.html there’s some sample code for adding a navigator with some views to a UI subclass.

When I added a navigator field to my own UI subclass and wanted to expose it through a protected getNavigator() method (for unit testing) I discovered that UI already has a getNavigator() method. It turns out that just instantiating a Navigator with a certain UI will already set the navigator field on the UI, which can be retrieved using UI.getNavigator(). So, it seems to me there’s no need to add an additional navigator field in the UI subclass, as is shown in the example.

Or is there any reason that we can’t depend on the existence of this field in the future?

2

I think that either the example is not totally up to date - UI.getNavigator() was somewhat a last-minute addition - or it may be simply for convenience’s sake, saving a few letters on each access.

3

I’m just starting to get into Navigator, but what I’m now concerned about is this: if I have nested navigation (e.g. an outer navigator that controls view changes by a top level menu, and a navigator for a submenu inside a view), then instantiating the Navigator for the submenu will overwrite UI.navigator, which should be the outer navigator. In this case it may be better to keep the outer navigator in a separate field in the UI subclass (and not use UI.getNavigator() at all).

4

Yes, unfortunately hierarchical navigation is not very well supported today (see
ticket #9800
). The idea is that there should be only one Navigator per UI, and nested navigation should be done some other way (for example using a custom ViewDisplay and ViewProviders) - it’s, however, not as clean as we would like.