Hi all,
When I added the Json response, I believe the required input was JObject, which is too restrictive and relaxed to JValue. The problem with JValue, however small, is that it has subtypes for which there are no valid serialized formats (JNothing, JField). I've pushed an experimental fix for this, available here: https://github.com/chrislewis/Unfiltered/compare/jserializable The solution introduces the type class JSerializable of which only valid instances are available (namely JObject, JArray, JNull.type, JDouble, JInt, JString, and JBool). One could argue this isn't really that important, but it remains that the current implementation can result either a) throw a runtime exception if passed JNothing or b) deliver invalid json to the client if given JField. -chris |
hi chris, I relax it to JValue since json allows arrays and values. One thing I noticed in your test is that `"answer" -> Seq(42)` needed to be explicitly assigned to a JObject.
I am assuming you had to change it because it's just Tuple2[String, Seq[Int]], which turns into JObject by virtue of lift-json implicits, and plain Tuple2[String, Seq[Int]] wasn't recognized to be JSerializable.
before: case GET(UFPath("/jsonp/lift-json/optional") & Jsonp.Optional(callback)) => callback respond { import net.liftweb.json.JsonAST._
import net.liftweb.json.JsonDSL._ "answer" -> Seq(42) } after: case GET(UFPath("/jsonp/lift-json/optional") & Jsonp.Optional(callback)) => callback respond {
import net.liftweb.json.JsonAST._ import net.liftweb.json.JsonDSL._ val obj: JObject = ("answer" -> Seq(42)) obj } I personally think JValue is good enough, but I wonder if there's a clean way to allow `"answer" -> Seq(42)` as before without reimplementing the DSL. eugene
On Tue, Mar 29, 2011 at 5:47 PM, chris_lewis [via Databinder] <[hidden email]> wrote:
Hi all, |
Hi! Yeah, and also strings, ints, bools, and nulls. Right. It is a bit of a bummer - there's probably cleaner way but I haven't had the time to clean it up yet. My issue with JValue is that it's not type-safe in that it allows invalid content to be streamed as if it were valid JSON. This can be resolved at the type level, and I want to exploit that. I agree that losing the lift DSL sucks, yet I still prefer static guarantees. I'll make some time to find a solution - if you have any input please share :-). Honestly, I think it makes sense for JSerializable (or something like it) to be part of the core lift-json lib. It's understandable its AST uses intermediate types to represent components of a JSON document, and that not every intermediate type is representable as JSON. However I am surprised that the serializable components aren't represented by a higher-level type. Perhaps I should chat with the lift folks ... -chris
|
Free forum by Nabble | Edit this page |