[Lift] Re: Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields

Excellent work Ross ! On Feb 12, 6:49 am, Ross Mellgren wrote: > I just committed a change to lift-record in 2.0-SNAPSHOT that will possibly > (probably?) break your build if you use it. > > This change makes it possible to have any record field be optional -- that > is, Box[MyType]. You use it

Re: [Lift] Re: Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields

Originally I had implemented this like you suggest, with separate field types. Marius reviewed it and preferred it to be baked into the basic field type. The advantages over that method are: - Not requiring 2x the number of field types everywhere. For example any record implementation that exte

[Lift] Re: Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields

What is the advantage of doing it this way as opposed to having a collection of Field types who's value is a Box[Whatever] (OptionalStringField, OptionalLongField, etc). I'm finding the e-mail you sent to the list moderately confusing. Maybe it's just that more explanation is needed? -harryh On

Re: [Lift] Re: **BREAKING CHANGES**: Use "mvn archetype:generate" to generate 1.1-SNAPSHOT archetypes

Hello Joseph, Archetype list is picked up from the archetype catalog [1]. This is controlled by the parameter 'archetypeCatalog' when you invoke the goal 'archetype:generate' (defaults to 'internal,local') [2]. Thus, what you see by default is the internal list that is picked up from archetype

[Lift] Re: **BREAKING CHANGES**: Use "mvn archetype:generate" to generate 1.1-SNAPSHOT archetypes

Hello Indrajitr, When using archetype:generate without the command line args, why does it not build the latest release of the archetype? I saw that 1.1-M8 is in central but the version it builds uses lift-core 0.8. I'm not 100% on how it chooses the archetype version from the normal selection men

