[Lift] Re: JSONParse.parse and List[Any]

2009-10-03 Thread Peter Robinett

Thanks, Tim. I was assuming that it was included as a dependency of
lift-core but as I think about I can see why not!

Peter

On Oct 2, 7:24 pm, Tim Nelson tnell...@gmail.com wrote:
 Add this below the lift-core dependency:

 dependency
    groupIdnet.liftweb/groupId
      artifactIdlift-json/artifactId
    version1.1-SNAPSHOT/version
  /dependency

 Tim

 On Fri, Oct 2, 2009 at 11:17 AM, Peter Robinett 
 pe...@bubblefoundry.comwrote:



  Thanks, David. Unfortunately, I get errors that net.liftweb.json does
  not exist. I imagine this is a configuration problem with my pom.xml,
  which is here:http://gist.github.com/199860. Could you or someone
  else conversant in Maven give me some tips to how to make sure I get
  lift-json?

  Thanks,
  Peter

  On Oct 2, 2:26 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
   Peter,

   I'd suggest using the stuff in lift-json.  It's a much faster, richer way
  to
   use JSON.

   Thanks,

   David

   On Thu, Oct 1, 2009 at 4:31 PM, Peter Robinett pe...@bubblefoundry.com
  wrote:

Hi all,

Building off of a previous thread[1], I'm trying to parse a POST
request that contains JSON data. Specifically, I expect a JSON array
of JSON objects representing Packet model data and want to have a List
[Packet] at the end.

I am trying the following:
val packets = for {
       JSONPackets - req.param(packets)
       packet - JSONParser.parse(JSONPackets)
       nodeId - packet.param(node)
       node - nodeId.toLong
} yield {
       val packet = Packet.create.node(node)
       packet.save
       packet
}

The problem is that JSONParser.parse returns a List[Any], so packet is
of type Any. I can try to convert packet to a Map with
packet.asInstanceOf[Map[String, String]], but this seems to just push
my type problems to the next line of code. I'm having a hard time
getting to the point where I have the Map[String, String] from which I
know I can extract values to create Packets, so I would appreciate
suggestions on how to do this.

This all seems quite complicated and I wonder if I'm missing an easier
way to do this. Is JSONParse the way to go, or should I switch to
Joni's lift-json stuff? I'm using 1.1-M5 but would be willing to
switch to 1.1-SNAPSHOT...

Thanks for your help.

Peter Robinett

[1]
   http://groups.google.com/group/liftweb/browse_thread/thread/5ffe64492.
  ..
[2]http://groups.google.com/group/liftweb/msg/c0103375623f788f

   --
   Lift, the simply functional web frameworkhttp://liftweb.net
   Beginning Scalahttp://www.apress.com/book/view/1430219890
   Follow me:http://twitter.com/dpp
   Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] lift-json's extract and Mapper

2009-10-03 Thread Peter Robinett

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 liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: lift-json's extract and Mapper

2009-10-03 Thread Kevin Wright

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 pe...@bubblefoundry.com 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 liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: lift-json's extract and Mapper

2009-10-03 Thread Kevin Wright

Totally untested, but something like this might work for you:


case class TempReading(node:String, dt:Int, temp:Double)

object JsonTempReading {
  def unapply(obj: JObject) : Option[TempReading] {
obj match {
  case JObject(List(
JField(node, JString(node)),
JField(dt, JInt(dt)),
JField(temp, JDouble(temp))
  )) = Some(TempReading(node, dt, temp))   
  case _ = None
}
  }
}

val obj : JObject = ... get json data...
val reading = JsonTempReading.unapply(obj)



On Sat, Oct 3, 2009 at 10:13 AM, Kevin Wright
kev.lee.wri...@googlemail.com 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 pe...@bubblefoundry.com 
 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 liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: a question about host based url rewriting

2009-10-03 Thread Jeppe Nejsum Madsen

harryh har...@gmail.com writes:

 Are they essentially two independent apps in terms of templates and
 snippets?

 Yes.  Though they share the same model (+ some random extra library
 code).

 That seems like you just want a virtual host via nginx or some
 other web server.

 I could go that route.  But then I have another app to build + deploy.

I believe the lift rewriting is internal to lift, ie the client never
sees/needs to worry about the rewritten request?

In that case, you could have nginx or some other frontend  simply ignore all the
/mobile urls (or redirect to m.* :-)

/Jeppe

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



[Lift] Re: lift-json's extract and Mapper

2009-10-03 Thread Peter Robinett

Thanks, Kevin. I'm going to poke around with lift-json a bit more but
a case class may be the way to go.

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.

Peter

On Oct 3, 11:13 am, Kevin Wright kev.lee.wri...@googlemail.com
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 pe...@bubblefoundry.com 
 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 liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Started integrating lift in a scala+spring project. Feedback?

2009-10-03 Thread rintcius

Hmm, I am still confused...

Maybe better to get into a specific use case.
Suppose i have the following:
1) a lift application just serving stuff via the Servlet interface
2) an object in the ServletContext (let's say spring's
ApplicationContext)
3) a snippet that does not need a session but needs access to this
object in the ServletContext
  (let's say just some static content but reusing spring's i18n
support)

How do I get access to this object in the ServletContext from such a
snippet?
Or are you telling me that this use case makes no sense in Lift?

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



[Lift] MappedStringForeignKey and Schemifier

2009-10-03 Thread Peter Robinett

I have a model, Node, with a string index. I have another model,
Packet, which has a MappedStringForeignKey to Node. Unfortunately,
Schemifier doesn't seem to respect the MappedStringForeignKey type and
creates a BIGINT column in the packets table, as you can see from its
output:
INFO - CREATE TABLE packets (temp DOUBLE , id BIGINT UNSIGNED NOT NULL
AUTO_INCREMENT UNIQUE KEY , mac BIGINT UNSIGNED , dt DATETIME , mah
DOUBLE , lux DOUBLE , rssi DOUBLE)  ENGINE = InnoDB
INFO - ALTER TABLE packets ADD CONSTRAINT packets_PK PRIMARY KEY(id)
INFO - CREATE INDEX packets_mac ON packets ( mac )

Is this a bug? I can override fieldCreatorString for the foreign key
but I don't think I should have to. This is with 1.1-SNAPSHOT.

