One form of jsonCall not working in Comet context

[dmclean62]

Mailing List thread

No example project available.

When using this form of jsonCall:

def jsonCall(jsCalcValue: JsExp, jsonContext: JsonContext, func: (JValue) ⇒ JValue): GUIDJsExp 

When "func" is called in a comet context, the client receives an empty response.

Antonio said:

Got it. This is the interaction of https://github.com/lift/framework/blob/master/web/webkit/src/main/scala/net/liftweb/http/CometActor.scala#L934
with https://github.com/lift/framework/blob/master/web/webkit/src/main/scala/net/liftweb/http/LiftServlet.scala#L637,
which means that a JsonResponse isn't ever generated correctly from a CometActor.

That's going to be a doozy to fix… We may end up wanting to push notices via the comet
response while pushing JSON via the AJAX response. But always doing that could result
in strange ordering issues, and sometimes doing that could lead to lack of clarity about when
that will happen vs not.

Will ponder it a bit; can you open an issue?

[Shadowfiend]

The basic question here is what we do when we have a JValue bundled with a JsCmd in the return value of liftSession.runParams. This seems like it's mostly a concern in comet actors, but we'll need to confirm that. One observation is that in this particular context, we are likely always returning only S.noticesToJsCmd, because of the mixed nature of the response data that comes back from runParams. So changing this behavior may take us from not really returning anything to returning something, which is much less potentially-breaking than other changes we could make.

For the comet case specifically, we see the comet actor line also appends LiftRules.noticesToJsCmd. However, since the notice stuff in S uses TransientRequestVars, I think any notice set in the comet would be invisible once we get back out of the comet and into LiftServlet's handling. IF that is true, that means LiftRules.noticesToJsCmd will always be empty in LiftServlet, which means a mixed JSON + notices return from the comet would always result in an empty response.

Some assumptions to be verified there, but we may be able to make a fix to this that is “additively backwards compatible”, which is to say it doesn't lose any data that wasn't already being lost before this. It could still result in changed behavior if somehow folks were relying on that data being lost, of course.