Re: [Lift] Re: rest service

Hello, Thanks for your answers, I'll look into the suggestions. Best Regards Niels On Wed, Dec 9, 2009 at 11:17 PM, wstrange wrote: > > > You could look at Jersey. They have a user contributed module that > integrates with lift. > > > > On Dec 9, 7:43 am, Niels Boldt wrote: > > Hi, > > > > Wh

Re: [Lift] Re: Understanding SessionVars and Objects

On Wed, Dec 9, 2009 at 10:52 PM, johncch wrote: > Thanks for the explanation! > > > SessionVars are kind of like thread local variables. They have an > internal "name" (which is guaranteed to be unique and is maintained by Lift) > which is used to check in a dictionary the session keeps around wi

[Lift] Re: JS event source in a server side handler

I encountered the same problem and the only solution I found is the same as your's. But that doesn't seem to be the Lift way ;) Anyone knows? -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com.

Re: [Lift] New Lift release process wiki page

On Wed, Dec 9, 2009 at 11:30 PM, Heiko Seeberger < heiko.seeber...@googlemail.com> wrote: > David, > > I do not understand the naming convention "Lift_x_version". Is this > something like "Lift_x_2.0" or "Lift_2.0" or ...? > > git checkout -b Lift_x_version > > Maybe it is possible to find a bette

Re: [Lift] New Lift release process wiki page

2009/12/10 David Pollak > > On Wed, Dec 9, 2009 at 11:30 PM, Heiko Seeberger < > heiko.seeber...@googlemail.com> wrote: > >> David, >> >> I do not understand the naming convention "Lift_x_version". Is this >> something like "Lift_x_2.0" or "Lift_2.0" or ...? >> >> git checkout -b Lift_x_version >

Re: [Lift] Re: Welcome Peter Robinett to the Lift committers

Welcome Peter! I'm also looking forward to your flot improvements :) On Wed, Dec 9, 2009 at 11:32 PM, Marius wrote: > Welcome Peter !! > > On Dec 10, 12:08 am, David Pollak > wrote: > > Folks, > > > > Please join me in welcoming Peter Robinett to the Lift committers. > Peter's > > been active

Re: [Lift] Welcome Peter Robinett to the Lift committers

Welcome Peter! Keen to discover your bag of trick ;-) Cheers, Indrajit On 10/12/09 3:38 AM, David Pollak wrote: > Folks, > > Please join me in welcoming Peter Robinett to the Lift committers. > Peter's been active on the Lift list helping people and asking questions > (a great combo.) As Peter's

[Lift] SHtml.link should work like Shtml.submit

Hallo I have problem with SHtml.link. I want that it will work like SHtml.submit. And the question is how can I made this. Thanks for answer -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. T

Re: [Lift] SHtml.link should work like Shtml.submit

On Thu, Dec 10, 2009 at 7:54 AM, dominikgr wrote: > Hallo > I have problem with SHtml.link. I want that it will work like > SHtml.submit. And the question is how can I made this. Thanks for > answer > What do you mean "work like"? What does submit do that link doesn't? What kind of behavioral

[Lift] Re: SHtml.link should work like Shtml.submit

The easy answer would be something like (for non Ajax links): def link(body: NodeSeq, f: () => Unit): NodeSeq = { {body} } I haven't tested it but you get the idea ... However I think this would be a really nice addition to Shtml. I'll open a defect and add this ... unless someone sees reasons

Re: [Lift] Multi-Ćolumn MappedField

IMHO this doesn't sound like an ideal way to do this. At a high level what are you trying to do? Is this a legacy DB or starting from scratch? If I had to do something like this I would instead use something like MappedLongForeignKey so that you have a direct reference to the other tables instead o

[Lift] Re: Multi-Ćolumn MappedField

I believe David has said that having MappedPassword represent two columns is one of his great regrets, so watch out! ;-) Peter On Dec 10, 9:17 am, Derek Chen-Becker wrote: > IMHO this doesn't sound like an ideal way to do this. At a high level what > are you trying to do? Is this a legacy DB or

[Lift] Re: Welcome Peter Robinett to the Lift committers

Thanks, all! Beyond lift-flot, I will be taking a look at MegaProtoUser, oAuth and AMQP in the coming months. Of course, if people would like to direct my work, that's very welcome. Peter On Dec 10, 7:18 am, Indrajit Raychaudhuri wrote: > Welcome Peter! Keen to discover your bag of trick ;-) > >

Re: [Lift] Re: Multi-Ćolumn MappedField

On Thu, Dec 10, 2009 at 9:27 AM, Peter Robinett wrote: > I believe David has said that having MappedPassword represent two > columns is one of his great regrets, so watch out! ;-) > Yeah... it's the single worst design decision I made in Lift (and I've made a non-trivial number of bad decisions..

[Lift] Re: Multi-Ćolumn MappedField

I believe it's a bit more complicated than that. I made one platform where you register and login to a User (let's call it UserA). Then I made some sub-platforms, which all have their own type of User (so many different "UserB"). All of the user types inherit from "InstanceUser" and all UserB have