Peter

And the relevant parts of my models:

class Node extends KeyedMapper[String, Node] {
 def getSingleton = Node
 /* MAC address as primary key */
 def primaryKeyField = mac
 object mac extends MappedStringIndex(this, 17) with IndexedField
[String] {
override def dbDisplay_? = true
override lazy val defaultValue = randomString(maxLen)
/* allow user-defined primary key */
override def writePermission_? = true
override def dbAutogenerated_? = false
private var myDirty = false
override def dirty_? = myDirty
override def dirty_?(b : Boolean) = { myDirty = b;
super.dirty_?(b) }
override def fieldCreatorString(dbType: DriverType, colName:
String): String = colName+ CHAR(+maxLen+) NOT NULL 
 }
}

class Packet extends LongKeyedMapper[Packet] with IdPK {
 def getSingleton = Packet
 object node extends MappedStringForeignKey(this, Node, 17) {
// Change the default behavior to add a database index for
this column.
override def dbIndexed_? = true
override def dbColumnName = mac
 }
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: lift-json's extract and Mapper

2009-10-03 Thread Kevin Wright

On Sat, Oct 3, 2009 at 10:43 AM, Peter Robinett pe...@bubblefoundry.com 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 kev.lee.wri...@googlemail.com
 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 pe...@bubblefoundry.com 
 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 liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: lift-json's extract and Mapper

2009-10-03 Thread Peter Robinett


On Oct 3, 12:04 pm, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
 On Sat, Oct 3, 2009 at 10:43 AM, Peter Robinett pe...@bubblefoundry.com 
 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.

Great.

 You might also want to look at record/mapper if database persistence
 is your thing...

Hence the original question, whether I could use extract to get
instances of my Mapper model. ;-) Case classes would just add another
step in the translation, but it looks like it's both necessary and
easy.

 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)

Good point. Do you know of any sample Mapper code that uses scala-
time? I'm still not very strong with making my own mapped types.

Peter

  Peter

  On Oct 3, 11:13 am, Kevin Wright kev.lee.wri...@googlemail.com
  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 pe...@bubblefoundry.com 
  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 liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: a question about host based url rewriting

2009-10-03 Thread Timothy Perrett

Jeppe, you are exactly right. Doing that should work no problem.

Cheers, Tim

Sent from my iPhone

On 3 Oct 2009, at 10:33, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:


 harryh har...@gmail.com writes:

 Are they essentially two independent apps in terms of templates and
 snippets?

 Yes.  Though they share the same model (+ some random extra library
 code).

 That seems like you just want a virtual host via nginx or some
 other web server.

 I could go that route.  But then I have another app to build +  
 deploy.

 I believe the lift rewriting is internal to lift, ie the client never
 sees/needs to worry about the rewritten request?

 In that case, you could have nginx or some other frontend  simply  
 ignore all the
 /mobile urls (or redirect to m.* :-)

 /Jeppe

 


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



[Lift] Re: lift-json's extract and Mapper

2009-10-03 Thread Kevin Wright

On Sat, Oct 3, 2009 at 11:33 AM, Peter Robinett pe...@bubblefoundry.com wrote:


 On Oct 3, 12:04 pm, Kevin Wright kev.lee.wri...@googlemail.com
 wrote:
 On Sat, Oct 3, 2009 at 10:43 AM, Peter Robinett pe...@bubblefoundry.com 
 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.

 Great.



 You might also want to look at record/mapper if database persistence
 is your thing...

 Hence the original question, whether I could use extract to get
 instances of my Mapper model. ;-) Case classes would just add another
 step in the translation, but it looks like it's both necessary and
 easy.

Ahh, I misinterpreted Mapper as Map - a very different beast :)

You could always use the JsonTempReading extractor from above to
directly build a Mapper class instead of a case class.

Having said that... going via a case class here would allow some
benefits, such as performing json decoding and mapper validation as
independent operations.  The first pass would use the extractor to
return an Option[TempReading], the second pass would then map this to
a Box - with the error condition being used if there's a validation
failure.  This arrangement should also be easier to test and debug, I
think that separating multiple steps like this is generally a Good
Thing, especially in the realms of functional programming.




 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)

 Good point. Do you know of any sample Mapper code that uses scala-
 time? I'm still not very strong with making my own mapped types.

I've not yet used both libraries at the same time, though I do
remember some discussion a while back about doing exactly this.
Probably worth a search back through the group messages, but I'm
pretty sure it's not difficult to do.

 Peter

  Peter

  On Oct 3, 11:13 am, Kevin Wright kev.lee.wri...@googlemail.com
  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 pe...@bubblefoundry.com 
  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 liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Lift compiled against 2.7.7.RC1

2009-10-03 Thread Indrajit Raychaudhuri

Folks,

Lift snapshot artifacts built on Scala 2.7.7.RC1 are now available in 
scala-tools repository.

