Loading...
Important Notice - Forums is archived

To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Product icon
TUTORIAL

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.

/level1/level2/.. URLs, View Hierarchy, Navigator, UriFragmentManager CHAOS

Anton Alegol
5 years ago Mar 07, 2017 3:07am

I am struggling for second day with navigation philosophy of vaadin with the Navigator and UriFragmentManager upside-down idea. I'd expect something more like React rather than flat URI path to views relations. 

Consider following URLs and how they are represented in my scenario:
/fruit/ - view/fruit/apple - view/fruit/orange - view

/vegetable/ - view
/vegetable/tomato - view
/vegetable/potato - view

The first glance at vaadin architecture gives a human perception that there is a mechanism to deal with this. I would expect that I can create a main UI with content which has 2 buttons using navigator(navigateTo /fruit and /vegetable ), navigator itself would be created with UI level component reference where the view will be displayed. So as we've already created and used single instance of Navigator(more on that later).

Then Within the /vegetable view I also have two buttons pointing to /vegetable/tomato and /vegetable/cherry views so I created second navigator which is created again with /vegetable view level component to display subviews and created two buttons using navigator(navigateTo /vegetable/tomato and /vegetable/potato).

When I traverse with buttons clicking via browser I get perception of hierarchy:

click 'vegetable' on UI -> vegetable subview appears with 'tomato' and 'potato' buttons
click 'tomato' -> tomato subsubview appears.

While the browser address bar is changed correspondingly from:
/ to /vegetable/ to  /vegetable/tomato

So far so good, now lets bookmark /vegetable/tomato

What happens if I open bookmark? Exactly! We would expect main UI with /vegetable subview inside and /vegetable/tomato subsubview within. However what we get is the main UI which just displays /vegetable/tomato subsubview, but does not have /vegetable subview. This happens because there seems to be no notion of hierarchy so subsubview = normal view in terms of url resolution. So on /vegetable/tomato request main UI is hit and top level nagivator intended for /vegetable or /fruit views actually displays /vegetable/tomato view on the root level.

Questions:

0. All I want is for multilevel URL resolution correspond to construction of nested hierachical views. Is this possible to achieve or I am trying to do navigation not in Vaadin style? Multilevel URLs capturing states are important for bookmarking. How do you develop SPAs with multilevel URLs bookmarking?

1. Should I continue and replace the useless(IMO) UriFragmentManager with my own implementation? Along the way probably ViewResolver and Navigator as well? All of this will be needed to support nested view structure recognition when typing to address bar multilevel URL, so it would literally recreate entire view hierarchy.   

2. Vaadin site itself has flat structure, so the '/forum' address is not under '/community', yet within the menu on UI it is , when writing this post the URL is:
https://vaadin.com/forum#!/thread/new/1007558 , hashbang precedes 'thread', however in my simple example hashbang precedes the very first level, so why /forum is not preceded by #! (#!forum/thread/new/1007558)? Something else used under hood? Or /forum and /community are both standalone UIs with their own navigators? Can I disable hashbang? Only Vaadin seem to care about it.

3. Every tutorial I read implies this invisible ghost notion of a SINGLE Navigator per UI, why is this so? Why Navigator class is so stupid that the component which content is replaced with view is only set in constructor. Why it cannot have method signature navigateTo with component paremeter for view display? This implies that you cannot reuse the same instance of Navigator for different components of different view displays which is why I NEED MULTIPLE Navigators. This notion not just embedded in people minds it is also embedded in Spring Boot Vaadin Starter, guess what -> I don't use SpringNavigator because the guy is singleton and you cannot init it with desired component again, but the idea is fiercefully pushed. The SpringNavigator like normal Navigator has no means to change the component  where view is to be displayed after they've been constructed. But then again @SpringViewDisplay introduced in SpringBoot also has recommendation of being ever only single. I haven't investigated how it works but I believe it is simillar to component which we pass to standard Navigator. This philosophy of one level UI and one dynamic display area is somewhat off.
 

Anton Alegol
5 years ago Mar 07, 2017 3:32am
Peter Lehto
5 years ago Mar 08, 2017 7:21am

Hey Anton,

without considering all aspects of your question, the navigation structure of Vaadin is by default Flat. It should be considered mainly as url to view mapping.

It's not uncommon to have large applications define their view structure with dot-notation. Quite often especially in larger apps the view structure could be as follows:

settings.user
settings.user.details

inbox
inbox.write
inbox.read

customers
customers.statistics

etc.

In this case the functionality is exactly the same as with / separator, only with the difference that the reminder of the view name part is not considered as parameter. Then, what usually happens is that there is a UI that sets up the menuing structure that corresponds the level of navigable elements. For example on the "left hand side menu" it's quite common to have things which are at the bottom level of navigation. Things like settings, inbox, customers.. At the very top of the window there usually are the second level navigation items like user, write, read, statistics. Out of these only the ones are visible which belong to the currently selected main level item. Finally, if third level is present, it's sometimes visualised as a tab of the view, for example the 'details' under the user item could be a tab.

The ViewDisplay is intended to be the view holder. It's purpose is not to change every time a view is navigated into but rather it's the object that hosts the view and not necessarily even a component. In my above example the UI structure could be such that it has a top header, left main menu and then reminder of the space is used by a component implementing the view display. Whenever main menu item, top header item or tab is clicked, an event will be sent out of which all the menu elements requiring to show the currently selected view will be refreshed. Also the UriFragment handling should be event based, when it changes, an event is fired that is handled similarly.

Something like the above is quite often seen within the project foundation of any Vaadin project. The question is, should something like this be more supported out of the box by the framework. In most of the cases yes, but there are also many projects that benefit from having the mapping as simple as possible as many apps have very special requirements for navigation.

Alejandro Duarte
5 years ago Mar 09, 2017 8:56am
Hayden Dekker
4 years ago Jul 21, 2017 3:59am