hi,
based on my blog post from last week, i thought a little about if it is possible to add HTML5 History API support for CUBA.
A few entry points i came across are:
A discussion about it would be great.
Bye,
Mario
Hi Mario,
Thank you for the good question and for your blog posts. You are absolutely right - the standard CUBA UI is the end of the web - it is much more like a desktop application from the user experience point of view.
To be honest, we didn’t pay much attention to the browser history functionality which is essential for web applications. The only thing that works now in this context is the ability to react on Back button: see the cuba.web.allowHandleBrowserHistoryBack application property. Of course, it is far from the full history support.
We are aware of the support of browser history by Vaadin, and it seems quite feasible to implement URL rewriting for CUBA applications. We can provide some API to react to the fragment change to be able to handle it on the application level.
Most probably, this functionality will allow a developer to encode links to the screens as URL fragments. So when a user enters a URL with a fragment to the browser, the application will show the login window, and then pass the control to a fragment handler. The developer is responsible for writing code to restore the application state depending on the fragment.
Roughly speaking, the URL fragments can be a better alternative to the current external links to screens. Plus the browser history will work automatically.
What do you think?
Hi Konstantin,
when do you talk about “fragment”, do you mean everything after “#” in the URL? History API also allows the whole URL to change, not just the shebang (but i’m not sure what Vaadin is allowing us to do here.
Generally i think it’s a good idea to be able to get an API for stuff like this. This is useful for scenarios when you have a UI that creates dialogs when clicking on a button and you want to reflect this dialog opening state in the URL. But i think this might only be the last 20% of the cases.
The first 80% of the uses cases are a little bit “easier” to achieve. Mostly a URL change relates to a screen that opens. So we could say, when opening a list of customers via the main menu the URL could change from "/#’ to “/#customers” or “/#om$Customer-customer-browse” or whatever have you. When changing to the editor of a customer something like “/#customers/UUID” could occur.
I would argue that this general pattern is so generic, that it would not be necessary to let the developer do this on their own (through the new API from above), but it could be backed into CUBA.
There are a few things that are a bit problematic i think. One of it is the multi tab situation. The approach from above can only work for the current active tab. This means, changing the tabs will change the URL. The back button in this case will re-activate the old tab (which would be compatible with the single tab approach the user can choose as well). But what if i want to open the editor of an customer via a dialog? Should that be reflected in a URL change as well? I’m not really sure about the different situations here.
From this perspective the deep link possibility that CUBA currently has, is not that bad i would say, because the situation that you described there:
“The developer is responsible for writing code to restore the application state depending on the fragment.” isn’t really needed in the current implementation (except for the 20% cases i described above).
But generally it’s good to hear that it is not that big of a deal to get that feature going…
Bye,
Mario
Yes, by fragment I mean the part after #. As I understand, only this part of the URL can be changed without the whole page reload, which is essential for CUBA app.
I understand your point that the fragments should be created automatically on the basis of screen parameters. This could work for standard screen flow like “browser -> editor”. However, sometimes the set of parameters is simply too big or can be hard to encode. Or imagine that you open a lookup screen from an editor field. What point is to remember such screen in the history?
As you mentioned, there are many questions around the generic history functionality. That’s why in the previous post I mentioned only the possibility to handle the history programmatically. But of course, when we start implementing the feature, we will consider all possibilities for generic behaviour, with minimum coding.
See the following issue in our bug tracker: