For quite some time the back button has been painful to deal with, not only for IntraWeb applications but for all types of web applications built with different technologies. Even simple pages that contain, for instance, a payment form may cause problems. Not coincidentally we usually see messages like “do not leave this page until the process completes” and such.
A simple search on Stackoverflow.com for “back button” shows almost 58K results. Some of them are not web-related but a quick look reveals that the majority of them are in fact JavaScript/web programming related questions such as “How to Detect Browser Back Button event” or “How do I disable browser’s back button”.
Navigating a web application through back and forward buttons usually creates several problems: It allows the user to go back to a previous page and repost the same request (or the same request with modified parameters) again, which requires that the server has special logic to detect and handle this situation. It also makes it harder for developers to create a consistent user experience within a web site or application. For instance, what happens – or what should happen – in a Single Page Application (SPA) when the user hits the back button?
More specifically in IntraWeb, users in general create Single Page Applications and disable the back button completely using an IntraWeb built-in feature (although WebKit based-browsers – Chrome, Edge and others require the user to explicitly interact with the web page first).
Sometimes, however, that’s not the best approach for specific web applications. Users often require a more “natural” navigational behavior that supports the back and forward buttons and also includes the capacity to bookmark specific pages/URLs. With this in mind we have continually improved the way IntraWeb handles the back and forward buttons. Recent IntraWeb versions (from 15.2.60 and up) transparently integrate the logic required to deal with these events to a point that most applications could start supporting this feature with minimal code changes.
In order to support the back button (i.e. disable any code that interferes with the standard back button action) users should set a ServerController property named BackButtonOptions.Mode to bmEnable. It means that the back/forward buttons will be fully enabled and IntraWeb will not generate any code to disable them. The default value of this property is bmDisableCompat. Although bmDisableCompat is not the recommended setting in any case, we decided to keep it this way because this makes the application behavior compatible with previous IntraWeb versions 12 and 14.
After releasing IW 15.2.60 we created a new simple demo application that shows several features working together to allow users to create applications that behave like normal web sites and correctly respond to back and forward buttons navigation.
The demo can be found in our Github repository here: https://github.com/Atozed/IntraWeb/tree/master/15/Delphi/MultiPageApp
This demo shows several IntraWeb features that work nicely together, more specifically, how to make extensive use of content handles. This application is not a typical SPA (where the application has a single URL). On the contrary this is a multi-page application, where each form (or page) has its own URL. This is achieved using the form’s SetURL() method, like here, in the initialization section of the main form unit:
The SetURL() method call here internally creates a TContentForm instance and assigns it to the TIWForm1 class, using ‘MainForm’ as the address (or URL) of that form. Doing that will allow the application to respond to a request to http(s)://yourdomain.com/MainForm URL. When this happens, the TContentForm registered for this URL will automatically create a new TIWForm1 instance, show and render it, making it the session’s active form. Have in mind that this is all done with zero user code required.
It is worth noting that there is no functional difference between calling SetURL() and creating/registering the content handler explicitly. The only difference is that, when creating it explicitly, you can also set other properties of the content handler (e.g. CanStartSession), which can’t be done when calling SetURL() directly.
The other two lines also show other interesting IntraWeb features – still unknown to some users – that allow the application to automatically respond to different requests.
The first one THandlers.AddStartHandler(), creates a new content handler for this form and sets it as the application’s Start handler, i.e. every new request that doesn’t have an associated session will be redirected to this handler. In practice, it means that every new request that creates a new session will be redirected to the MainForm, regardless of the URL. This feature is ideal to be used in applications that require a login, for instance.
The second, THandlers.AddRootHandler(), also creates a content handler for TIWForm1 and sets it as the application’s Root handler. The root handler is supposed to handle all incoming requests targeted to your application root URL (i.e. http(s)://yourdomain.com). It means that whenever the users type http(s)://yourdomain.com they will be automatically redirected to http(s)://yourdomain.com/MainForm and the MainForm will be created/shown/rendered as needed.
Finally, the other feature used in this demo is the internal navigation using URLs, which does not involve the usual sequence of creating/showing a new TIWForm instance:
Here, both events (the first one is sync and the second, Async) trigger the same action: They both call WebApplication’s method GoToURL(), passing the address of some other form (TIWForm2). If you inspect TIWForm2 code you will also see that it is registered via SetURL() method, just like the main form, but using a different address, of course:
It’s also worth noting that the form life-cycle (creation/destruction) of TIWForm instances is transparently handled by IntraWeb.
I recommend the IntraWeb user to download, build and run this demo application and get familiar with the concepts and features used there. While doing it, please (ab)use the back and forward buttons and see how well the application behaves.