JSON serialization for enum types

[Geoff Liu]

Hi all,

I just ran into the problem discussed in this thread (didn't want to disturb that ancient discussion):

https://groups.google.com/forum/#!topic/liftweb/ivRDguibNCw

I was wondering if there's any interest in fixing the issue. I see two obvious ways of doing this:

1. Incorporate the workaround suggested in the thread directly into the EnumNameSerializer class, and

2. With the addition of TypeTags in Scala 2.10, substituting the ClassTags and Manifests with those.

1 is, of course, an embarrassing hack, but 2 is a much bigger change, so I can understand the reluctance. What do people think?

cheers,

Geoff

[Matt Farmer]

I think the TypeTags are still experimental in 2.10 aren’t they? If they were finalized in 2.11 though, that’s something I’d be interested in looking at / implementing… 

—
Matt Farmer
Software Engineer | Atlanta, GA
Crazy Goat Creative | Blog | Twitter

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[j...@joescii.com]

Old thread resurrection time... I have a client who has a large number of Enums defined, and it would be really handy for them if our enum serializers were type-aware. Now that Lift is done with supporting Scala 2.10, I thought I'd take a preliminary peek under the covers of our code to get something working. 

As pointed out in this thread, part of the problem is that via reflection we record Enumeration.Value in the TypeInfo object when we encounter enums. This doesn't contain enough type information to know which enum is in question. Furthermore, I also found this blog post seems to have all anyone needs to figure this one out.

I'm struggling to see a path forward to support this better enum serializer we want without breaking existing API and/or behavior. Ideally we would just need to change the two enum serializers, but we have to change our reflection code to record the surrounding type some how (i.e. the object or whatever which extends Enumeration and defines the Values). Here are the options I've thought so far:

1) Instead of recording the Value type, record the surrounding type. This would preserve our APIs as is, but anyone's code which has been written to expect an Enumeration.Value to workaround our enum limitations would be broken at run time.

2) Add another parameter (probably the TypeTag) to TypeInfo case class. This would break all over the place, but it would be a compile-time failure. 

3) Hijack the existing parameterizedType field in TypeInfo to contain the Enumeration.Value's surrounding type. This could still break existing code if folks expect this field to be None. I suspect there other assumptions that would likely be broken by this approach based on what I've seen in the code. So while this one seems to do the least damage on the surface, I think having this special case behavior for enums would cause us greater grief down the line.

I'm going to see if I can get a POC of the first one or two ideas to see what else I learn.

I'd love any thoughts or feedback.

Joe

[Matt Farmer]

Have you tried taking my json-extractor-ng project out for a spin? It’s built on Scala reflection and would in theory support enum out of the box.

No promises though.

[Joe Barnes]

No I have not. Thanks for that tip. Unfortunately it won't trivially work because we're using lift-ng which only has the json Formats object on its API and uses it with Lift's Extractor. It's not the first time I've been bitten by not keeping the lift-ng API simple and deal only with JValues. One of those hindsight is 20/20 things :) 

Joe

/**

 * Joe Barnes

 * Owner/Principal Consultant, joescii, llc

 * 256.541.0377

 * j...@joescii.com

 */

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.