The artifacts follow the version pattern 1.1-scala2.7.7.RC1-SNAPSHOT. So 
they are all available in the usual snapshot repository location 
(http://scala-tools.org/repo-snapshots) as 
lift-module-1.1-scala2.7.7.RC1-SNAPSHOT.

To try out the new version in your project, all that you'd need to do is 
change scala.version to 2.7.7.RC1 and set the version number of all 
lift-modules to 1.1-scala2.7.7.RC1-SNAPSHOT.

You can also use Maven's project profile feature to switch Lift and 
Scala between regular version and 2.7.7.RC1 version.

One way to do this would be to add a project profile section in your 
pom.xml as thus:

!-- ... --
!-- ... --

   profiles
 profile
   idscala277/id
   properties
 scala.version2.7.7.RC1/scala.version
   /properties
   dependencies
   dependency
   groupIdnet.liftweb/groupId
   artifactIdlift-core/artifactId
   version1.1-scala2.7.7.RC1-SNAPSHOT/version
 /dependency
   /dependencies
 /profile
   /profiles

!-- ... --

/project

With this section in place in your project pom,

- Run mvn clean install for scala-2.7.5 version

- Run mvn -Pscala277 clean install for scala-2.7.7.RC1 version

Cheers, Indrajit


NB: Thanks David for fixing the version typo that I wrongly committed!


On 03/10/09 3:57 AM, David Pollak wrote:
 Folks,

 I have pushed a branch of Lift that compiles against Scala 2.7.7.RC1 to
 the Lift repository (dpp_wip_277).

 Indrajit, please do Hudson magic such that there are Maven artifacts
 that people can test against and send out changes that people will need
 to make to their pom.xml file to test against the 2.7.7.RC1 build of Lift.

 I found no source incompatibilities, so your code should 'just work.'
   But, please report any unexpected (i.e., different than Lift running
 against Scala 2.7.5) behaviors to this list.  We'll reproduce and
 determine if the issue is in Lift (we'll update Lift) or in 2.7.7.RC1
 (we'll post to the Scala list/trac).

 Thanks,

 David

 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 

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



[Lift] Re: RFC: Restructuring Lift Codebase [Round 2]

2009-10-03 Thread Indrajit Raychaudhuri



On 02/10/09 6:25 PM, David Pollak wrote:


 On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri
 indraj...@gmail.com mailto:indraj...@gmail.com wrote:




 On Oct 2, 5:39 pm, David Pollak feeder.of.the.be...@gmail.com
 mailto:feeder.of.the.be...@gmail.com wrote:
   On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri
   indraj...@gmail.com mailto:indraj...@gmail.comwrote:
  
  
  
  
  
Folks,
  
Following up from the previous round, I am summarizing what we
discussed so far with an attempt to converge and move on to impl.
Would be keen to have feedback and possibly arrive at some
 resolution
on the outstanding items. (Meaty stuff below the module structure)
  
liftweb
  
- lift-core [H]
 - lift-base [J]
 - lift-util [J]
 - lift-actor
 - lift-json
 - lift-webkit [K]
  
- lift-persistence
 - lift-mapper
 - lift-record
 - lift-jpa
  
- lift-modules [L]
 - lift-testkit
 - lift-osgi
 - lift-wizard
 - lift-widgets
 - lift-machine
 - lift-textile
 - lift-facebook
 - lift-amqp
 - lift-xmpp
 - lift-openid
 - lift-oauth
 - lift-paypal
 - lift-jta
  
- lift-archetypes
 - ...
  
- lift-examples [M]
 - ...
  
- lift-site
  
- lift-resources [N]
 - lift-root-model
 - lift-site-skin
 - lift-installer
 - misc config resources (scaladoc, javadoc etc.)
  
Resolved since:
  
[A] lift-* prefix is fine/preferred for top level categories
 (dir_name
== artifactId) [Heiko]
  
[B] For Lift users not using Maven these *-all.jars will be
 valuable.
Assembly preferred to meta [Heiko]
  
[C] lift-testkit to move to lift-modules. Applications would use it
under 'test' scope. [David]
  
[D] lift-json to be part of core [Marius]
  
[E] lift-persistence being separated from lift-core into it's own
category and made optional [Marius]
  
[F] No deep nesting within modules (no submodules) for now [Heiko]
  
[G] Presentations and docs to be in central repository for now
[+1:David/Tim/Derek, +0:Indrajit, -1:Heiko/Viktor].
Settling for central repo at the moment (a: least change, b: in a
hurry to converge, c: effect of living in largest democracy in the
world!).  Later on, I'll attempt to make this part of site
 build and
make them more conveniently available.
  
Outstanding since:
  
[H] lift-core has to get a better and more appropriate name
 (and also
to avoid confusion since lift-core == 'everything lift' at the
moment).
   Starting with two that come to my mind.
   - lift-lite (Members of this category make up the lightweight,
minimalistic Lift distribution that would help you build a Lift
 based
application)
   - lift-genesis (Members of this category make up the genesis of
your Lift based application)
   - lift-mini (Minimal Lift distribution to get started with Lift)
   - lift-minimal (Same as above)
  
   How about lift-web (the stuff you need to build a web application)

 Hmm, lift-web vs lift-web/lift-webkit could add to confusion. Too many
 combination of lift+web (liftweb.net http://liftweb.net, lift-web,
 lift-webkit) for
 comfort.



 okay.

Now that lift-base is free for grab, I am settling for lift-base for 
lack of any other clear winner.

So we have lift-base = (lift-common, lift-util, lift-json, lift-actor, 
lift-webkit)

Feel free to comment in favor or against (vote/veto) if someone has a 
better option popping up.



  
  
  
[J] lift-base, lift-util needs more unambiguous names.
   - lift-base - lift-common [+1:Naftoli/Derek/Stuart/Marius/Tim/
Heiko/Viktor, +0:Indrajit -1:DavidB (very strong)] But still
 good to
have even better option.
  
   +1 for lift-common, but I'm not wedded to the name.
  
   - lift-util - lift-util (no change) [+1:Marius/David (status
quo)]
  
   I'm going to mandate that this not change.  The cost of changing
 is too high
   and the value to changing is minimal.
  
   - lift-util - lift-webutil
 [+1:Naftoli/Derek/Stuart/Indrajit/Tim/
Heiko/Viktor]
  
   Veto.

 Fair do. let's settle for lift-common and lift-util for now.


snip/

Cheers, Indrajit


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe 

[Lift] Re: Extending Session Expiry

2009-10-03 Thread Timothy Perrett
OK, so first testing says that

session-config
   session-timeout10/session-timeout
/session-config

does the trick - for some strange reason winstone appears to cut  
sessions really short

Cheers, Tim

On 3 Oct 2009, at 01:30, Timothy Perrett wrote:

 This explains why I'm not seeing the issue in dev mode with mvn  
 jetty:run

 I'm deploying to embedded winstone so it's quite possible the  
 sessions are being reaped by winstone itself. I'll investgate and  
 report back :-)

 Cheers

 Tim

 Sent from my iPhone

 On 3 Oct 2009, at 00:17, David Pollak  
 feeder.of.the.be...@gmail.com wrote:

 Tim,

 By default, Lift sessions last as long as the contain keeps  
 sessions alive (usually 15-30 minutes).

 LiftSession.inactivityLength determines when the session gets timed  
 out, unless the container times it out first.

 Thanks,

 David

 On Fri, Oct 2, 2009 at 9:58 AM, Timothy Perrett timo...@getintheloop.eu 
  wrote:

 Guys,

 Im building an application that works with Twitter OAuth - in order  
 to
 do that, i make requests to twitter and get various tokens and hold
 them in a session var.

 However, it appears (looking at my logs) that when the user is  
 bounced
 out to twitter.com for the authentication the session in my lift app
 is expiring, thus my session vars are then Empty when the user
 returns.

 I had a poke in LiftRules, but there appears to be nothing directly
 indicating how to set a session timeout explicitly. Any suggestions  
 on
 how I could extend it? (or just stop it expiring straight away)

 Cheers, Tim




 -- 
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics



 


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



[Lift] Re: MappedStringForeignKey and Schemifier

2009-10-03 Thread Thomas Rampelberg

I had some issues getting string foreign keys working that required
changes to MetaMapper (because of how it handles autogenerated primary
keys). That said, Here's some code that'll fix the issue you're
currently having:

class StringForeignKey[T:Mapper[T],O:KeyedMapper[String, O]](
  override val fieldOwner: T, foreign: = KeyedMetaMapper[String, O],
maxLen: Int)
  extends MappedStringForeignKey[T,O](fieldOwner, foreign, maxLen) {
override def fieldCreatorString(dbType: DriverType,
colName: String): String =
colName +  VARCHAR( + maxLen + )
}

class InfoHashForeignKey[T:Mapper[T],O:KeyedMapper[String, O]](
  override val fieldOwner: T, foreign: = KeyedMetaMapper[String, O])
  extends StringForeignKey[T,O](fieldOwner, foreign, 20)

If you'd like to take a look at my models and how everything's hooked
together, I've got the source up on github at
http://github.com/pyronicide/swarmstat .

On Sat, Oct 3, 2009 at 3:00 AM, Peter Robinett pe...@bubblefoundry.com wrote:

 I have a model, Node, with a string index. I have another model,
 Packet, which has a MappedStringForeignKey to Node. Unfortunately,
 Schemifier doesn't seem to respect the MappedStringForeignKey type and
 creates a BIGINT column in the packets table, as you can see from its
 output:
 INFO - CREATE TABLE packets (temp DOUBLE , id BIGINT UNSIGNED NOT NULL
 AUTO_INCREMENT UNIQUE KEY , mac BIGINT UNSIGNED , dt DATETIME , mah
 DOUBLE , lux DOUBLE , rssi DOUBLE)  ENGINE = InnoDB
 INFO - ALTER TABLE packets ADD CONSTRAINT packets_PK PRIMARY KEY(id)
 INFO - CREATE INDEX packets_mac ON packets ( mac )

 Is this a bug? I can override fieldCreatorString for the foreign key
 but I don't think I should have to. This is with 1.1-SNAPSHOT.

 Peter

 And the relevant parts of my models:

 class Node extends KeyedMapper[String, Node] {
  def getSingleton = Node
  /* MAC address as primary key */
  def primaryKeyField = mac
  object mac extends MappedStringIndex(this, 17) with IndexedField
 [String] {
        override def dbDisplay_? = true
        override lazy val defaultValue = randomString(maxLen)
        /* allow user-defined primary key */
        override def writePermission_? = true
        override def dbAutogenerated_? = false
        private var myDirty = false
        override def dirty_? = myDirty
        override def dirty_?(b : Boolean) = { myDirty = b;
 super.dirty_?(b) }
        override def fieldCreatorString(dbType: DriverType, colName:
 String): String = colName+ CHAR(+maxLen+) NOT NULL 
  }
 }

 class Packet extends LongKeyedMapper[Packet] with IdPK {
  def getSingleton = Packet
  object node extends MappedStringForeignKey(this, Node, 17) {
        // Change the default behavior to add a database index for
 this column.
        override def dbIndexed_? = true
        override def dbColumnName = mac
  }
 }
 


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



[Lift] Re: RFC: Restructuring Lift Codebase [Round 2]

2009-10-03 Thread marius d.


Why not lift-core = (lift-common, lift-util, lift-json, lift-
actor,lift-webkit) ?

Br's,
Marius

On Oct 3, 7:33 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 On 02/10/09 6:25 PM, David Pollak wrote:





  On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri
  indraj...@gmail.com mailto:indraj...@gmail.com wrote:

      On Oct 2, 5:39 pm, David Pollak feeder.of.the.be...@gmail.com
      mailto:feeder.of.the.be...@gmail.com wrote:
        On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri
        indraj...@gmail.com mailto:indraj...@gmail.comwrote:

         Folks,

         Following up from the previous round, I am summarizing what we
         discussed so far with an attempt to converge and move on to impl.
         Would be keen to have feedback and possibly arrive at some
      resolution
         on the outstanding items. (Meaty stuff below the module structure)

         liftweb

         - lift-core [H]
          - lift-base [J]
          - lift-util [J]
          - lift-actor
          - lift-json
          - lift-webkit [K]

         - lift-persistence
          - lift-mapper
          - lift-record
          - lift-jpa

         - lift-modules [L]
          - lift-testkit
          - lift-osgi
          - lift-wizard
          - lift-widgets
          - lift-machine
          - lift-textile
          - lift-facebook
          - lift-amqp
          - lift-xmpp
          - lift-openid
          - lift-oauth
          - lift-paypal
          - lift-jta

         - lift-archetypes
          - ...

         - lift-examples [M]
          - ...

         - lift-site

         - lift-resources [N]
          - lift-root-model
          - lift-site-skin
          - lift-installer
          - misc config resources (scaladoc, javadoc etc.)

         Resolved since:

         [A] lift-* prefix is fine/preferred for top level categories
      (dir_name
         == artifactId) [Heiko]

         [B] For Lift users not using Maven these *-all.jars will be
      valuable.
         Assembly preferred to meta [Heiko]

         [C] lift-testkit to move to lift-modules. Applications would use it
         under 'test' scope. [David]

         [D] lift-json to be part of core [Marius]

         [E] lift-persistence being separated from lift-core into it's own
         category and made optional [Marius]

         [F] No deep nesting within modules (no submodules) for now [Heiko]

         [G] Presentations and docs to be in central repository for now
         [+1:David/Tim/Derek, +0:Indrajit, -1:Heiko/Viktor].
         Settling for central repo at the moment (a: least change, b: in a
         hurry to converge, c: effect of living in largest democracy in the
         world!).  Later on, I'll attempt to make this part of site
      build and
         make them more conveniently available.

         Outstanding since:

         [H] lift-core has to get a better and more appropriate name
      (and also
         to avoid confusion since lift-core == 'everything lift' at the
         moment).
            Starting with two that come to my mind.
            - lift-lite (Members of this category make up the lightweight,
         minimalistic Lift distribution that would help you build a Lift
      based
         application)
            - lift-genesis (Members of this category make up the genesis of
         your Lift based application)
            - lift-mini (Minimal Lift distribution to get started with Lift)
            - lift-minimal (Same as above)

        How about lift-web (the stuff you need to build a web application)

      Hmm, lift-web vs lift-web/lift-webkit could add to confusion. Too many
      combination of lift+web (liftweb.net http://liftweb.net, lift-web,
      lift-webkit) for
      comfort.

  okay.

 Now that lift-base is free for grab, I am settling for lift-base for
 lack of any other clear winner.

 So we have lift-base = (lift-common, lift-util, lift-json, lift-actor,
 lift-webkit)

 Feel free to comment in favor or against (vote/veto) if someone has a
 better option popping up.





         [J] lift-base, lift-util needs more unambiguous names.
            - lift-base - lift-common [+1:Naftoli/Derek/Stuart/Marius/Tim/
         Heiko/Viktor, +0:Indrajit -1:DavidB (very strong)] But still
      good to
         have even better option.

        +1 for lift-common, but I'm not wedded to the name.

            - lift-util - lift-util (no change) [+1:Marius/David (status
         quo)]

        I'm going to mandate that this not change.  The cost of changing
      is too high
        and the value to changing is minimal.

            - lift-util - lift-webutil
      [+1:Naftoli/Derek/Stuart/Indrajit/Tim/
         Heiko/Viktor]

        Veto.

      Fair do. let's settle for lift-common and lift-util for now.

 snip/

 Cheers, Indrajit
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to 

[Lift] Re: RFC: Restructuring Lift Codebase [Round 2]

2009-10-03 Thread Indrajit Raychaudhuri



On 04/10/09 12:32 AM, marius d. wrote:


 Why not lift-core = (lift-common, lift-util, lift-json, lift-
 actor,lift-webkit) ?

1. Initially, it didn't sound right to me (when we had lift-base, 
lift-util etc.).

2. DavidP commented, that lift-core currently means everything Lift. 
and he thought we'd need another name.

3. DavidB pointed out an old thread[a] and suggested that:

lift-core == lift-full, but to be backward compatible with the time
when there is one jar (lift-core), we keep the name.

[a] 
http://groups.google.com/group/lift-committers/browse_thread/thread/2fdadf2f9db51a04/0bae3866bbc6d581

Of these, #1 doesn't hold true anymore, thus nullified.

Cheers, Indrajit


 Br's,
 Marius

 On Oct 3, 7:33 pm, Indrajit Raychaudhuriindraj...@gmail.com  wrote:
 On 02/10/09 6:25 PM, David Pollak wrote:





 On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri
 indraj...@gmail.commailto:indraj...@gmail.com  wrote:

  On Oct 2, 5:39 pm, David Pollakfeeder.of.the.be...@gmail.com
  mailto:feeder.of.the.be...@gmail.com  wrote:
 On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri
 indraj...@gmail.commailto:indraj...@gmail.comwrote:

   Folks,

   Following up from the previous round, I am summarizing what we
   discussed so far with an attempt to converge and move on to 
 impl.
   Would be keen to have feedback and possibly arrive at some
  resolution
   on the outstanding items. (Meaty stuff below the module 
 structure)

   liftweb

   - lift-core [H]
 - lift-base [J]
 - lift-util [J]
 - lift-actor
 - lift-json
 - lift-webkit [K]

   - lift-persistence
 - lift-mapper
 - lift-record
 - lift-jpa

   - lift-modules [L]
 - lift-testkit
 - lift-osgi
 - lift-wizard
 - lift-widgets
 - lift-machine
 - lift-textile
 - lift-facebook
 - lift-amqp
 - lift-xmpp
 - lift-openid
 - lift-oauth
 - lift-paypal
 - lift-jta

   - lift-archetypes
 - ...

   - lift-examples [M]
 - ...

   - lift-site

   - lift-resources [N]
 - lift-root-model
 - lift-site-skin
 - lift-installer
 - misc config resources (scaladoc, javadoc etc.)

   Resolved since:

   [A] lift-* prefix is fine/preferred for top level categories
  (dir_name
   == artifactId) [Heiko]

   [B] For Lift users not using Maven these *-all.jars will be
  valuable.
   Assembly preferred to meta [Heiko]

   [C] lift-testkit to move to lift-modules. Applications would 
 use it
   under 'test' scope. [David]

   [D] lift-json to be part of core [Marius]

   [E] lift-persistence being separated from lift-core into it's 
 own
   category and made optional [Marius]

   [F] No deep nesting within modules (no submodules) for now 
 [Heiko]

   [G] Presentations and docs to be in central repository for now
   [+1:David/Tim/Derek, +0:Indrajit, -1:Heiko/Viktor].
   Settling for central repo at the moment (a: least change, b: in 
 a
   hurry to converge, c: effect of living in largest democracy in 
 the
   world!).  Later on, I'll attempt to make this part of site
  build and
   make them more conveniently available.

   Outstanding since:

   [H] lift-core has to get a better and more appropriate name
  (and also
   to avoid confusion since lift-core == 'everything lift' at the
   moment).
   Starting with two that come to my mind.
   - lift-lite (Members of this category make up the 
 lightweight,
   minimalistic Lift distribution that would help you build a Lift
  based
   application)
   - lift-genesis (Members of this category make up the 
 genesis of
   your Lift based application)
   - lift-mini (Minimal Lift distribution to get started with 
 Lift)
   - lift-minimal (Same as above)

 How about lift-web (the stuff you need to build a web application)

  Hmm, lift-web vs lift-web/lift-webkit could add to confusion. Too many
  combination of lift+web (liftweb.nethttp://liftweb.net, lift-web,
  lift-webkit) for
  comfort.

 okay.

 Now that lift-base is free for grab, I am settling for lift-base for
 lack of any other clear winner.

 So we have lift-base = (lift-common, lift-util, lift-json, lift-actor,
 lift-webkit)

 Feel free to comment in favor or against (vote/veto) if someone has a
 better option popping up.





   [J] lift-base, lift-util needs more unambiguous names.
   - lift-base -  lift-common 
 

[Lift] 1.1-SNAPSHOT and Snippet problems?

2009-10-03 Thread Thomas Rampelberg

I just synced up to main this morning and now whenever I try and use
one of my snippets, I'm getting the traceback below. Any hints on what
I'm doing wrong? The snippet in question is just the basic
Util.in/Util.out that the tutorial has you write.

  div class=column span-17 last
lift:Util.in
  lift:bind name=content /
/lift:Util.in
lift:Util.out
  h3 class=alt
You must be logged in to view this content.
lift:menu.item name=LoginLogin/lift:menu.item
  /h3
/lift:Util.out
  /div

class Util {
  def in(html: NodeSeq) =
if (User.loggedIn_?) html else NodeSeq.Empty

  def out(html: NodeSeq) =
if (!User.loggedIn_?) html else NodeSeq.Empty
}

Message: java.lang.AbstractMethodError:
net.liftweb.util.Helpers$.tryo(Lscala/PartialFunction;Lscala/Function0;)Lnet/liftweb/util/Box;

net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$instantiateOrRedirect(LiftSession.scala:862)

net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1$$anonfun$apply$41.apply(LiftSession.scala:911)

net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1$$anonfun$apply$41.apply(LiftSession.scala:911)
net.liftweb.util.Full.flatMap(Box.scala:332)

net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1.apply(LiftSession.scala:911)

net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1.apply(LiftSession.scala:911)
net.liftweb.util.EmptyBox.or(Box.scala:374)

net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$findSnippetInstance(LiftSession.scala:910)

net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1$$anonfun$17.apply(LiftSession.scala:967)

net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1$$anonfun$17.apply(LiftSession.scala:967)
net.liftweb.util.EmptyBox.or(Box.scala:374)

net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1.apply(LiftSession.scala:967)

net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1.apply(LiftSession.scala:966)
net.liftweb.util.EmptyBox.or(Box.scala:374)

net.liftweb.http.LiftSession.locateAndCacheSnippet$1(LiftSession.scala:966)

net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48$$anonfun$apply$50.apply(LiftSession.scala:978)

net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48$$anonfun$apply$50.apply(LiftSession.scala:976)
net.liftweb.util.EmptyBox.openOr(Box.scala:372)

net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48.apply(LiftSession.scala:976)

net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48.apply(LiftSession.scala:976)
net.liftweb.util.EmptyBox.openOr(Box.scala:372)

net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45.apply(LiftSession.scala:975)

net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45.apply(LiftSession.scala:975)
net.liftweb.http.S$.doSnippet(S.scala:1586)
net.liftweb.http.LiftSession$$anonfun$18.apply(LiftSession.scala:973)
net.liftweb.http.LiftSession$$anonfun$18.apply(LiftSession.scala:972)
net.liftweb.util.Full.map(Box.scala:330)

net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$processSnippet(LiftSession.scala:972)

net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:1073)

