[Lift] Newbie Question design pattern for ORM in Lift

2009-08-27 Thread rstradling

I am using Lift 1.0 with the Mapper ORM module from Lift. I am a
newbie to Scala and Lift.  I have auto-generated my ORM classes from
a .sql file.  Given that these classes are auto-generated I would
prefer not to edit them directly and provide additional functionality
via inheritance.

Say I have the following...
class StatGenerated extends LongKeyedMapper[StatGenerated] with IdPK {
   def getSingleton = StatGenerated
   object errors extends MappedLong(this)
   object hits extends MappedLong(this)
   object AB extends MappedLong(this)
}

object StatGenerated extends StatGenerated with LongKeyedMetaMapper
[StatGenerated] {
   override def fieldOrder = List(errors, hits)
}

class Statistics extends StatGenerated {
   def GetBattingAverage(id : Long) : float = {
val stat = Stat.findByKey(id)
stat.hits/stat.AB
   }
}


Now what I would like to do is work with the Statistics class as my
ORM object...
But I believe everything that is ORM related is actually of type
StatGenerated rather than Statistics.  i.e. findByKey will return me a
StatGenerated rather than a Statistics class.  Is there any clever way
around this that I am missing without either modifying the generated
class or duplicating 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] Re: Newbie Question design pattern for ORM in Lift

2009-08-27 Thread rstradling

With a parser combinator I wrote to parse .sql and it outputs scala
orm files.  Please note it is very specific to my needs (i.e. only
works with certain grammars (INSERTS) but that particular grammar is
all I needed to process at the time) but is written in a way that
could be extended to the full grammar (at least that was my
intent :)..


On Aug 27, 1:09 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 How do you auto-generate them?

 On Thu, Aug 27, 2009 at 1:03 PM, rstradling ryanstradl...@gmail.com wrote:

  I am using Lift 1.0 with the Mapper ORM module from Lift. I am a
  newbie to Scala and Lift.  I have auto-generated my ORM classes from
  a .sql file.  Given that these classes are auto-generated I would
  prefer not to edit them directly and provide additional functionality
  via inheritance.

  Say I have the following...
  class StatGenerated extends LongKeyedMapper[StatGenerated] with IdPK {
    def getSingleton = StatGenerated
    object errors extends MappedLong(this)
    object hits extends MappedLong(this)
    object AB extends MappedLong(this)
  }

  object StatGenerated extends StatGenerated with LongKeyedMetaMapper
  [StatGenerated] {
    override def fieldOrder = List(errors, hits)
  }

  class Statistics extends StatGenerated {
    def GetBattingAverage(id : Long) : float = {
                 val stat = Stat.findByKey(id)
                 stat.hits/stat.AB
    }
  }

  Now what I would like to do is work with the Statistics class as my
  ORM object...
  But I believe everything that is ORM related is actually of type
  StatGenerated rather than Statistics.  i.e. findByKey will return me a
  StatGenerated rather than a Statistics class.  Is there any clever way
  around this that I am missing without either modifying the generated
  class or duplicating 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] Re: Newbie Question design pattern for ORM in Lift

2009-08-27 Thread rstradling