Re: [Lift] Re: Multi-Ćolumn MappedField

On Thu, Dec 10, 2009 at 10:00 AM, Joern wrote: > I believe it's a bit more complicated than that. I made one platform > where you register and login to a User (let's call it UserA). Then I > made some sub-platforms, which all have their own type of User (so > many different "UserB"). All of the u

[Lift] Re: Multi-Ćolumn MappedField

Ok, I'll try to describe it, since it's pretty dynamic... I have separated my application into several "instances" (i called those sub-platforms before). Every instance has its own database with, at least, a table called "instance_users", where it defines it own user type, with special information

Re: [Lift] Re: Multi-Ćolumn MappedField

On Thu, Dec 10, 2009 at 10:58 AM, Joern wrote: > Ok, I'll try to describe it, since it's pretty dynamic... > > > I have separated my application into several "instances" (i called > those sub-platforms before). Every instance has its own database with, > at least, a table called "instance_use

[Lift] jsonCall for clickable links

Hello, all. I'm sure this is an incredibly silly mistake on my part, but I've never really done AJAX until playing with Lift and am at a loss as to what's going wrong. I'm dusting off my old geolocation web app. My current goals are two-fold: set an initial position based on the browser, then g

[Lift] Re: Multi-Ćolumn MappedField

> Why do these fields have to be "taped together"?  What is "taped together"? > > Why not just create a method that takes a user and updates the correct > columns in the record? Sorry if "taped together" didn't make sense - I wanted to say that they belong together and should be seen as one Unit i

[Lift] Re: Managing templates with associated snippets?

Hi Ilya and David, My apologies for the vagueness, and thank you both for the interest in feedback. :) David, I have no particular ideas on the best practises applicable to other people - as I work in Wicket all day, I'd probably be happier with having all my snippets living next door to my classe

Re: [Lift] Foreign Key constraints are not created by schemify

What about that spec I threw together in a hurry implies that foreign keys would conflict with mapper? See a recent (few weeks ago) thread discussing how many-to-many should deal with broken joins. Why would one not want them to be created by default? P.S. Sorry I never made that ticket for H2 FK s

Re: [Lift] Foreign Key constraints are not created by schemify

If FKs are enabled then the spec fails because you're intentionally trying to break the joins by deleting the Companys that are on the other side of the many-to-many. I'm not sure that FKs should be enabled by default, but if I add the option to introduce them with schemify then I could write anoth

Re: [Lift] Re: Multi-Ćolumn MappedField