net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:1061)
net.liftweb.util.NamedPF.apply(NamedPartialFunction.scala:30)
net.liftweb.util.NamedPF$.apply(NamedPartialFunction.scala:76)

net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58$$anonfun$apply$59.apply(LiftSession.scala:1094)

net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58$$anonfun$apply$59.apply(LiftSession.scala:1094)
net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)
net.liftweb.http.S$.setVars(S.scala:1414)

net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58.apply(LiftSession.scala:1093)

net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58.apply(LiftSession.scala:1093)
net.liftweb.http.S$.withAttrs(S.scala:1433)

net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57.apply(LiftSession.scala:1092)

net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57.apply(LiftSession.scala:1092)
net.liftweb.http.S$.doSnippet(S.scala:1586)


[Lift] Trouble getting lift up and running

2009-10-03 Thread Mobbit

Would be great to get some help setting up lift, guess I am kind of
lost here. I use Mac OS X Snow Leopard with 64bit Java 6.

When I try to create a new lift project as written in the tutorial I
get the following error message:

Invalid task 'archetypeArtifactId=lift-archetype-blank': you must
specify a valid lifecycle phase, or a goal in the format plugin:goal
or pluginGroupId:pluginArtifactId:pluginVersion:goal

Which is the first thing I don't understand. When I reduced the
command to the following line it worked:
mvn archetype:generate -U -DarchetypeGroupId=net.liftweb -
DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=1.0 -
DremoteRepositories=http://scala-tools.org/repo-releases

