mjoska,
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
What is returned is possibly some HTML, but mainly, it will be a script which creates and initializes a Javascript ComponentPanel which is the UI side container for the Component
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
Code:
PanelLoadCallback2384(contentPanel);
The important thing is that the loaded javascript is generated by logic on the server side which understands that it is not creating a "web page", but a ComponentPanel for use by an Ext.Container.
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
http://localhost:8080/aspicio/AspCom...CountryDetails.update
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.