[Lift] Re: Are we willing to make a breaking change for Joda Time?
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 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 > > 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 > > wrote: > > >> 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 -~--~~~~--~~--~--~---
[Lift] Bind with a map collection
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: Testing snippets that depend on a user logged in
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 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 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 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 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 =
> >> >
> >> >
> >> >
> >> > My Name
> >> >
> >> >
> >> > Fighter Style
> >> >
> >> >
> >> > Weight
> >> >
> >> >
> >> >
> >> > 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
> >> > 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 ses
[Lift] Re: Testing snippets that depend on a user logged in
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 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 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 =
> >
> >
> >
> > My Name
> >
> >
> > Fighter Style
> >
> >
> > Weight
> >
> >
> >
> > 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
> > 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
> > 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 =
> > >>
> > >>
> > >>
> > >> My Name
> > >>
> > >>
> > >> Fighter Style
> > >>
> > >>
> > >> Weight
> > >>
[Lift] Testing snippets that depend on a user logged in
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 =
My Name
Fighter Style
Weight
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: Mapper subclasses
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 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 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 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 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 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 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?
>
> > > > > > -
>
> > > > > > harryh 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] Re: Newbie Question design pattern for ORM in Lift
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 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
> wrote:
>
> > On Thu, Aug 27, 2009 at 10:26 AM, rstradling wrote:
>
> > > 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 wrote:
> > > > How do you auto-generate them?
>
> > > > On Thu, Aug 27, 2009 at 1:03 PM, rstradling
> > > 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
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
wrote:
> On Thu, Aug 27, 2009 at 10:26 AM, rstradling wrote:
>
>
>
> > 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 wrote:
> > > How do you auto-generate them?
>
> > > On Thu, Aug 27, 2009 at 1:03 PM, rstradling
> > 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
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 wrote:
> How do you auto-generate them?
>
> On Thu, Aug 27, 2009 at 1:03 PM, rstradling 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] Newbie Question design pattern for ORM in Lift
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
-~--~~~~--~~--~--~---