But, when I try mvn jetty:run it fails compiling.

error: overloaded method constructor Server with alternatives
(java.net.URL)org.mortbay.jetty.Server and
(org.mortbay.util.Resource)org.mortbay.jetty.Server and
(java.lang.String)org.mortbay.jetty.Server cannot be applied to (Int)
  val server = new Server(8080);
   ^
one error found
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] wrap: org.apache.commons.exec.ExecuteException: Process exited
with an error: 1(Exit value: 1)


Thanks a lot!

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



[Lift] Re: 1.1-SNAPSHOT and Snippet problems?

2009-10-03 Thread marius d.

What verions of lift are you using? It appears that lift-util is a
different version than lift ?

Br's,
Marius

On Oct 3, 11:11 pm, Thomas Rampelberg pyronic...@gmail.com wrote:
 I just synced up to main this morning and now whenever I try and use
 one of my snippets, I'm getting the traceback below. Any hints on what
 I'm doing wrong? The snippet in question is just the basic
 Util.in/Util.out that the tutorial has you write.

       div class=column span-17 last
         lift:Util.in
           lift:bind name=content /
         /lift:Util.in
         lift:Util.out
           h3 class=alt
             You must be logged in to view this content.
             lift:menu.item name=LoginLogin/lift:menu.item
           /h3
         /lift:Util.out
       /div

 class Util {
   def in(html: NodeSeq) =
     if (User.loggedIn_?) html else NodeSeq.Empty

   def out(html: NodeSeq) =
     if (!User.loggedIn_?) html else NodeSeq.Empty

 }

 Message: java.lang.AbstractMethodError:
 net.liftweb.util.Helpers$.tryo(Lscala/PartialFunction;Lscala/Function0;)Lnet/liftweb/util/Box;
         
 net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$instantiateOrRedirect(LiftSession.scala:862)
         
 net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1$$anonfun$apply$41.apply(LiftSession.scala:911)
         
 net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1$$anonfun$apply$41.apply(LiftSession.scala:911)
         net.liftweb.util.Full.flatMap(Box.scala:332)
         
 net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1.apply(LiftSession.scala:911)
         
 net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1.apply(LiftSession.scala:911)
         net.liftweb.util.EmptyBox.or(Box.scala:374)
         
 net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$findSnippetInstance(LiftSession.scala:910)
         
 net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1$$anonfun$17.apply(LiftSession.scala:967)
         
 net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1$$anonfun$17.apply(LiftSession.scala:967)
         net.liftweb.util.EmptyBox.or(Box.scala:374)
         
 net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1.apply(LiftSession.scala:967)
         
 net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1.apply(LiftSession.scala:966)
         net.liftweb.util.EmptyBox.or(Box.scala:374)
         
 net.liftweb.http.LiftSession.locateAndCacheSnippet$1(LiftSession.scala:966)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48$$anonfun$apply$50.apply(LiftSession.scala:978)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48$$anonfun$apply$50.apply(LiftSession.scala:976)
         net.liftweb.util.EmptyBox.openOr(Box.scala:372)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48.apply(LiftSession.scala:976)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48.apply(LiftSession.scala:976)
         net.liftweb.util.EmptyBox.openOr(Box.scala:372)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45.apply(LiftSession.scala:975)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45.apply(LiftSession.scala:975)
         net.liftweb.http.S$.doSnippet(S.scala:1586)
         net.liftweb.http.LiftSession$$anonfun$18.apply(LiftSession.scala:973)
         net.liftweb.http.LiftSession$$anonfun$18.apply(LiftSession.scala:972)
         net.liftweb.util.Full.map(Box.scala:330)
         
 net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$processSnippet(LiftSession.scala:972)
         
 net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:1073)
         
 net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:1061)
         net.liftweb.util.NamedPF.apply(NamedPartialFunction.scala:30)
         net.liftweb.util.NamedPF$.apply(NamedPartialFunction.scala:76)
         
 net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58$$anonfun$apply$59.apply(LiftSession.scala:1094)
         
 net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58$$anonfun$apply$59.apply(LiftSession.scala:1094)
         net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)
         net.liftweb.http.S$.setVars(S.scala:1414)
         
 net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58.apply(LiftSession.scala:1093)
         
 net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58.apply(LiftSession.scala:1093)
         net.liftweb.http.S$.withAttrs(S.scala:1433)
         
 