Re: [Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Tue, Nov 17, 2009 at 7:30 AM, Kris Nuttycombe wrote: > On Tue, Nov 17, 2009 at 7:37 AM, Jeppe Nejsum Madsen > wrote: > > On Nov 17, 12:11 am, David Pollak > > wrote: > >> On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe > >> wrote: > >> > >> > >> > >> > >> > >> > On Mon, Nov 16, 2009 at 4:02

Re: [Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Tue, Nov 17, 2009 at 7:37 AM, Jeppe Nejsum Madsen wrote: > On Nov 17, 12:11 am, David Pollak > wrote: >> On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe >> wrote: >> >> >> >> >> >> > On Mon, Nov 16, 2009 at 4:02 PM, David Pollak >> > wrote: >> >> > > On Mon, Nov 16, 2009 at 2:20 PM, Kris Nut

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Nov 17, 3:37 pm, Jeppe Nejsum Madsen wrote: > On Nov 17, 12:11 am, David Pollak > wrote: [...] > Did this ever get resolved? I'm still seeing this after an update to > latest. This is pretty major, so I looked into it and found this: > > 1) The Template LocParam defined on loginMenuLoc is

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Nov 17, 12:11 am, David Pollak wrote: > On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe > wrote: > > > > > > > On Mon, Nov 16, 2009 at 4:02 PM, David Pollak > > wrote: > > > > On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe < > > kris.nuttyco...@gmail.com> > > > wrote: > > > >> On Mon, Nov 1

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Mon, Nov 16, 2009 at 4:11 PM, David Pollak wrote: > > > On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe > wrote: >> >> On Mon, Nov 16, 2009 at 4:02 PM, David Pollak >> wrote: >> > >> > >> > On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe >> > >> > wrote: >> >> >> >> On Mon, Nov 16, 2009 a

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe wrote: > > On Mon, Nov 16, 2009 at 4:02 PM, David Pollak > wrote: > > > > > > On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe < > kris.nuttyco...@gmail.com> > > wrote: > >> > >> On Mon, Nov 16, 2009 at 3:13 PM, David Pollak > >> wrote: > >> > > >

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Mon, Nov 16, 2009 at 4:02 PM, David Pollak wrote: > > > On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe > wrote: >> >> On Mon, Nov 16, 2009 at 3:13 PM, David Pollak >> wrote: >> > >> > >> > On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe >> > >> > wrote: >> >> >> >> Hi, all, >> >> >> >> I

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe wrote: > > On Mon, Nov 16, 2009 at 3:13 PM, David Pollak > wrote: > > > > > > On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe < > kris.nuttyco...@gmail.com> > > wrote: > >> > >> Hi, all, > >> > >> I was just informed that my changes broke MetaMega

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Mon, Nov 16, 2009 at 3:13 PM, David Pollak wrote: > > > On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe > wrote: >> >> Hi, all, >> >> I was just informed that my changes broke MetaMegaProtoUser >> interaction. I've reverted the commit until I can get that sorted out. > > How was it broken?

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe wrote: > > Hi, all, > > I was just informed that my changes broke MetaMegaProtoUser > interaction. I've reverted the commit until I can get that sorted out. > How was it broken? > > Sorry, > > Kris > > On Mon, Nov 16, 2009 at 11:27 AM, Kris Nutty

[Lift] Re: *** BREAKING CHANGES *** to Loc & LocParam

Hi, all, I was just informed that my changes broke MetaMegaProtoUser interaction. I've reverted the commit until I can get that sorted out. Sorry, Kris On Mon, Nov 16, 2009 at 11:27 AM, Kris Nuttycombe wrote: > Hi, all, > > I have committed a number of enhancements to Loc & LocParam which > i

[Lift] Re: **Breaking Changes** **README** **Important**

On Thu, Oct 22, 2009 at 8:54 PM, Jonathan Ferguson wrote: > If we are using Actors for non Comet based stuff I assume we are free to > leave them as is as long as we don't come asking for support ? Absolutely. Use the Actor library that best suits your needs. > > I am thinking about moving th

[Lift] Re: **Breaking Changes** **README** **Important**

If we are using Actors for non Comet based stuff I assume we are free to leave them as is as long as we don't come asking for support ? I am thinking about moving through switching them over, but I'd like to do it at a leisurely pace. Jono 2009/10/23 David Pollak > > > On Thu, Oct 22, 2009 at

[Lift] Re: **Breaking Changes** **README** **Important**

On Thu, Oct 22, 2009 at 6:03 PM, ssid wrote: > > Hi all, > I'm using XMPP in my little LiftApp and tried to migrate my code to > the new Lift Actors. > Somehow it seems that net.liftweb.xmpp still uses Scala Actors. > Is this intentional or about to change? > I was lazy and didn't make that chan

[Lift] Re: **Breaking Changes** **README** **Important**

On Thu, Oct 22, 2009 at 6:28 PM, Jim Barrows wrote: > RrttrRrrrtrtrtrrrtrtrtrrttÞ > bless you. > Sent on the Now Network™ from my Sprint® BlackBerry > > -Original Message- > From: ssid > Date: Thu, 22 Oct 2009 18:03:25 > To: Lift > Subject: [L

[Lift] Re: **Breaking Changes** **README** **Important**

RrttrRrrrtrtrtrrrtrtrtrrttÞ Sent on the Now Network™ from my Sprint® BlackBerry -Original Message- From: ssid Date: Thu, 22 Oct 2009 18:03:25 To: Lift Subject: [Lift] Re: **Breaking Changes** **README** **Important** Hi all, I'm using XMPP in my little LiftApp and tri

[Lift] Re: **Breaking Changes** **README** **Important**

Hi all, I'm using XMPP in my little LiftApp and tried to migrate my code to the new Lift Actors. Somehow it seems that net.liftweb.xmpp still uses Scala Actors. Is this intentional or about to change? If not is it possible that Scala Actors communicate with Lift Actors? At the moment I don't get m

[Lift] Re: **Breaking Changes** **README** **Important**

Thanks Dan, I will try that. --~--~-~--~~~---~--~~ 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.

[Lift] Re: **Breaking Changes** **README** **Important**

Code for our app now compiles. Needed to replace Actor with LiftActor. Also, needed to define the messageHandler partial function. So, George, I think the answer to your question is: object LocalSmtp extends Actor becomes object LocalSmtp extends LiftActor Dan On Oct 22, 11:19 am, Dano w

[Lift] Re: **Breaking Changes** **README** **Important**

I did a quick check in the lift sources and could not find example or test code for the new LiftActors. Perhaps additions to these areas would help those that are trying to convert their Actor code. Thanks in advance for any help for those still struggling to make the conversion. Dan On Oct 2

[Lift] Re: **Breaking Changes** **README** **Important**

It would be good to have an example like George's verified as it is not clear how to convert our Actor code. Dan On Oct 22, 4:48 am, george wrote: > ok so.. > > object LocalSmtp extends Actor > > should become > > object LocalSmtp extends GenericActor[LocalSmtp] > > ? --~--~-~--~~

[Lift] Re: **Breaking Changes** **README** **Important**

ok so.. object LocalSmtp extends Actor should become object LocalSmtp extends GenericActor[LocalSmtp] ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@g

[Lift] Re: **Breaking Changes** **README** **Important**

Guys, >   Prior to the changes, I had a function "def registerActor(act: > Actor) which could handle both scala Actor as well as CometActor,; now > if I change this to "def registerActor(act: GenericActor)" it throws > compilation error asking to a type to be specified for the > GenericActor. Wh

[Lift] Re: **Breaking Changes** **README** **Important**

DPP (and I) recommend just doing schedule and then re-schedule after message recieved. schedule(actor,MyMsg(),3 seconds) in the actor { case MyMsg() => { doMyStuff schedule(this,MyMsg(),3 seconds) } } Makes sense? On Thu, O

[Lift] Re: **Breaking Changes** **README** **Important**

> - Secondly, I also get compilation error for calling > scheduleAtFixedRate method on ActorPing. Says no such method. Has this > method been deprecated and if so, what is the method I should be > calling instead? I have this problem also. --~--~-~--~~~---~--~~ Yo

[Lift] Re: **Breaking Changes** **README** **Important**

Hi, I've a few question regarding the changes made. - Firstly, with the changes made, how do I have a method which can now accept both scala Actor as well as a CometActor?? Prior to the changes, I had a function "def registerActor(act: Actor) which could handle both scala Actor as well as CometA

[Lift] Re: **Breaking Changes** **README** **Important**

You're right, my bad - an old pom was looking at the wrong repo, all happy now. Cheers Jono 2009/10/22 David Pollak > > > On Wed, Oct 21, 2009 at 10:27 PM, Jonathan Ferguson wrote: > >> Do we need to update our pom's or should it be code changes only ? > > > You likely only need to make the cod

[Lift] Re: **Breaking Changes** **README** **Important**

Code change should suffice. pom.xml updates won't be necessary since lift-util has lift-common as dependency and your application (which must be having lift-util as dependency) would resolve the lift-common dependency transitively. Cheers, Indrajit On 22/10/09 10:57 AM, Jonathan Ferguson wrot

[Lift] Re: **Breaking Changes** **README** **Important**

On Wed, Oct 21, 2009 at 10:27 PM, Jonathan Ferguson wrote: > Do we need to update our pom's or should it be code changes only ? You likely only need to make the code change... at least that's been the case for all the projects I've converted. > > Cheers > > Jono > > 2009/10/22 David Pollak >

[Lift] Re: **Breaking Changes** **README** **Important**

Do we need to update our pom's or should it be code changes only ? Cheers Jono 2009/10/22 David Pollak > Folks, > As the title of this email indicates, there are breaking changes in Lift > that just got pushed to master. > > We've migrated from Scala Actors to Lift Actors and included a series

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

Of course in a perfect world we would like to use the perfect EPFL actors. But as know the world, well at least EPFL actors, are not perfect. By the way: Scala is a lot about libraries, hence IMHO it is OK if Lift uses it's own approach for actors. => Let's go for lift-actor, if possible abstracted

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

I vote for lift-actor. On Wed, Sep 16, 2009 at 10:46 AM, David Pollak < feeder.of.the.be...@gmail.com> wrote: > > > On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett > wrote: > >> Kevin, >> >> To clarify, your talking about akka-actors? >> >> The preferred route I think would be to use a fixed EP

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett wrote: > Kevin, > > To clarify, your talking about akka-actors? > > The preferred route I think would be to use a fixed EPFL implementation, > however, in leu of that i think from a project perspective it would be > beneficial for lift to have a cor

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

On Wed, Sep 16, 2009 at 4:50 PM, Timothy Perrett wrote: > Kevin, > > To clarify, your talking about akka-actors? > > The preferred route I think would be to use a fixed EPFL implementation, > however, in leu of that i think from a project perspective it would be > beneficial for lift to have a cor

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

Kevin, To clarify, your talking about akka-actors? The preferred route I think would be to use a fixed EPFL implementation, however, in leu of that i think from a project perspective it would be beneficial for lift to have a corrected actor implementation that we have direct control of. I k

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

On Wed, Sep 16, 2009 at 6:27 AM, Kevin Wright wrote: > Is there any reason not to go with something like the Akka framework? I > believe it has a lift-friendly license. I can work on a way to make CometActors work with Akka Actors or Lift Actors. Jonas and I have had a lot of conversations an

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

On Wed, Sep 16, 2009 at 3:42 PM, Naftoli Gugenheim wrote: > > I haven't used comet, but would it be worthwhile to abstract it with > implementations (potentially) for Scala, Lift, and Akka actors? > I've integrated Atmosphere into Akka, and I know that Jeanfranço

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

I haven't used comet, but would it be worthwhile to abstract it with implementations (potentially) for Scala, Lift, and Akka actors? - TylerWeir wrote: Given the on again/off again nature of the issue, I'm voting for adding your change. We can rely on your c

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

What is the problem this time? .. same thing essentially? Br's, Marius On Sep 16, 8:14 am, David Pollak wrote: > Guys, > The Scala Actor issue has raised its head again. > > From November 2008 - June 2009, I did an epic battle with Scala actors and > their memory retention issues. > > I finally

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

Hey David, Are you saying that scala actors are leaking outside of large rate construction / destruction situations? At least, I remember that was what was tickling the EPFL bug last time :-) This has pretty major ramifications if it is! Personally, I'm happy to move to lift-actor. Cheers

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

Given the on again/off again nature of the issue, I'm voting for adding your change. We can rely on your code working until the issue is sorted with the Scala team. So, +1 to dpp's code. On Sep 16, 9:14 am, David Pollak wrote: > Guys, > The Scala Actor issue has raised its head again. > > From

[Lift] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

Is there any reason not to go with something like the Akka framework? I believe it has a lift-friendly license. On Wed, Sep 16, 2009 at 2:14 PM, David Pollak wrote: > Guys, > The Scala Actor issue has raised its head again. > > From November 2008 - June 2009, I did an epic battle with Scala act

[Lift] Re: *** BREAKING CHANGES COMMITTED ***

On Fri, Aug 7, 2009 at 12:35 PM, Kevin Wright wrote: > Impressive stuff :) +1 Way to go Marius. > > > On Fri, Aug 7, 2009 at 6:54 PM, marius d. wrote: > >> >> Dear all, >> >> I'f committed today in the master the support for abstracting HTTP >> stack in lift so that Lift itself does not dep

[Lift] Re: *** BREAKING CHANGES COMMITTED ***

Impressive stuff :) On Fri, Aug 7, 2009 at 6:54 PM, marius d. wrote: > > Dear all, > > I'f committed today in the master the support for abstracting HTTP > stack in lift so that Lift itself does not depend on javax.servlet._ > classes. This allows us to add support for Netty, AsyncWeb, etc. or >

