Excellent work Ross !
On Feb 12, 6:49 am, Ross Mellgren dri...@gmail.com 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,
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
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
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
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
On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:
On Mon, Nov 16, 2009 at 4:02 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe
On Nov 17, 3:37 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com
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
On Tue, Nov 17, 2009 at 7:37 AM, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:
On Mon, Nov 16, 2009 at 4:02 PM, David Pollak
On Tue, Nov 17, 2009 at 7:30 AM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:
On Tue, Nov 17, 2009 at 7:37 AM, Jeppe Nejsum Madsen je...@ingolfs.dk
wrote:
On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe
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
kris.nuttyco...@gmail.com wrote:
Hi, all,
I have committed a number of enhancements to
On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:
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
On Mon, Nov 16, 2009 at 3:13 PM, David Pollak
feeder.of.the.be...@gmail.com 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 MetaMegaProtoUser
interaction. I've reverted the commit until I can get
On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:
On Mon, Nov 16, 2009 at 3:13 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe
kris.nuttyco...@gmail.com
wrote:
Hi, all,
I was just informed
On Mon, Nov 16, 2009 at 4:02 PM, David Pollak
feeder.of.the.be...@gmail.com 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
feeder.of.the.be...@gmail.com wrote:
On Mon, Nov 16, 2009 at 2:12 PM,
On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:
On Mon, Nov 16, 2009 at 4:02 PM, David Pollak
feeder.of.the.be...@gmail.com 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,
On Mon, Nov 16, 2009 at 4:11 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe kris.nuttyco...@gmail.com
wrote:
On Mon, Nov 16, 2009 at 4:02 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Nov 16, 2009 at 2:20 PM,
You're right, my bad - an old pom was looking at the wrong repo, all happy
now.
Cheers
Jono
2009/10/22 David Pollak feeder.of.the.be...@gmail.com
On Wed, Oct 21, 2009 at 10:27 PM, Jonathan Ferguson j...@spiralarm.comwrote:
Do we need to update our pom's or should it be code changes only ?
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
- 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.
--~--~-~--~~~---~--~~
You
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,
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. What
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
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 geo...@mattandgeorge.com wrote:
ok so..
object LocalSmtp extends Actor
should become
object LocalSmtp extends GenericActor[LocalSmtp]
?
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
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
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
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
RrttrRrrrtrtrtrrrtrtrtrrttÞ
Sent on the Now Network™ from my Sprint® BlackBerry
-Original Message-
From: ssid j.gat...@googlemail.com
Date: Thu, 22 Oct 2009 18:03:25
To: Liftliftweb@googlegroups.com
Subject: [Lift] Re: **Breaking Changes** **README** **Important**
Hi all
@googlegroups.com
Subject: [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
On Thu, Oct 22, 2009 at 6:03 PM, ssid j.gat...@googlemail.com 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
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 feeder.of.the.be...@gmail.com
On Thu, Oct 22, 2009 at 8:54 PM, Jonathan Ferguson j...@spiralarm.comwrote:
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
Do we need to update our pom's or should it be code changes only ?
Cheers
Jono
2009/10/22 David Pollak feeder.of.the.be...@gmail.com
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
On Wed, Oct 21, 2009 at 10:27 PM, Jonathan Ferguson j...@spiralarm.comwrote:
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
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
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 feeder.of.the.be...@gmail.com
wrote:
Guys,
The Scala Actor issue has raised its head again.
From November 2008 - June 2009, I did an
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 feeder.of.the.be...@gmail.com
wrote:
Guys,
The Scala Actor issue has
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
What is the problem this time? .. same thing essentially?
Br's,
Marius
On Sep 16, 8:14 am, David Pollak feeder.of.the.be...@gmail.com
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
I haven't used comet, but would it be worthwhile to abstract it with
implementations (potentially) for Scala, Lift, and Akka actors?
-
TylerWeirtyler.w...@gmail.com wrote:
Given the on again/off again nature of the issue, I'm voting for
adding your change.
On Wed, Sep 16, 2009 at 3:42 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
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 http://atmosphere.dev.java.net/ into Akka, and
I know
On Wed, Sep 16, 2009 at 6:27 AM, Kevin Wright kev.lee.wri...@googlemail.com
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
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
On Wed, Sep 16, 2009 at 4:50 PM, Timothy Perrett timo...@getintheloop.euwrote:
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
On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett timo...@getintheloop.euwrote:
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
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
timo...@getintheloop.euwrote:
Kevin,
To clarify, your talking about akka-actors?
The preferred route I think would be to use a
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
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
Impressive stuff :)
On Fri, Aug 7, 2009 at 6:54 PM, marius d. marius.dan...@gmail.com 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,
On Fri, Aug 7, 2009 at 12:35 PM, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
Impressive stuff :)
+1
Way to go Marius.
On Fri, Aug 7, 2009 at 6:54 PM, marius d. marius.dan...@gmail.com wrote:
Dear all,
I'f committed today in the master the support for abstracting HTTP
stack
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 dchenbec...@gmail.com wrote:
Cool. I'll have to look at portlets and see what they do.
Derek
On
Could you setup a milestone before the merge?
On 4 Aug., 21:51, Marius marius.dan...@gmail.com 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
Sounds good to me
On Aug 5, 1:51 pm, Yousry Abdallah yous...@gmail.com wrote:
Could you setup a milestone before the merge?
On 4 Aug., 21:51, Marius marius.dan...@gmail.com wrote:
Folks,
I spent a few days decoupling Lift from JEE web container
dependencies: javax.servlet._ The code
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. marius.dan...@gmail.com wrote:
Sounds good to me
On Aug 5, 1:51 pm, Yousry Abdallah
And looks to perform a bit better then MINA.
On Aug 5, 2:13 pm, Derek Chen-Becker dchenbec...@gmail.com 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
On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:
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
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
feeder.of.the.be...@gmail.comwrote:
On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
I don't necessarily have a problem with this, but what's the
Things like AsyncWeb, some HTTP stacks on top of Netty ...
Br's,
Marius
On Aug 4, 11:37 pm, Derek Chen-Becker dchenbec...@gmail.com 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.
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 jorge.or...@gmail.com wrote:
Try (without the = sign):
LiftRules.exceptionHandler.prepend {
case (mode, state, ex) =
Oliver,
What version of Lift are you using?
Thanks,
David
On Tue, Feb 10, 2009 at 2:58 PM, Oliver ola...@gmail.com 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
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
On Tue, Feb 10, 2009 at 3:13 PM, Oliver ola...@gmail.com 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
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
On Tue, Feb 10, 2009 at 3:52 PM, Oliver ola...@gmail.com 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
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 marius.dan...@gmail.com wrote:
Folks,
I just committed a couple of changes
CRUDify is sweeet!
(extra e for extra sweet)
On Dec 2 2008, 2:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
:-)
On Dec 2, 2008 11:00 AM, Derek Chen-Becker dchenbec...@gmail.com wrote:
I just found this email while researching all of the CRUD stuff in mapper.
One word:
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 changes
:-)
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, ...
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
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
apply
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 instansiable
71 matches
Mail list logo