[Lift] Re: RFC: Restructuring Lift Codebase [Round 2]

2009-10-03 Thread marius d.

Ok ... got it. Thanks.

On Oct 3, 10:16 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 On 04/10/09 12:32 AM, marius d. wrote:



  Why not lift-core = (lift-common, lift-util, lift-json, lift-
  actor,lift-webkit) ?

 1. Initially, it didn't sound right to me (when we had lift-base,
 lift-util etc.).

 2. DavidP commented, that lift-core currently means everything Lift.
 and he thought we'd need another name.

 3. DavidB pointed out an old thread[a] and suggested that:

 lift-core == lift-full, but to be backward compatible with the time
 when there is one jar (lift-core), we keep the name.

 [a]http://groups.google.com/group/lift-committers/browse_thread/thread/2...

 Of these, #1 doesn't hold true anymore, thus nullified.

 Cheers, Indrajit



  Br's,
  Marius

  On Oct 3, 7:33 pm, Indrajit Raychaudhuriindraj...@gmail.com  wrote:
  On 02/10/09 6:25 PM, David Pollak wrote:

  On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri
  indraj...@gmail.commailto:indraj...@gmail.com  wrote:

       On Oct 2, 5:39 pm, David Pollakfeeder.of.the.be...@gmail.com
       mailto:feeder.of.the.be...@gmail.com  wrote:
          On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri
          indraj...@gmail.commailto:indraj...@gmail.comwrote:

            Folks,

            Following up from the previous round, I am summarizing what we
            discussed so far with an attempt to converge and move on to 
  impl.
            Would be keen to have feedback and possibly arrive at some
       resolution
            on the outstanding items. (Meaty stuff below the module 
  structure)

            liftweb

            - lift-core [H]
              - lift-base [J]
              - lift-util [J]
              - lift-actor
              - lift-json
              - lift-webkit [K]

            - lift-persistence
              - lift-mapper
              - lift-record
              - lift-jpa

            - lift-modules [L]
              - lift-testkit
              - lift-osgi
              - lift-wizard
              - lift-widgets
              - lift-machine
              - lift-textile
              - lift-facebook
              - lift-amqp
              - lift-xmpp
              - lift-openid
              - lift-oauth
              - lift-paypal
              - lift-jta

            - lift-archetypes
              - ...

            - lift-examples [M]
              - ...

            - lift-site

            - lift-resources [N]
              - lift-root-model
              - lift-site-skin
              - lift-installer
              - misc config resources (scaladoc, javadoc etc.)

            Resolved since:

            [A] lift-* prefix is fine/preferred for top level categories
       (dir_name
            == artifactId) [Heiko]

            [B] For Lift users not using Maven these *-all.jars will be
       valuable.
            Assembly preferred to meta [Heiko]

            [C] lift-testkit to move to lift-modules. Applications would 
  use it
            under 'test' scope. [David]

            [D] lift-json to be part of core [Marius]

            [E] lift-persistence being separated from lift-core into it's 
  own
            category and made optional [Marius]

            [F] No deep nesting within modules (no submodules) for now 
  [Heiko]

            [G] Presentations and docs to be in central repository for now
            [+1:David/Tim/Derek, +0:Indrajit, -1:Heiko/Viktor].
            Settling for central repo at the moment (a: least change, b: 
  in a
            hurry to converge, c: effect of living in largest democracy 
  in the
            world!).  Later on, I'll attempt to make this part of site
       build and
            make them more conveniently available.

            Outstanding since:

            [H] lift-core has to get a better and more appropriate name
       (and also
            to avoid confusion since lift-core == 'everything lift' at the
            moment).
                Starting with two that come to my mind.
                - lift-lite (Members of this category make up the 
  lightweight,
            minimalistic Lift distribution that would help you build a 
  Lift
       based
            application)
                - lift-genesis (Members of this category make up the 
  genesis of
            your Lift based application)
                - lift-mini (Minimal Lift distribution to get started 
  with Lift)
                - lift-minimal (Same as above)

          How about lift-web (the stuff you need to build a web 
  application)

       Hmm, lift-web vs lift-web/lift-webkit could add to confusion. Too 
  many
       combination of lift+web (liftweb.nethttp://liftweb.net, lift-web,
       lift-webkit) for
       comfort.

  okay.

  Now that lift-base is free for grab, I am settling for lift-base for
  lack of any other clear winner.

  So we have lift-base = (lift-common, lift-util, lift-json, lift-actor,
  lift-webkit)

  Feel free to comment in favor or 

