Your colleagues will have to tear themselves away from their old ideas which are based around "web pages".
I cannot share the stuff we use - it's a proprietary commercial application.
But I will say that it has been designed so that the server and client side both have analogues of each other's state.
Each "page" (to use old terminology) is in fact now a Component. The Java side has the concept of a Component which can have commands performed upon it with parameters passed.
The UI is one page, which once served stays there. When a menu option is selected, a request is sent to the server for Component X, say "Country Maintenance". So it requests say http://localhost:8080/aspicio/AspComponent/Country passing params callback=PanelLoadCallback2384
The script passes the created ComponentPanel to a callback function specified by the loading script, and that integrates the Panel into the Viewport - the last statement is
When a command must be invoked on that Component, a request is sent back to the same URL which loaded the component:
So when I click "Update" when I've changed a country field, it submits to
The command is in bold. The java Component is written to have a certain set of commands invoked upon it. It processes the params, and returns a status object which is receieved and processed by the ComponentPanel back in the browser.