[Lift] Re: *** BREAKING CHANGES COMMITTED ***

Dear all, I'f committed today in the master the support for abstracting HTTP stack in lift so that Lift itself does not depend on javax.servlet._ classes. This allows us to add support for Netty, AsyncWeb, etc. or even your own implementation of a HTTP server etc. This effort lead to several bre

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

And looks to perform a bit better then MINA. On Aug 5, 2:13 pm, Derek Chen-Becker wrote: > Netty looks really cool. On a quick read it sounds maybe a little like MINA, > although it definitely looks like it has a more high-level API to simplify > things. > > On Wed, Aug 5, 2009 at 5:08 AM, mariu

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

We just rolled out a milestone release last night. 1.1-SNAPSHOT-M4 Cheers, Tim On Aug 5, 12:08 pm, "marius d." wrote: > Sounds good to me > > On Aug 5, 1:51 pm, Yousry Abdallah wrote: > > > > > Could you setup a milestone before the merge? > > > On 4 Aug., 21:51, Marius wrote: > > > > Folks,

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

Netty looks really cool. On a quick read it sounds maybe a little like MINA, although it definitely looks like it has a more high-level API to simplify things. On Wed, Aug 5, 2009 at 5:08 AM, marius d. wrote: > > Sounds good to me > > On Aug 5, 1:51 pm, Yousry Abdallah wrote: > > Could you setu

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