[Lift] Re: 1.1-SNAPSHOT and Snippet problems?

2009-10-03 Thread Thomas Rampelberg

I thought that I'd just updated all the versions . from that stack
trace, how do you tell which version lift-util is?

On Sat, Oct 3, 2009 at 1:39 PM, marius d. marius.dan...@gmail.com wrote:

 What verions of lift are you using? It appears that lift-util is a
 different version than lift ?

 Br's,
 Marius

 On Oct 3, 11:11 pm, Thomas Rampelberg pyronic...@gmail.com wrote:
 I just synced up to main this morning and now whenever I try and use
 one of my snippets, I'm getting the traceback below. Any hints on what
 I'm doing wrong? The snippet in question is just the basic
 Util.in/Util.out that the tutorial has you write.

       div class=column span-17 last
         lift:Util.in
           lift:bind name=content /
         /lift:Util.in
         lift:Util.out
           h3 class=alt
             You must be logged in to view this content.
             lift:menu.item name=LoginLogin/lift:menu.item
           /h3
         /lift:Util.out
       /div

 class Util {
   def in(html: NodeSeq) =
     if (User.loggedIn_?) html else NodeSeq.Empty

   def out(html: NodeSeq) =
     if (!User.loggedIn_?) html else NodeSeq.Empty

 }

 Message: java.lang.AbstractMethodError:
 net.liftweb.util.Helpers$.tryo(Lscala/PartialFunction;Lscala/Function0;)Lnet/liftweb/util/Box;
         
 net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$instantiateOrRedirect(LiftSession.scala:862)
         
 net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1$$anonfun$apply$41.apply(LiftSession.scala:911)
         
 net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1$$anonfun$apply$41.apply(LiftSession.scala:911)
         net.liftweb.util.Full.flatMap(Box.scala:332)
         
 net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1.apply(LiftSession.scala:911)
         
 net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1.apply(LiftSession.scala:911)
         net.liftweb.util.EmptyBox.or(Box.scala:374)
         
 net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$findSnippetInstance(LiftSession.scala:910)
         
 net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1$$anonfun$17.apply(LiftSession.scala:967)
         
 net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1$$anonfun$17.apply(LiftSession.scala:967)
         net.liftweb.util.EmptyBox.or(Box.scala:374)
         
 net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1.apply(LiftSession.scala:967)
         
 net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1.apply(LiftSession.scala:966)
         net.liftweb.util.EmptyBox.or(Box.scala:374)
         
 net.liftweb.http.LiftSession.locateAndCacheSnippet$1(LiftSession.scala:966)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48$$anonfun$apply$50.apply(LiftSession.scala:978)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48$$anonfun$apply$50.apply(LiftSession.scala:976)
         net.liftweb.util.EmptyBox.openOr(Box.scala:372)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48.apply(LiftSession.scala:976)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48.apply(LiftSession.scala:976)
         net.liftweb.util.EmptyBox.openOr(Box.scala:372)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45.apply(LiftSession.scala:975)
         
 net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45.apply(LiftSession.scala:975)
         net.liftweb.http.S$.doSnippet(S.scala:1586)
         net.liftweb.http.LiftSession$$anonfun$18.apply(LiftSession.scala:973)
         net.liftweb.http.LiftSession$$anonfun$18.apply(LiftSession.scala:972)
         net.liftweb.util.Full.map(Box.scala:330)
         
 net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$processSnippet(LiftSession.scala:972)
         
 net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:1073)
         
 net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:1061)
         net.liftweb.util.NamedPF.apply(NamedPartialFunction.scala:30)
         net.liftweb.util.NamedPF$.apply(NamedPartialFunction.scala:76)
         
 net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58$$anonfun$apply$59.apply(LiftSession.scala:1094)
         
 net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58$$anonfun$apply$59.apply(LiftSession.scala:1094)
         net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)
         net.liftweb.http.S$.setVars(S.scala:1414)
         
 net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58.apply(LiftSession.scala:1093)
         
 