Thanks for the answers everyone.  What David hit upon about wanting
objects to be subclassible is the conclusion I came to that would
work..if it existed.  I was hoping there was a way. :(.  Well, I guess
Naftoli has provided a possible solution but seems more involved than
I have the experience for.

I will resort to putting the stuff on the generated classes and let
merge tools do the rest.

Regarding sharing the codeI should be more specific in that it
parses ddl.  To be honest, I hope you all are not hoping for
muchbut I will get it up on github and when I do will reply to
this thread with the location.


On Aug 27, 1:35 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Thu, Aug 27, 2009 at 10:26 AM, rstradling ryanstradl...@gmail.comwrote:



  With a parser combinator I wrote to parse .sql and it outputs scala
  orm files.

 Care to share?  That'd be a pretty darned useful utility!

  Please note it is very specific to my needs (i.e. only
  works with certain grammars (INSERTS) but that particular grammar is
  all I needed to process at the time) but is written in a way that
  could be extended to the full grammar (at least that was my
  intent :)..

 So... the problem is that objects in Scala are not subclassible.  What does
 this mean?  For example:

 trait Foo {
   object bar extends AnyRef

 }

 trait MyFoo extends Foo {
   override object bar {
     def cantDoIt = sigh
   }

 }

 Back in the Scala 2.5 days, there was some talk about allowing this to
 happen, but it never did.  So, unfortunately, I can't think of a way for
 your sql generator to create a superclass that could be subclassed and have
 the effect that you want.

 Sorry/





  On Aug 27, 1:09 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
   How do you auto-generate them?

   On Thu, Aug 27, 2009 at 1:03 PM, rstradling ryanstradl...@gmail.com
  wrote:

I am using Lift 1.0 with the Mapper ORM module from Lift. I am a
newbie to Scala and Lift.  I have auto-generated my ORM classes from
a .sql file.  Given that these classes are auto-generated I would
prefer not to edit them directly and provide additional functionality
via inheritance.

Say I have the following...
class StatGenerated extends LongKeyedMapper[StatGenerated] with IdPK {
  def getSingleton = StatGenerated
  object errors extends MappedLong(this)
  object hits extends MappedLong(this)
  object AB extends MappedLong(this)
}

object StatGenerated extends StatGenerated with LongKeyedMetaMapper
[StatGenerated] {
  override def fieldOrder = List(errors, hits)
}

class Statistics extends StatGenerated {
  def GetBattingAverage(id : Long) : float = {
               val stat = Stat.findByKey(id)
               stat.hits/stat.AB
  }
}

Now what I would like to do is work with the Statistics class as my
ORM object...
But I believe everything that is ORM related is actually of type
StatGenerated rather than Statistics.  i.e. findByKey will return me a
StatGenerated rather than a Statistics class.  Is there any clever way
around this that I am missing without either modifying the generated
class or duplicating code?

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning Scalahttp://www.apress.com/book/view/1430219890
 Follow me:http://twitter.com/dpp
 Git some:http://github.com/dpp

--~--~-~--~~~---~--~~
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: Newbie Question design pattern for ORM in Lift

2009-08-27 Thread rstradling

git clone git://github.com/rstradling/DDLtoLiftORM.git  is the
location of the git code.

http://github.com/rstradling/DDLtoLiftORM is the web address

I hope this is helpful to others.

On Aug 27, 3:13 pm, rstradling ryanstradl...@gmail.com wrote:
 Thanks for the answers everyone.  What David hit upon about wanting
 objects to be subclassible is the conclusion I came to that would
 work..if it existed.  I was hoping there was a way. :(.  Well, I guess
 Naftoli has provided a possible solution but seems more involved than
 I have the experience for.

 I will resort to putting the stuff on the generated classes and let
 merge tools do the rest.

 Regarding sharing the codeI should be more specific in that it
 parses ddl.  To be honest, I hope you all are not hoping for
 muchbut I will get it up on github and when I do will reply to
 this thread with the location.

 On Aug 27, 1:35 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:

  On Thu, Aug 27, 2009 at 10:26 AM, rstradling ryanstradl...@gmail.comwrote:

   With a parser combinator I wrote to parse .sql and it outputs scala
   orm files.

  Care to share?  That'd be a pretty darned useful utility!

   Please note it is very specific to my needs (i.e. only
   works with certain grammars (INSERTS) but that particular grammar is
   all I needed to process at the time) but is written in a way that
   could be extended to the full grammar (at least that was my
   intent :)..

  So... the problem is that objects in Scala are not subclassible.  What does
  this mean?  For example:

  trait Foo {
    object bar extends AnyRef

  }

  trait MyFoo extends Foo {
    override object bar {
      def cantDoIt = sigh
    }

  }

  Back in the Scala 2.5 days, there was some talk about allowing this to
  happen, but it never did.  So, unfortunately, I can't think of a way for
  your sql generator to create a superclass that could be subclassed and have
  the effect that you want.

  Sorry/

   On Aug 27, 1:09 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
How do you auto-generate them?

On Thu, Aug 27, 2009 at 1:03 PM, rstradling ryanstradl...@gmail.com
   wrote:

 I am using Lift 1.0 with the Mapper ORM module from Lift. I am a
 newbie to Scala and Lift.  I have auto-generated my ORM classes from
 a .sql file.  Given that these classes are auto-generated I would
 prefer not to edit them directly and provide additional functionality
 via inheritance.

 Say I have the following...
 class StatGenerated extends LongKeyedMapper[StatGenerated] with IdPK {
   def getSingleton = StatGenerated
   object errors extends MappedLong(this)
   object hits extends MappedLong(this)
   object AB extends MappedLong(this)
 }

 object StatGenerated extends StatGenerated with LongKeyedMetaMapper
 [StatGenerated] {
   override def fieldOrder = List(errors, hits)
 }

 class Statistics extends StatGenerated {
   def GetBattingAverage(id : Long) : float = {
                val stat = Stat.findByKey(id)
                stat.hits/stat.AB
   }
 }

 Now what I would like to do is work with the Statistics class as my
 ORM object...
 But I believe everything that is ORM related is actually of type
 StatGenerated rather than Statistics.  i.e. findByKey will return me a
 StatGenerated rather than a Statistics class.  Is there any clever way
 around this that I am missing without either modifying the generated
 class or duplicating code?

  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Git some:http://github.com/dpp

--~--~-~--~~~---~--~~
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: Mapper subclasses

2009-09-08 Thread rstradling

I am trying to do what is mentioned below but am struggling with the
object side of things for my particular case.  This all relates back
to trying to auto-generate some classes that I posted back a while ago
on.  I would love to generate 1 file that has the trait and the object
in it that I then inherit from in my sub-class and object sub-class in
another file.

Autogenerated.scala
trait FC[MapperType : FC[MapperType]] extends Mapper[MapperType] {
   self: MapperType =
   object today extends MappedLong(this)
}

trait FCObj extends FC[MapperType] with LongKeyedMetaMapper[FC
[MapperType]] {
  override def fieldOrder = List(today)
}

In UserClass.scala
class FC_Wrapper extends LongKeyedMapper[FC_Wrapper] with IdPK with FC
[Wrapper] {
   def getSingleton = FCObj_Wrapper
   // define methods
}

object FCObj_Wrapper extends FCObj {
  // define auxiliary functionality

}

I know that the FCObj and FCObj_Wrapper is not correct syntax wise.
But the basic idea is that I want to have my autogeneration generate
the boilerplate code for me in a separate file.  This boilerplate
would ideally include the class and object related stuff.  Then in a
file that won't be stomped upon the next time I run the generator I
inherit from these objects.  I hope this makes sense.

I admit to not totally understanding the templated/generic programming
that is happening.




On Sep 3, 1:33 pm, glenn gl...@exmbly.com wrote:
 Isn't this really a matter of type casting, and asInstanceOf is just
 Scala's
 way of doing this. It's always best if you don't have to downcast your
 objects, but sometimes its unavoidable.

 Glenn...

 On Sep 3, 10:29 am, glenn gl...@exmbly.com wrote:

  I'm not sure of what the exact problem is. I created an Address trait
  that
  I couple with a number of mapper classes.

  trait Address[OwnerType : KeyedMapper[Long, OwnerType]]{

    def owner = this.asInstanceOf[OwnerType]

  

  Where exactly does this construct break down?

  Glenn...

  On Sep 3, 7:55 am, Giuseppe Fogliazza g.foglia...@mcmspa.it wrote:

   jon suggested to me the way to avoid both explicit type parameter and
   asinstance of:
   trait Timestamp[MapperType : TimeStamp[MapperType]] extends Mapper
   [MapperType] {
  self:MapperType =
   object xdatetime extends MappedDateTime(this)

     // all sorts of utility functions for dealing with timestamps

   }

   Thanks jon I have improved model in my application with this approach.

   Giuseppe

   On 3 Set, 16:16, Giuseppe Fogliazza g.foglia...@mcmspa.it wrote:

As an alternative to asInstanceOf you could use explicit type
parameter in MappedField creation:
   self:MapperType =
object xdatetime extends MappedDateTime[MapperType](this)

On 3 Set, 09:19, Giuseppe Fogliazza g.foglia...@mcmspa.it wrote:

 Unfortunately you cannot escape from asInstanceOf . Forcing
self:MapperType the type of this will be TimeStamp with MapperType
 violating the constraint for the type of the first parameter of
 MappedDateTime :T : Mapper[T].

 Regards
 Giuseppe

 On 3 Set, 07:08, Naftoli Gugenheim naftoli...@gmail.com wrote:

  So I guess you can't escape the asInstanceOf. Can you successfully 
  give the trait aself-type of this: MapperType =, or declare it to 
  extend Mapper[MapperType], without running into problems elsewhere?

  -

  harryhhar...@gmail.com wrote:

  I've been handling this with traits, for example I have something 
  like
  so:

  trait Timestamp[MapperType : Mapper[MapperType]] {
    object xdatetime extends 
  MappedDateTime[MapperType](this.asInstanceOf
  [MapperType])

    // all sorts of utility functions for dealing with timestamps

  }

  Then I can do

  class Foo extends LongKeyedMapper[Foo] with IdPK with 
  Timestamp[Foo] {
    // additional fields that are Foo specific

  }

  I have quite a few traits similar to Timestamp at this point
  corresponding to various fields that appear in lots of different
  tables in my application.

  -harryh

--~--~-~--~~~---~--~~
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] Testing snippets that depend on a user logged in

2009-10-01 Thread rstradling

I have a class called
class Trainer {
   def showPeople(xhtml : Group) : NodeSeq = {
  val user : User = User.currentUser.open_!
  ...
   }
}

I then want to write a unit test to test that returns proper xml.

The test is written as so
  def testValue() = {
val xml =
xml:group
  tr
  td
  p:fullNameMy Name/p:fullName
  /td
  td
  p:styleFighter Style/p:style
  /td
  td
  p:weightWeight/p:weight
  /td
  /tr
/xml:group
val trainer = new Trainer()
val output = trainer.showPeople(xml)
()
  }

The User object inherits from MegaProtoUser.

The problem is I am not sure how to create a mock user and sign them
in.
I have tried in my unit test
override def setUp : Unit = {
   val user = User.create
   user.firstName(XXX)
   user.lastName(YYY)
   user.save
   User.logUserIn(user)
}

The mock user log-in *seems* to work fine but when
User.currentUser.open_! is called it throws an exception on trying to
open an empty box.

So either how do I do this or how do others do this type of testing.
I am sure I am missing something simple.

Thanks,
ryan





--~--~-~--~~~---~--~~
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: Testing snippets that depend on a user logged in

2009-10-01 Thread rstradling

Awesome!!! Thanks guys for the help.  It now works.

I put a how-to wiki document up on github.  For me this was one of
those times where my google searches did not seem to turn up anything
fruitful, so I thought this how-to would be helpful.  If it is not
helpful, then no hard feelings if the page is deleted.  I just wanted
to give back.

Wiki page
http://wiki.github.com/dpp/liftweb/how-to-unit-test-lift-snippets-with-a-logged-in-user




On Oct 1, 4:53 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
 Bill,
 Thanks for posting this.  I am, by experience (I started using it, I can use
 it enough to write basic tests, I know no more) using Specs.  I would
 welcome and encourage some sample tests in Lift archetypes that use
 ScalaTest.  I want to make sure that folks who pick up Lift get to
 experience ScalaTest as well as Specs... that way, folks who have a better
 understanding of tests can make better choices.

 Thanks,

 David



 On Thu, Oct 1, 2009 at 1:27 PM, Bill Venners b...@artima.com wrote:

  Hi Ryan,

  It looks like you're currently using a JUnit TestCase. If you want an
  easier port to something that would work you could use a ScalaTest
  Suite like this:

  import org.scalatest.Suite

  class YourSuite extends Suite {

   val session = new LiftSession(, randomString(20), Empty)
   val stableTime = now

    override def withFixture(test: NoArgTest) {

     S.initIfUninitted(session) {
        val user = User.create
       user.firstName(XXX)
       user.lastName(YYY)
       user.save
       User.logUserIn(user)
        test()
      }
   }

   def testValue() {
    val xml =
        xml:group
          tr
              td
                  p:fullNameMy Name/p:fullName
              /td
              td
                  p:styleFighter Style/p:style
              /td
              td
                  p:weightWeight/p:weight
              /td
          /tr
        /xml:group
     val trainer = new Trainer()
     val output = trainer.showPeople(xml)
      // seems like you need an assertion here...
   }
  }

  A Suite considers methods that start with test as tests, like JUnit
  3, except they don't need to result in Unit so you don't need an extra
  () at the end. The withFixture method is an alternative to
  beforeEach/afterEach, which are like JUnit 3's setUp/tearDown methods.
  Each test gets passed as a function to withFixture, which is
  responsible for executing the test by invoking the function. In this
  case, it is executed in the context created by S. initIfUninitted.
  This is ScalaTest 1.0, which is available as a SNAPSHOT right now but
  should be released proper a week from Monday.

 http://www.artima.com/scalatest

  Bill

  On Thu, Oct 1, 2009 at 9:50 AM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
   Using Specs 1.6:

   object HelloWorldTestSpecs extends Specification {
     val session = new LiftSession(, randomString(20), Empty)
     val stableTime = now
     override def executeExpectations(ex: Examples, t: =Any): Any = {
       S.initIfUninitted(session) {
         ... put your User init here.  The User.logUserIn will be within the
   context of a session and thus session (and request) vars will be valid
       }
     }
     HelloWorld Snippet should {
       Put the time in the node in {
         ... do testing here
       }
     }
   }

   Hope this helps.
   On Thu, Oct 1, 2009 at 8:55 AM, rstradling ryanstradl...@gmail.com
  wrote:

   I have a class called
   class Trainer {
     def showPeople(xhtml : Group) : NodeSeq = {
        val user : User = User.currentUser.open_!
        ...
     }
   }

   I then want to write a unit test to test that returns proper xml.

   The test is written as so
    def testValue() = {
      val xml =
          xml:group
            tr
                td
                    p:fullNameMy Name/p:fullName
                /td
                td
                    p:styleFighter Style/p:style
                /td
                td
                    p:weightWeight/p:weight
                /td
            /tr
          /xml:group
      val trainer = new Trainer()
      val output = trainer.showPeople(xml)
      ()
    }

   The User object inherits from MegaProtoUser.

   The problem is I am not sure how to create a mock user and sign them
   in.
   I have tried in my unit test
   override def setUp : Unit = {
     val user = User.create
     user.firstName(XXX)
     user.lastName(YYY)
     user.save
     User.logUserIn(user)
   }

   The mock user log-in *seems* to work fine but when
   User.currentUser.open_! is called it throws an exception on trying to
   open an empty box.

   So either how do I do this or how do others do this type of testing.
   I am sure I am missing something simple.

   Thanks,
   ryan

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

  --
  Bill Venners

[Lift] Re: Testing snippets that depend on a user logged in

2009-10-02 Thread rstradling

Sweet!!! Thanks Bill for adding a ScalaTest version.  I wanted to but
just did not find the time yesterday. I also don't know ScalaTest very
well but will be working with it shortly.

On Oct 2, 12:37 am, Bill Venners b...@artima.com wrote:
 Hi Ryan, David, Eric,

 I added a ScalaTest version to your wiki page:

 http://wiki.github.com/dpp/liftweb/how-to-unit-test-lift-snippets-wit...

 Eric you may want to add a specs version.

 Bill



 On Thu, Oct 1, 2009 at 3:03 PM, rstradling ryanstradl...@gmail.com wrote:

  Awesome!!! Thanks guys for the help.  It now works.

  I put a how-to wiki document up on github.  For me this was one of
  those times where my google searches did not seem to turn up anything
  fruitful, so I thought this how-to would be helpful.  If it is not
  helpful, then no hard feelings if the page is deleted.  I just wanted
  to give back.

  Wiki page
 http://wiki.github.com/dpp/liftweb/how-to-unit-test-lift-snippets-wit...

  On Oct 1, 4:53 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
  Bill,
  Thanks for posting this.  I am, by experience (I started using it, I can 
  use
  it enough to write basic tests, I know no more) using Specs.  I would
  welcome and encourage some sample tests in Lift archetypes that use
  ScalaTest.  I want to make sure that folks who pick up Lift get to
  experience ScalaTest as well as Specs... that way, folks who have a better
  understanding of tests can make better choices.

  Thanks,

  David

  On Thu, Oct 1, 2009 at 1:27 PM, Bill Venners b...@artima.com wrote:

   Hi Ryan,

   It looks like you're currently using a JUnit TestCase. If you want an
   easier port to something that would work you could use a ScalaTest
   Suite like this:

   import org.scalatest.Suite

   class YourSuite extends Suite {

    val session = new LiftSession(, randomString(20), Empty)
    val stableTime = now

     override def withFixture(test: NoArgTest) {

      S.initIfUninitted(session) {
         val user = User.create
        user.firstName(XXX)
        user.lastName(YYY)
        user.save
        User.logUserIn(user)
         test()
       }
    }

    def testValue() {
     val xml =
         xml:group
           tr
               td
                   p:fullNameMy Name/p:fullName
               /td
               td
                   p:styleFighter Style/p:style
               /td
               td
                   p:weightWeight/p:weight
               /td
           /tr
         /xml:group
      val trainer = new Trainer()
      val output = trainer.showPeople(xml)
       // seems like you need an assertion here...
    }
   }

   A Suite considers methods that start with test as tests, like JUnit
   3, except they don't need to result in Unit so you don't need an extra
   () at the end. The withFixture method is an alternative to
   beforeEach/afterEach, which are like JUnit 3's setUp/tearDown methods.
   Each test gets passed as a function to withFixture, which is
   responsible for executing the test by invoking the function. In this
   case, it is executed in the context created by S. initIfUninitted.
   This is ScalaTest 1.0, which is available as a SNAPSHOT right now but
   should be released proper a week from Monday.

  http://www.artima.com/scalatest

   Bill

   On Thu, Oct 1, 2009 at 9:50 AM, David Pollak
   feeder.of.the.be...@gmail.com wrote:
Using Specs 1.6:

object HelloWorldTestSpecs extends Specification {
  val session = new LiftSession(, randomString(20), Empty)
  val stableTime = now
  override def executeExpectations(ex: Examples, t: =Any): Any = {
    S.initIfUninitted(session) {
      ... put your User init here.  The User.logUserIn will be within 
the
context of a session and thus session (and request) vars will be valid
    }
  }
  HelloWorld Snippet should {
    Put the time in the node in {
      ... do testing here
    }
  }
}

Hope this helps.
On Thu, Oct 1, 2009 at 8:55 AM, rstradling ryanstradl...@gmail.com
   wrote:

I have a class called
class Trainer {
  def showPeople(xhtml : Group) : NodeSeq = {
     val user : User = User.currentUser.open_!
     ...
  }
}

I then want to write a unit test to test that returns proper xml.

The test is written as so
 def testValue() = {
   val xml =
       xml:group
         tr
             td
                 p:fullNameMy Name/p:fullName
             /td
             td
                 p:styleFighter Style/p:style
             /td
             td
                 p:weightWeight/p:weight
             /td
         /tr
       /xml:group
   val trainer = new Trainer()
   val output = trainer.showPeople(xml)
   ()
 }

The User object inherits from MegaProtoUser.

The problem is I am not sure how to create a mock user and sign them
in.
I have tried in my unit test
override def setUp

[Lift] Bind with a map collection

2009-10-06 Thread rstradling

Hello everyone,
I have the following code...
case class item(name : String)
class demo {
  def exampleFour(xhtml : NodeSeq) : NodeSeq = {
val map = Map(Test - List(item(1), item(2), item(3)),
  Vehicles - List(item(Bike), item(Automobile))
  )
val articles = List(
article(A bunch of text, List(tag(Health),
tag(Hurt))),
article(BODY, List(tag(Coming)))
)
map.flatMap(a = bind(a, xhtml,
  body - Text(a._1),
  tags - a._2.flatMap(t =
bind(t, chooseTemplate(tag, list, xhtml),
  name - Text(t.name))
)
  )
)
  }
}

And I get this error message...
C:\Java\helloworld\src\main\scala\demo\helloworld\snippet\demo.scala:
46: error: type mismatch;
 found   : Iterable[scala.xml.Node]
 required: scala.xml.NodeSeq
map.flatMap(a = bind(a, xhtml,
^
one error found

I am not sure how to get around this.  I realize I have different
types but am not sure how they are related and how to convert one to
the other.  I googled for some answers and found stuff related to
Scala 2.8 but am not sure that applies to my situation.

I am using Scala 2.7.5 and Lift 1.1-M5.

Thanks for the help.
--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread rstradling

Take my input or vote of confidence with a grain of salt...
 I had to use java.util.Calendar recently and noticed some of the
issues with it that you mention.  For my case, I created a light
wrapper for my use of java.util.Calendar that redefined the relevant
statics (Monday, Tuesday, etc) as Scala enumerations and then
provided some implicit conversions to go from DayOfWeek.Monday to
java.util.Calendar.Monday.  My hope is that client code never knows
that they are using java.util.Calendar and that they will also get
some level of type-safety by using my wrapper.


In summary, I do not like the design of java.util.Calendar because of
its inconsistencies and think that creating a more consistent way of
doing things is a good thing.





On Oct 18, 10:58 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
 OK, I've run into an issue that makes me really uncomfortable.
 java.util.Calender is generally 1-based for fields, except for month of
 year, which is zero-based. This inconsistency has bled through to the
 TimeHelpers API. I can't just change this, because that would break a lot of
 code, possibly at runtime. What I would like to do is make a corresponding
 set of field accessor methods (day, month, year) in the JodaTimeHelpers
 trait that behave just like TimeHelpers, and then I'm building an extender
 class that will wrap a DateTime to provide functionality very similar to
 what Scala Time does (it's mostly pretty simple). The other inconsistency in
 the API is that some fields are UTC relative (day, month, year), but others
 aren't (currentYear). To address this, I would like to make all of my
 extender class methods use the local timezone, and provide a utc method that
 will return an extender relative to UTC. That way you could do things like:

 now.days // day of month relative to local timezone
 now.utc.days // day of month relative to UTC

 Thoughts?

 Derek

 On Thu, Oct 15, 2009 at 5:18 PM, David Pollak feeder.of.the.be...@gmail.com

  wrote:
  I'd prefer not the break the apis without deprecating them first

  On Thu, Oct 15, 2009 at 4:09 PM, Derek Chen-Becker 
  dchenbec...@gmail.comwrote:

  Just asking, since I'm looking at bolting a lot of java.util.Date methods
  onto the innards of TimeHelpers so that the specs pass.

  Derek

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