Details
-
Type:
New Feature
-
Status:
In Progress
-
Priority:
Normal
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 3.0.1
-
Component/s: None
Issue Links
| Dependency | |||
|---|---|---|---|
|
|||
Activity
Comments in order of execution 
Servlet filter to set up DWR ThreadLocals:
Aren't you aiming to do all work in the "page" request, ie the root request loading the page? Then no extra DWR info is added to the request, so we can't set up our ThreadLocals. We can only do this for requests sent by the DWR client layer.
Reuse existing ScriptSession if exists:
As we don't have the extra DWR info (the page request doesn't transfer any scriptSessionId), we don't know if there is already a ScriptSession. On the flip side though, if you are using the default ScriptSession model, where a new ScriptSession is created for every page load, then you can be certain that no ScriptSession exists yet and can safely create a new one.
Creating a new ScriptSession:
I guess this could be done like this with the current APIs and without requiring being inside a DWR thread:
Container container = ServerContextFactory.get().getContainer();
ScriptSessionManager ssmgr = container.getBean(ScriptSessionManager.class);
String myScriptSessionId = ...
ScriptSession ss = ssmgr.getScriptSession(myScriptSessionId, page, sessionId);
Handing over the scriptSessionId to DWR engine.js in the page:
If my assumptions above are correct, this is the only part left that needs implementing. You need some way of setting the scriptSessionId before engine.js gets a chance to set up its own, is that right?
Servlet filter to set up DWR ThreadLocals:
Aren't you aiming to do all work in the "page" request, ie the root request loading the page? Then no extra DWR info is added to the request, so we can't set up our ThreadLocals. We can only do this for requests sent by the DWR client layer.
Reuse existing ScriptSession if exists:
As we don't have the extra DWR info (the page request doesn't transfer any scriptSessionId), we don't know if there is already a ScriptSession. On the flip side though, if you are using the default ScriptSession model, where a new ScriptSession is created for every page load, then you can be certain that no ScriptSession exists yet and can safely create a new one.
Creating a new ScriptSession:
I guess this could be done like this with the current APIs and without requiring being inside a DWR thread:
Container container = ServerContextFactory.get().getContainer();
ScriptSessionManager ssmgr = container.getBean(ScriptSessionManager.class);
String myScriptSessionId = ...
ScriptSession ss = ssmgr.getScriptSession(myScriptSessionId, page, sessionId);
Handing over the scriptSessionId to DWR engine.js in the page:
If my assumptions above are correct, this is the only part left that needs implementing. You need some way of setting the scriptSessionId before engine.js gets a chance to set up its own, is that right?
Here's what the tags might look like
<!-- creates a script session and calls WebContextBuilder.engageThread() -->
<dwr:script-session>
<html>
<head>
<!-- sets dwr.engine._scriptSessionId and includes engiune.js -->
<dwr:engine-js />
</head>
<body>
<!-- sets the userType script session attribute, this can now be used by a reverse ajax thread -->
<dwr:script-session-set var="userType" value="restricted" />
<!-- copies from the script session to a page scoped attribute -->
<dwr:script-session-copy fromVar="userType" toVar="pageUserType" toScope="page" />
<!-- page scoped attribute can be used by jstl etc -->
<c:out value="${pageUserType}" />
</body>
</html>
<!-- WebContextBuilder.disengageThread() -->
</dwr:script-session>