Sounds good to me On Aug 5, 1:51 pm, Yousry Abdallah wrote: > Could you setup a milestone before the merge? > > On 4 Aug., 21:51, Marius wrote: > > > Folks, > > > I spent a few days decoupling Lift from JEE web container > > dependencies: javax.servlet._ The code is currently in wip-marius-http

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

Could you setup a milestone before the merge? On 4 Aug., 21:51, Marius wrote: > Folks, > > I spent a few days decoupling Lift from JEE web container > dependencies: javax.servlet._ The code is currently in wip-marius-http- > abstractions. > > I still need to nail down a few things but the idea i

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

Portlets have some mixed press, so im not sure how much of a win that will be. The AsyncWeb / Netty stuff does look pretty freaking cool tho. Cheers, Tim On Aug 4, 10:40 pm, Derek Chen-Becker wrote: > Cool. I'll have to look at portlets and see what they do. > > Derek > > On Tue, Aug 4, 2009 at

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

Things like AsyncWeb, some HTTP stacks on top of Netty ... Br's, Marius On Aug 4, 11:37 pm, Derek Chen-Becker wrote: > I don't necessarily have a problem with this, but what's the gain? Are there > other HTTP frameworks that don't use the javax.servlet API? Just curious. > > Derek > > On Tue, A

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