The business logic/interfaces on your Scala classes do not need to match the DB. For example: class MyFoo extends LongKeyedMapper[MyFoo] with IdPK { def getSingleton = MyFoo protected object name extends MappedString(this, 64) protected object age extends MappedInt(this) def info: (Stri

Re: [Lift] New Lift release process wiki page

Maybe I missed it, but it's probably desirable to tag the actual release point as well as create a branch, isn't it? Kris On Thu, Dec 10, 2009 at 7:47 AM, Heiko Seeberger wrote: > 2009/12/10 David Pollak >> >> On Wed, Dec 9, 2009 at 11:30 PM, Heiko Seeberger >> wrote: >>> >>> David, >>> I do n

Re: [Lift] New Lift release process wiki page

On Thu, Dec 10, 2009 at 3:45 PM, Kris Nuttycombe wrote: > Maybe I missed it, but it's probably desirable to tag the actual > release point as well as create a branch, isn't it? > In Git, it's the same thing. The creation of the branch is a marker at a particular commit... the same as a tag. The

[Lift] Re: Multi-Ćolumn MappedField

Joern, are you using MegaProtoUser? If so, I dramatically simplified our access control code by using the superUser property it provides, though I can't say whether that'd be useful for you. Also, what you describe kind of reminds me of App Engine's Expando models (http:// code.google.com/appengine

[Lift] lift-json and illegal field names

I feel like there has been a post on this before, but I can't seem to find it. How can I construct a case class that can deal with json like so: { "type" : "image" } since this won't work (as type is a scala keyword): case class Foo(type: String) -harryh -- You received this message becaus

Re: [Lift] lift-json and illegal field names

Backticks. - harryh wrote: I feel like there has been a post on this before, but I can't seem to find it. How can I construct a case class that can deal with json like so: { "type" : "image" } since this won't work (as type is a scala keyword): case class

Re: [Lift] lift-json and illegal field names

On Thu, Dec 10, 2009 at 4:14 PM, harryh wrote: > I feel like there has been a post on this before, but I can't seem to > find it. How can I construct a case class that can deal with json > like so: > > { > "type" : "image" > } > > since this won't work (as type is a scala keyword): > > case cla

Re: [Lift] lift-json and illegal field names

On Thursday December 10 2009, harryh wrote: > ... > > since this won't work (as type is a scala keyword): > > case class Foo(type: String) Back-ticks forgive all: case class Foo(`type`: String) > -harryh Randall Schulz -- You received this message because you are subscribed to the Google Gr

[Lift] Re: lift-json and illegal field names

Thx all! Just couldn't remember that little trick. -harryh -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.c

[Lift] Re: Lift compiles on Scala 2.8 and runs the demo

Will the 2.8 branch be in 1.1-m8? Best regards On Nov 23, 3:11 pm, David Bernard wrote: > I agree skipping test is BAD, but in the case of 2.8 for lift or when > running test is long and you need to run install (eg to check compilation on > a multi-module project). > > -Dtest=false less typing

Re: [Lift] Re: Lift compiles on Scala 2.8 and runs the demo

On Thu, Dec 10, 2009 at 6:39 PM, Franz Bettag wrote: > Will the 2.8 branch be in 1.1-m8? > No. Scala 2.8 has not even reached beta yet... there's no way I'd subject the folks who use milestones in production to a pre-beta version of Scala. The 2.8 stuff is on the 280_port branch in the GitHub

[Lift] M8 delay

Folks, We're having a Nexus problem on scala-tools.org and the M8 release that was built today is delayed. Sorry. 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 harmonic

Re: [Lift] New Lift release process wiki page

Right, but the moment another commit goes on the branch you no longer can see exactly where the release was cut from. Thus it's best to both branch and tag. In git a branch is a mutable reference to a commit whereas a tag is immutable. That way you can do bugfixes on the release branch and diff aga

Re: [Lift] New Lift release process wiki page

On Thu, Dec 10, 2009 at 8:18 PM, Kris Nuttycombe wrote: > Right, but the moment another commit goes on the branch you no longer can > see exactly where the release was cut from. Thus it's best to both branch > and tag. In git a branch is a mutable reference to a commit whereas a tag is > immutable

Re: [Lift] New Lift release process wiki page

On 11/12/09 9:48 AM, Kris Nuttycombe wrote: > Right, but the moment another commit goes on the branch you no longer > can see exactly where the release was cut from. Thus it's best to both > branch and tag. In git a branch is a mutable reference to a commit > whereas a tag is immutable. That way

Re: [Lift] Open discussion on Lift Name Calling practices

Dates have changed below. I slipped everything a week. On Wed, Dec 9, 2009 at 11:59 PM, Kris Nuttycombe wrote: > On Tue, Dec 1, 2009 at 1:43 PM, Jim Barrows wrote: > > Lift is getting very large. We've got singular names as lists, and > plural > > names that aren't lists. We've got people cal

[Lift] The thread for discussing names that need to change.

And we can start with Kris's list! Which hopefully will start things off nicely. If any particular discussion starts getting long, I, or the discussers should move it to it's own thread. module: lift-util file: src/main/scala/net/liftweb/util/JsonCmd.scala ResponseInfoHolder => ResponseMetadata

Re: [Lift] The thread for discussing names that need to change.

Until we finish one part of the process, let's not jump to the next part, this only serves to cut off comments that other may have as part of the prior discussion. Further, having all this stuff strewn through an email thread is going to make it very difficult to consume. I would strongly prefer

Re: [Lift] New Lift release process wiki page

On Thu, Dec 10, 2009 at 9:26 PM, Indrajit Raychaudhuri wrote: > > > On 11/12/09 9:48 AM, Kris Nuttycombe wrote: >> Right, but the moment another commit goes on the branch you no longer >> can see exactly where the release was cut from. Thus it's best to both >> branch and tag. In git a branch is a

Re: [Lift] New Lift release process wiki page

Nice Kris Nuttycombe wrote: > On Thu, Dec 10, 2009 at 9:26 PM, Indrajit Raychaudhuri > wrote: > >> On 11/12/09 9:48 AM, Kris Nuttycombe wrote: >> >>> Right, but the moment another commit goes on the branch you no longer >>> can see exactly where the release was cut from. Thus it's best to

Re: [Lift] New Lift release process wiki page

On 11/12/09 11:25 AM, Kris Nuttycombe wrote: > On Thu, Dec 10, 2009 at 9:26 PM, Indrajit Raychaudhuri > wrote: >> >> >> On 11/12/09 9:48 AM, Kris Nuttycombe wrote: >>> Right, but the moment another commit goes on the branch you no longer >>> can see exactly where the release was cut from. Thus

[Lift] Re: Welcome Peter Robinett to the Lift committers

Congrats! On Dec 10, 11:40 am, Peter Robinett wrote: > Thanks, all! Beyond lift-flot, I will be taking a look at > MegaProtoUser, oAuth and AMQP in the coming months. Of course, if > people would like to direct my work, that's very welcome. > > Peter > > On Dec 10, 7:18 am, Indrajit Raychaudhuri

Re: [Lift] Re: Lift and LDAP

I write a CAS SSO proxy, it's so easy if anyone read this article and It's java way for lack of IO in Scala. On Tue, Dec 1, 2009 at 9:18 AM, Xuefeng Wu wrote: > Thank you for your reply and I will try. > > > On Mon, Nov 30, 2009 at 6