[Lift] Lift with JavaRebel, Jetty: Can I add views and/or modify Boot.scala without restarting Jetty?

2009-10-03 Thread Alex Black

I'm just getting started with Lift and Scala, and I'm excited about
using JavaRebel to avoid waiting to restart Jetty every time I make a
change.

It seems to be working well: I can see changes made to snippets for
example right away, I'm running mvn scala:cc: and I see it pick up
the changes.

However, if I add a new view say test2.html, then modify the sitemap
Boot.scala, I can't access test2 until I restart Jetty, even though I
saw that scala.cc picked up  the change and recompiled Boot.scala.

Should this be possible? Thanks!

- Alex

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



[Lift] Re: CometActor timeout problem

2009-10-03 Thread jack

Yes, I will send you this. In the mean time, could you at least tell
me how to reset the code. I.E. I would like that everytime you refresh
the page, it starts again.

On Oct 3, 12:47 am, Atsuhiko Yamanaka atsuhiko.yaman...@gmail.com
wrote:
 Hi,

 On Sat, Oct 3, 2009 at 1:05 PM, jack jack.wid...@gmail.com wrote:

  Atsuhiko,

  The way I have modified the code, each thread is returning its Package
  object at different times. But its seems the screen updates only when
  they all have completed. Could you tell me what piece of the code
  makes the screen update?

 Can you show your code?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---