[Lift] Re: Trouble getting lift up and running

[Mobbit]

Found the following command which solves the problem for me:

mvn archetype:generate -DarchetypeCatalog=http://scala-tools.org/

Would still be great to know what went wrong.

--~--~-~--~~~---~--~~
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

[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 
wrote:
> Hi,
>
> On Sat, Oct 3, 2009 at 1:05 PM, jack  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
-~--~~~~--~~--~--~---

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

[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: 1.1-SNAPSHOT and Snippet problems?

[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.  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  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.
>>
>>       
>>         
>>           
>>         
>>         
>>           
>>             You must be logged in to view this content.
>>             Login
>>           
>>         
>>       
>>
>> 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$

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

[marius d.]

Ok ... got it. Thanks.

On Oct 3, 10:16 pm, Indrajit Raychaudhuri  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 Raychaudhuri  wrote:
> >> On 02/10/09 6:25 PM, David Pollak wrote:
>
> >>> On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri
> >>> mailto:indraj...@gmail.com>>  wrote:
>
> >>>      On Oct 2, 5:39 pm, David Pollak >>>      >  wrote:
> >>>       >  On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri
> >>>       >  mailto:indraj...@gmail.com>>wrote:
>
> >>>       >  >  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 n

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

[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  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.
>
>       
>         
>           
>         
>         
>           
>             You must be logged in to view this content.
>             Login
>           
>         
>       
>
> 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.LiftSessi

[Lift] Trouble getting lift up and running

[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 
(org.mortbay.util.Resource)org.mortbay.jetty.Server 
(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] 1.1-SNAPSHOT and Snippet problems?

[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.

  

  


  
You must be logged in to view this content.
Login
  

  

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)

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

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

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

[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 Raychaudhuri  wrote:
>> On 02/10/09 6:25 PM, David Pollak wrote:
>>
>>
>>
>>
>>
>>> On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri
>>> mailto:indraj...@gmail.com>>  wrote:
>>
>>>  On Oct 2, 5:39 pm, David Pollak>>  >  wrote:
>>>   >  On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri
>>>   >  mailto:indraj...@gmail.com>>wrote:
>>
>>>   >  >  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, lift-web,
>>>  lift-webkit) for
>>>  comfort.
>>
>>

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

[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  wrote:
> On 02/10/09 6:25 PM, David Pollak wrote:
>
>
>
>
>
> > On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri
> > mailto:indraj...@gmail.com>> wrote:
>
> >     On Oct 2, 5:39 pm, David Pollak  >     > wrote:
> >      > On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri
> >      > mailto:indraj...@gmail.com>>wrote:
>
> >      > > 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 , 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
> >   

[Lift] Re: MappedStringForeignKey and Schemifier

[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  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: Extending Session Expiry

[Timothy Perrett]

OK, so first testing says that


   10


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  
>  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 > > 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: RFC: Restructuring Lift Codebase [Round 2]

[Indrajit Raychaudhuri]

On 02/10/09 6:25 PM, David Pollak wrote:
>
>
> On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri
> mailto:indraj...@gmail.com>> wrote:
>
>
>
>
> On Oct 2, 5:39 pm, David Pollak  > wrote:
>  > On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri
>  > mailto:indraj...@gmail.com>>wrote:
>  >
>  >
>  >
>  >
>  >
>  > > 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 , 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] Re: Lift compiled against 2.7.7.RC1

[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--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:




   
 
   scala277
   
 2.7.7.RC1
   
   
   
   net.liftweb
   lift-core
   1.1-scala2.7.7.RC1-SNAPSHOT
 
   
 
   





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: lift-json's extract and Mapper

[Kevin Wright]

On Sat, Oct 3, 2009 at 11:33 AM, Peter Robinett  wrote:
>
>
> On Oct 3, 12:04 pm, Kevin Wright 
> wrote:
>> On Sat, Oct 3, 2009 at 10:43 AM, Peter Robinett  
>> 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 
>> > 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  
>> >> 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

[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  wrote:

>
> harryh  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

[Peter Robinett]

On Oct 3, 12:04 pm, Kevin Wright 
wrote:
> On Sat, Oct 3, 2009 at 10:43 AM, Peter Robinett  
> 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 
> > 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  
> >> 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

[Kevin Wright]

On Sat, Oct 3, 2009 at 10:43 AM, Peter Robinett  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 
> 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  
>> 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] MappedStringForeignKey and Schemifier

[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: Started integrating lift in a scala+spring project. Feedback?

[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] Re: lift-json's extract and Mapper

[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 
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  
> 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

[Jeppe Nejsum Madsen]

harryh  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

[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
 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  
> 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

[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  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] lift-json's extract and Mapper

[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
-~--~~~~--~~--~--~---