How to open multiple views of the same application
The main parts of the underlaying technology are a web browser on the client side and a servlet container on the server side. Servlets can maintain state across many server transactions by using HTTP cookies, session variables or URL rewriting. ThinWire uses the standard servlet cookie JSESSIONID to separate different connections. So the behaviour depends on your operationg system and the used browser.
Most browsers (if not all) share the same JSESSIONID between all windows of the same instance. If you open a new tab or a new window from within your browser and start a ThinWire application with the same URL there that is already in use in another window of the browser then the browser will reuse the old JSESSIONID and ThinWire will be confused and everything will end up with an hanging application or an error.
On windows it should be possible to work around by starting a new browser from the start menu or the command line.
In the combination Debian (maybe on other Linux distributions too) and Iceweasel (=Firefox) also this workaround failed and it was necessary to switch between different logon users via the Gnome (gdm) logoff/change user feature.
If you are not afraid of changing the source (and preparing the web.xml) there is a possible way in this forum thread.
return to top
How to push information from server to client / update the UI from another thread?
You have to use a timer task. See this forum thread.
return to top
Is it possible to have editors in cells on the GridBox component?
The short answer is: not yet, but planned for in v1.3.
The long answer is: you can mimic similar behavior by using the Grid interface capabilities of TableLayout.
return to top
How do you listen for the shutdown of an application instance / session?
Although there are technical reasons nothing yet that lets you customize what the shutdown message looks like or anything that would let you detect the user closing the browser, but you can write code to be notified whenever a users session is terminated as a result of a timeout or as a result of the frame's visibility being set to false elsewhere in the application. See the following forum thread for details.
return to top
Is it possible to detect the browser window closing?
No, but you can SIMULATE a similar effect as follows:
Set the session-timeout as low as possible. As far as a I know, the web.xml lets you set the timeout to a minimum of 1 minute. Some application servers may have a workaround for this, but generally 1 minute is sufficient.
Have each application instance register an application timer-task and schedule it to run at an interval that is about 1/2 of the session-timeout time. So if the session timeout is 1 minute, then set this to 30-second intervals. The body of the timer can be entirely empty, it's just important that it be registered so the browser talks to the server at regular intervals.
Add a "visible" PropertyChangeListener to the Application's Frame and place whatever shutdown code you want to execute upon browser-close in the listener's "propertyChange" method.
That's it. With those three steps you're shutdown code should be run about 1 minute after the browser window is closed. You can read/discuss this topic in this forum thread.
return to top
Can I access request parameters, http headers, web.xml init-params or remote user info?
Yes, the String[] arguments that are passed to the main method of the application include the request parameters by default, with each entry in the arguments array containing a value such as "param=value". To access http headers, remote user info, web.xml init-params or context-params, you must first add an additional init param to the application configuration in web.xml that toggles on the passing of the information you are looking for. For instance, here's a configuration that passes all information to the application:
<init-param>
<param-name>extraArguments</param-name>
<param-value>initParam,contextParam,clientInfo,header</param-value>
</init-param>
After doing this, the various items will be returned to you in the following formats:
- HTTP Headers: "HEADER_xxxx=value"
- Remote Users: "CLIENT_INFO_USER=value", "CLIENT_INFO_HOST=value", "CLIENT_INFO_ADDRESS=value"
- Additional <init-param> values: "INIT_PARAM_xxxx=value"
- All <context-param> values: "CONTEXT_PARAM_xxxx=value"
return to top
How can I access the servlet container session environment
The bad news: You cannot do directly from within ThinWire.
The good news: There are two mechanism to get around this limitation:
- Session varibles via Application.Local:
If your goal is to store per session variables you can do this comfortable via Application.Local from the ThinWire API. Have a look at this forum thread for some discussion and examples.
- Full access to HttpServletRequest:
If you need full access, do not call ThinWire directly, but call your own HttpServlet and do whatever you want there (authentification, role management, etc) and delegate afterwards to Thinwire and maybe continue your actions when it returns from the delegate call. In the forums there are some threads with basic code, additional explanation (cross context forward), and web.xml integration.
If your goal is to store per session variables you can do this comfortable via Application.Local from the ThinWire API. Have a look at this forum thread for some discussion and examples.
If you need full access, do not call ThinWire directly, but call your own HttpServlet and do whatever you want there (authentification, role management, etc) and delegate afterwards to Thinwire and maybe continue your actions when it returns from the delegate call. In the forums there are some threads with basic code, additional explanation (cross context forward), and web.xml integration.