Cool. I'll have to look at portlets and see what they do. Derek On Tue, Aug 4, 2009 at 2:38 PM, David Pollak wrote: > > > On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker > wrote: > >> I don't necessarily have a problem with this, but what's the gain? Are >> there other HTTP frameworks that do

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker wrote: > I don't necessarily have a problem with this, but what's the gain? Are > there other HTTP frameworks that don't use the javax.servlet API? Just > curious. Yes, Jersey directly, portlets, etc. > > > Derek > > > On Tue, Aug 4, 2009 at 1:5

[Lift] Re: *** BREAKING CHANGES COMING UP SOON ***

I don't necessarily have a problem with this, but what's the gain? Are there other HTTP frameworks that don't use the javax.servlet API? Just curious. Derek On Tue, Aug 4, 2009 at 1:51 PM, Marius wrote: > > Folks, > > I spent a few days decoupling Lift from JEE web container > dependencies: jav

[Lift] Re: *** BREAKING CHANGES ***

On Tue, Feb 10, 2009 at 3:52 PM, Oliver wrote: > > My apologies, it works as shown by your code and in the way Jorge > described. I had changed simply cut and pasted Marius's example > and deleted it when it didn't work. Then I changed my own code without > modifying the case statement correctly.

[Lift] Re: *** BREAKING CHANGES ***

My apologies, it works as shown by your code and in the way Jorge described. I had changed simply cut and pasted Marius's example and deleted it when it didn't work. Then I changed my own code without modifying the case statement correctly. Sometimes I can't add 1 + 1 On Wed, Feb 11, 2009 at 10:2

[Lift] Re: *** BREAKING CHANGES ***

On Tue, Feb 10, 2009 at 3:13 PM, Oliver wrote: > > I've just updated my code to rely on the stable version of lift 0.10 > rather than an earlier snapshot. > Unfortunately the removal of LiftRules.logAndReturnExceptionToBrowser > and non working status of > LiftRules.exceptionHandler.prepend means

[Lift] Re: *** BREAKING CHANGES ***

I've just updated my code to rely on the stable version of lift 0.10 rather than an earlier snapshot. Unfortunately the removal of LiftRules.logAndReturnExceptionToBrowser and non working status of LiftRules.exceptionHandler.prepend means my choices now are 1) To back out my reliance on the stabl

[Lift] Re: *** BREAKING CHANGES ***

Oliver, What version of Lift are you using? Thanks, David On Tue, Feb 10, 2009 at 2:58 PM, Oliver wrote: > > Doesn't look right and If I do this I get the following error - > constructor cannot be instantiated to the expected type > > On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz > wrote: > >

