On Sat, Oct 3, 2009 at 10:43 AM, Peter Robinett <[email protected]> wrote:
>
> Thanks, Kevin. I'm going to poke around with lift-json a bit more but
> a case class may be the way to go.

case classes definitely get you some juicy extras, it becomes a lot
easier to filter or map a list of readings when compared to the raw
json.
You might also want to look at record/mapper if database persistence
is your thing...


> As for the datetime, it's actually stored as a Long representing a
> millisecond Unix timestamp. I've considered scala-time but haven't
> seen the need to switch yet.

I'm with DavidP on this one, get as much rich type info into the
system at the earliest opportunity.  A timestamp definitely carries
more semantic meaning than a number.  Imagine trying to filter the 30
days worth of readings that were taken between 9am and 5pm GMT (when
your server is running on EST)

> Peter
>
> On Oct 3, 11:13 am, Kevin Wright <[email protected]>
> wrote:
>> Sounds to me like you want to create yourself a small helper function
>> that can map that structure into your own case class, something like:
>>
>> case class TempReading(node:String, dt:Int, temp:Double)
>>
>> It should be possible to do this as a layer on top of the json parser.
>> So you can go from:
>>
>>         Object(
>>                 List(
>>                         JField(node,JString(00:1D:C9:00:04:9F)),
>>                         JField(dt,JInt(1254553581405)),
>>                         JField(temp,JDouble(27.5))
>>                 )
>>         )
>>
>> to:
>>
>>         TempReading("00:1D:C9:00:04:9F", 1254553581405, 27.5)
>>
>> A Map would be an improvement over the raw json, but still is nowhere
>> near as concise or type-safe as the dedicated structure.
>>
>> You probably also want to rethink using ints for datetime (I guess
>> this is what dt represents).  Take a look at the scala-time library,
>> which is a nice wrapper over Java's joda-time.
>>
>> On Sat, Oct 3, 2009 at 9:46 AM, Peter Robinett <[email protected]> 
>> wrote:
>>
>> > I guess this is basically a question for Joni, but I figure I'll throw
>> > it out here for everyone to see.
>>
>> > Would it be possible to have extract() support Mapper instances in
>> > additional to standard case classes?
>>
>> > After parsing some JSON I get the following JValue: JObject(List(JField
>> > (node,JString(00:1D:C9:00:04:9F)), JField(dt,JInt(1254553581405)),
>> > JField(temp,JDouble(27.5)))). I'd like to turn this into a new
>> > instance of my Packet model and it'd be awesome if extract could do
>> > that.
>>
>> > I don't know how hard would it be to add this feature, so I don't know
>> > if this is a reasonable request. This would make making JSON API
>> > endpoints really easy for me and I hope for other people too.
>>
>> > Peter Robinett
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to