[Lift] Re: *** BREAKING CHANGES ***

Doesn't look right and If I do this I get the following error - constructor cannot be instantiated to the expected type On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz wrote: > Try (without the = sign): > > LiftRules.exceptionHandler.prepend { >case (mode, state, ex) => RedirectResponse("/error

[Lift] Re: *** BREAKING CHANGES ***

Try (without the = sign): LiftRules.exceptionHandler.prepend { case (mode, state, ex) => RedirectResponse("/error") } --j On Mon, Feb 9, 2009 at 10:47 PM, Oliver wrote: > > If I try to use the following, I get a reassignment to Val error - any > ideas? > > LiftRules.exceptionHandler.prepend

[Lift] Re: *** BREAKING CHANGES ***

If I try to use the following, I get a reassignment to Val error - any ideas? LiftRules.exceptionHandler.prepend = { case (mode, state, ex) => RedirectResponse("/error") } On Wed, Dec 24, 2008 at 5:41 AM, Marius wrote: > > Folks, > > I just committed a couple of changes that may impact your

[Lift] Re: *Breaking Changes* Getting down and CRUDy

On Mon, Jan 19, 2009 at 7:01 AM, TylerWeir wrote: > > CRUDify is sweeet! :-) > > > (extra "e" for extra sweet") > > > > On Dec 2 2008, 2:02 pm, "David Pollak" > wrote: > > :-) > > > > On Dec 2, 2008 11:00 AM, "Derek Chen-Becker" > wrote: > > > > I just found this email while researching all

[Lift] Re: *Breaking Changes* Getting down and CRUDy

CRUDify is sweeet! (extra "e" for extra sweet") On Dec 2 2008, 2:02 pm, "David Pollak" wrote: > :-) > > On Dec 2, 2008 11:00 AM, "Derek Chen-Becker" wrote: > > I just found this email while researching all of the CRUD stuff in mapper. > One word: supercalifragilisticexpialidocious! > > On Th

[Lift] Re: *Breaking Changes* Getting down and CRUDy

:-) On Dec 2, 2008 11:00 AM, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote: I just found this email while researching all of the CRUD stuff in mapper. One word: supercalifragilisticexpialidocious! On Thu, Nov 20, 2008 at 7:23 PM, David Pollak <[EMAIL PROTECTED]> wrote: > > Folks, > ... --~

[Lift] Re: *Breaking Changes* Getting down and CRUDy

I just found this email while researching all of the CRUD stuff in mapper. One word: supercalifragilisticexpialidocious! On Thu, Nov 20, 2008 at 7:23 PM, David Pollak <[EMAIL PROTECTED] > wrote: > Folks, > > I've been cleaning up code and adding features left and right. > > First, the breaking ch

[Lift] Re: *Breaking Changes* CometActor instantiation and SHtml.submit() and SHtml.hidden()

Nice stuff for CometActor ... it's really handy having the session etc. to be injected automatically by Lift Br's, Marius On Nov 7, 3:14 am, David Pollak <[EMAIL PROTECTED]> wrote: > Folks, > > I've make some breaking changes to Lift: > >     * CometActors no longer take any parameters during in

[Lift] Re: *breaking changes* Gravatar widget

Glad you like it guys :-) On Nov 1, 4:26 pm, TylerWeir <[EMAIL PROTECTED]> wrote: > Much better than my initial impl.  Thanks and good stuff. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to

[Lift] Re: *breaking changes* Gravatar widget

Much better than my initial impl. Thanks and good stuff. On Nov 1, 7:18 am, Tim Perrett <[EMAIL PROTECTED]> wrote: > Hey guys, > > I've updated the Gravatar widget that was origionally created by Ty. > The implementation now is actually very different. No longer is the > Gravatar class an instan

[Lift] Re: *breaking changes* Gravatar widget

Excellent stuff! On 11/1/08, Tim Perrett <[EMAIL PROTECTED]> wrote: > > > Hey guys, > > I've updated the Gravatar widget that was origionally created by Ty. > The implementation now is actually very different. No longer is the > Gravatar class an instansiable class, its an object with overloaded >