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

[Marius]

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 like this:
>
> object MyRecord extends Record[MyRecord] {
>     object myNormalField extends StringField(this, 100)
>     object myOptionalField extends StringField(this, 100) {
>         override def optional_? = true
>         override def defaultValueBox = Empty
>         override def defaultValue = "nothin"
>     }
>
> }
>
> val r: MyRecord
>
> r.myNormalField.set("Hello") // as before the change
> r.myOptionalField.setBox(Empty)
>
> r.myNormalField.value == "Hello" // as before
> r.myNormalField.valueBox == Full("Hello")
> r.myOptionalField.valueBox == Empty
> r.myOptionalField.value == "nothin" // because defaultValue was used to give 
> back something
>
> As part of this change, the semantics for field errors has changed somewhat 
> -- hopefully, to be more consistent.
>
> Previously if you tried to set a field and checkCanWrite_? returned false 
> then an internal flag "valueCouldNotBeSet" on the field will be raised which 
> makes that field generate a validation error when validate is called on the 
> record. In addition, some fields (but not all) would raise the same flag and 
> return Failure or Empty from setFromString or setFromAny upon being given an 
> invalid value.
>
> With this change, all types of failure to set now result in the field value 
> becoming a Failure. setFromAny, setFromString, and setBox all return that 
> Failure, while set will return defaultValue (due to its return type.)
>
> validators and set filters have had their types changed to Boxed equivalents.
>
> And finally, I made consistent the setFromAny methods of all the built-in 
> field types so that they all follow the same contract. For setFromAny it's 
> essentially accept one of MyType, Box[MyType], Option[MyType], or 
> List[MyType] as well as null, with a default to convert an unknown input to 
> string and use setFromString. For setFromString, it is as before, except if 
> the field is optional_? and the empty string is passed in, that's treated as 
> Empty.
>
> As I'll mention in another message, I also pushed lift-couchdb to master. I 
> ran the unit tests that I wrote for that, but that doesn't give me full 
> confidence that all the fields are entirely bug free. Similarly I did not 
> test the form generation. If anybody runs into any issues please let me know 
> and I'll fix it as soon as I can. And of course if it causes too much 
> breakage we can revert it back out.
>
> -Ross

-- 
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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

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

[Ross Mellgren]

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 extends fields needs double (e.g. DBIntField, 
DBOptionalIntField)
 - Less code
 - Centralizes error handling.

Fields that aren't optional should act mostly the same as they did, modulo 
validators and set filters.

Let me know what you'd like described better. I can go into the details of how 
it's implemented maybe? Or do you want more examples? I'd be happy to clarify 
what the change is.

-Ross

P.S. here's the RB link, in case you'd like to take a look at the older 
version, or what have you

http://reviewboard.liftweb.net/r/191/


On Feb 12, 2010, at 12:34 AM, harryh wrote:

> 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 Feb 11, 11:49 pm, 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 like this:
>> 
>> object MyRecord extends Record[MyRecord] {
>> object myNormalField extends StringField(this, 100)
>> object myOptionalField extends StringField(this, 100) {
>> override def optional_? = true
>> override def defaultValueBox = Empty
>> override def defaultValue = "nothin"
>> }
>> 
>> }
>> 
>> val r: MyRecord
>> 
>> r.myNormalField.set("Hello") // as before the change
>> r.myOptionalField.setBox(Empty)
>> 
>> r.myNormalField.value == "Hello" // as before
>> r.myNormalField.valueBox == Full("Hello")
>> r.myOptionalField.valueBox == Empty
>> r.myOptionalField.value == "nothin" // because defaultValue was used to give 
>> back something
>> 
>> As part of this change, the semantics for field errors has changed somewhat 
>> -- hopefully, to be more consistent.
>> 
>> Previously if you tried to set a field and checkCanWrite_? returned false 
>> then an internal flag "valueCouldNotBeSet" on the field will be raised which 
>> makes that field generate a validation error when validate is called on the 
>> record. In addition, some fields (but not all) would raise the same flag and 
>> return Failure or Empty from setFromString or setFromAny upon being given an 
>> invalid value.
>> 
>> With this change, all types of failure to set now result in the field value 
>> becoming a Failure. setFromAny, setFromString, and setBox all return that 
>> Failure, while set will return defaultValue (due to its return type.)
>> 
>> validators and set filters have had their types changed to Boxed equivalents.
>> 
>> And finally, I made consistent the setFromAny methods of all the built-in 
>> field types so that they all follow the same contract. For setFromAny it's 
>> essentially accept one of MyType, Box[MyType], Option[MyType], or 
>> List[MyType] as well as null, with a default to convert an unknown input to 
>> string and use setFromString. For setFromString, it is as before, except if 
>> the field is optional_? and the empty string is passed in, that's treated as 
>> Empty.
>> 
>> As I'll mention in another message, I also pushed lift-couchdb to master. I 
>> ran the unit tests that I wrote for that, but that doesn't give me full 
>> confidence that all the fields are entirely bug free. Similarly I did not 
>> test the form generation. If anybody runs into any issues please let me know 
>> and I'll fix it as soon as I can. And of course if it causes too much 
>> breakage we can revert it back out.
>> 
>> -Ross
> 
> -- 
> 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.com.
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en.
> 

-- 
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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

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

[harryh]

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 Feb 11, 11:49 pm, 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 like this:
>
> object MyRecord extends Record[MyRecord] {
>     object myNormalField extends StringField(this, 100)
>     object myOptionalField extends StringField(this, 100) {
>         override def optional_? = true
>         override def defaultValueBox = Empty
>         override def defaultValue = "nothin"
>     }
>
> }
>
> val r: MyRecord
>
> r.myNormalField.set("Hello") // as before the change
> r.myOptionalField.setBox(Empty)
>
> r.myNormalField.value == "Hello" // as before
> r.myNormalField.valueBox == Full("Hello")
> r.myOptionalField.valueBox == Empty
> r.myOptionalField.value == "nothin" // because defaultValue was used to give 
> back something
>
> As part of this change, the semantics for field errors has changed somewhat 
> -- hopefully, to be more consistent.
>
> Previously if you tried to set a field and checkCanWrite_? returned false 
> then an internal flag "valueCouldNotBeSet" on the field will be raised which 
> makes that field generate a validation error when validate is called on the 
> record. In addition, some fields (but not all) would raise the same flag and 
> return Failure or Empty from setFromString or setFromAny upon being given an 
> invalid value.
>
> With this change, all types of failure to set now result in the field value 
> becoming a Failure. setFromAny, setFromString, and setBox all return that 
> Failure, while set will return defaultValue (due to its return type.)
>
> validators and set filters have had their types changed to Boxed equivalents.
>
> And finally, I made consistent the setFromAny methods of all the built-in 
> field types so that they all follow the same contract. For setFromAny it's 
> essentially accept one of MyType, Box[MyType], Option[MyType], or 
> List[MyType] as well as null, with a default to convert an unknown input to 
> string and use setFromString. For setFromString, it is as before, except if 
> the field is optional_? and the empty string is passed in, that's treated as 
> Empty.
>
> As I'll mention in another message, I also pushed lift-couchdb to master. I 
> ran the unit tests that I wrote for that, but that doesn't give me full 
> confidence that all the fields are entirely bug free. Similarly I did not 
> test the form generation. If anybody runs into any issues please let me know 
> and I'll fix it as soon as I can. And of course if it causes too much 
> breakage we can revert it back out.
>
> -Ross

-- 
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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

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

[Indrajit Raychaudhuri]

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-catalog.xml that is bundled internally. That catalog is 
an old one.

The only way to have archetype:generate pick up new catalog is to 
specify one via -DarchetypeCatalog. For example, "mvn archetype:generate 
-DarchetypeCatalog=http://scala-tools.org/"; should show you the new list.

That said, we don't have the new catalog of archetypes deployed on 
http://scala-tools.org/archetype-catalog.xml. Please raise a ticket for 
this.

Till then, the longer version of archetype:generate (with 
'-DarchetypeRepository=... -DremoteRepositories=...' etc.) works best.

[1] 
http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-catalog.html
[2] 
http://maven.apache.org/plugins/maven-archetype-plugin/generate-mojo.html#archetypeCatalog

Cheers, Indrajit


On 28/12/09 1:35 AM, joseph hirn wrote:
> 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 menu but it would be nice to get something relatively more
> up to date.
>
> Sorry if this is discussed elsewhere.
>
>
> On Dec 1, 8:28 am, Indrajit Raychaudhuri  wrote:
>> Friends,
>>
>> Following the recent refactoring that the Lift archetypes went though,
>> we have moved forward to the newarchetypemetadata format [1] for all
>> the archetypes.
>>
>> So far, the JPA related archetypes were using the new metadata format
>> while the others (esp. lift-archetype-blank and lift-archetype-basic)
>> were still on the old format. Moving to the new metadata format helps
>> us keep things consistent, comply with Maven's recommendation and open
>> the archetypes up for additional future enhancements.
>>
>>  From now on, the recommended Maven goal togenerateprojects fromarchetypeis 
>> to use "archetype:generate" [2]. The currently deprecated
>> Maven goal "archetype:create" [3] would not work to give expected
>> result and thus is not recommended anymore.
>>
>> Therefore, togenerateproject from the archetypes in the master you
>> would use a command of the form:
>>
>> mvnarchetype:generate\
>>-DarchetypeRepository=http://scala-tools.org/repo-snapshots\
>>-DremoteRepositories=http://scala-tools.org/repo-snapshots\
>>-DarchetypeGroupId=net.liftweb \
>>-DarchetypeArtifactId=lift-archetype-blank \
>>-DarchetypeVersion=1.1-SNAPSHOT \
>>-DgroupId=com.mypackage \
>>-DartifactId=myproject \
>>-Dversion=1.0-SNAPSHOT
>>
>> Currently, the possible archetypeArtifactId are:
>>- lift-archetype-blank
>>- lift-archetype-basic
>>- lift-archetype-jpa-blank-single
>>- lift-archetype-jpa-blank
>>- lift-archetype-jpa-basic
>>
>> If you create project interactively (default behavior), -DgroupId, -
>> DartifactId, -Dversion are optional. Maven would prompt for these
>> values (and some more) interactively.
>>
>> On the other hand, if you are using a batch/shell script togenerate
>> project non-interactively, you would need to add at least -DgroupId, -
>> DartifactId and additionally set -DinteractiveMode=false.
>>
>> Cheers, Indrajit
>>
>> References:
>> [1]http://maven.apache.org/plugins/maven-archetype-plugin/specification/...
>> [2]http://maven.apache.org/plugins/maven-archetype-plugin/generate-mojo
>> [3]http://maven.apache.org/plugins/maven-archetype-plugin/create-mojo.html
>
> --
>
> 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.com.
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en.
>
>

--

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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

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

[joseph hirn]

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 menu but it would be nice to get something relatively more
up to date.

Sorry if this is discussed elsewhere.


On Dec 1, 8:28 am, Indrajit Raychaudhuri  wrote:
> Friends,
>
> Following the recent refactoring that the Lift archetypes went though,
> we have moved forward to the newarchetypemetadata format [1] for all
> the archetypes.
>
> So far, the JPA related archetypes were using the new metadata format
> while the others (esp. lift-archetype-blank and lift-archetype-basic)
> were still on the old format. Moving to the new metadata format helps
> us keep things consistent, comply with Maven's recommendation and open
> the archetypes up for additional future enhancements.
>
> From now on, the recommended Maven goal togenerateprojects fromarchetypeis to 
> use "archetype:generate" [2]. The currently deprecated
> Maven goal "archetype:create" [3] would not work to give expected
> result and thus is not recommended anymore.
>
> Therefore, togenerateproject from the archetypes in the master you
> would use a command of the form:
>
> mvnarchetype:generate\
>   -DarchetypeRepository=http://scala-tools.org/repo-snapshots\
>   -DremoteRepositories=http://scala-tools.org/repo-snapshots\
>   -DarchetypeGroupId=net.liftweb \
>   -DarchetypeArtifactId=lift-archetype-blank \
>   -DarchetypeVersion=1.1-SNAPSHOT \
>   -DgroupId=com.mypackage \
>   -DartifactId=myproject \
>   -Dversion=1.0-SNAPSHOT
>
> Currently, the possible archetypeArtifactId are:
>   - lift-archetype-blank
>   - lift-archetype-basic
>   - lift-archetype-jpa-blank-single
>   - lift-archetype-jpa-blank
>   - lift-archetype-jpa-basic
>
> If you create project interactively (default behavior), -DgroupId, -
> DartifactId, -Dversion are optional. Maven would prompt for these
> values (and some more) interactively.
>
> On the other hand, if you are using a batch/shell script togenerate
> project non-interactively, you would need to add at least -DgroupId, -
> DartifactId and additionally set -DinteractiveMode=false.
>
> Cheers, Indrajit
>
> References:
> [1]http://maven.apache.org/plugins/maven-archetype-plugin/specification/...
> [2]http://maven.apache.org/plugins/maven-archetype-plugin/generate-mojo
> [3]http://maven.apache.org/plugins/maven-archetype-plugin/create-mojo.html

--

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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

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

[David Pollak]

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 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:
> >>
> >> > >> > 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?
> >>
> >> > >> It's something to do with how the login form is processed - at the
> >> > >> moment I haven't figured out anything more with that. Essentially,
> the
> >> > >> login fails silently and returns the user to the login form upon
> >> > >> submission.
> >>
> >> > > That sounds like a deeper issue with MetaProtoUser.  I'd keep your
> >> > changes
> >> > > and see why MegaProtoUser is failing.
> >>
> >> > Absolutely; I just figured I didn't want to leave people with broken
> >> > code while I figure it out since I'm not that familiar with
> >> > MegaProtoUser and am not sure how long that will take.
> >>
> >> Please check the code back in and get me a test case and I'll debug it.
> >>
> >> I've got about 20 tickets I'm working on right now... one more ain't
> gonna
> >> kill me. ;-)
> >
> > 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 never called on
> > form post, so the login method is never called during post. I assume
> > this worked before?
> > 2) If I change the bind for login to include a function that calls
> > login on submit, the login process works
> >
> > Not sure what the correct semantics are wrt 1) abovebut something
> > definately seem to have changed...
> >
> > /Jeppe
>
> I just noticed that David committed a fix. Thanks, David!
>

Certainly.  And thank you for your excellent enhancements to SiteMap.
Sometimes there's minor pain when there's forward progress... I'm here to
support thoughtful changes and the community when those changes have minor
issues.


>
> Kris
>
> --
>
> 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.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>


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

--

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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.

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

[Kris Nuttycombe]

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 Nuttycombe <
>> > kris.nuttyco...@gmail.com>
>> > > 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 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?
>>
>> > >> It's something to do with how the login form is processed - at the
>> > >> moment I haven't figured out anything more with that. Essentially, the
>> > >> login fails silently and returns the user to the login form upon
>> > >> submission.
>>
>> > > That sounds like a deeper issue with MetaProtoUser.  I'd keep your
>> > changes
>> > > and see why MegaProtoUser is failing.
>>
>> > Absolutely; I just figured I didn't want to leave people with broken
>> > code while I figure it out since I'm not that familiar with
>> > MegaProtoUser and am not sure how long that will take.
>>
>> Please check the code back in and get me a test case and I'll debug it.
>>
>> I've got about 20 tickets I'm working on right now... one more ain't gonna
>> kill me. ;-)
>
> 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 never called on
> form post, so the login method is never called during post. I assume
> this worked before?
> 2) If I change the bind for login to include a function that calls
> login on submit, the login process works
>
> Not sure what the correct semantics are wrt 1) abovebut something
> definately seem to have changed...
>
> /Jeppe

I just noticed that David committed a fix. Thanks, David!

Kris

--

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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.

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

[Jeppe Nejsum Madsen]

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 never called on
> form post, so the login method is never called during post. I assume
> this worked before?
> 2) If I change the bind for login to include a function that calls
> login on submit, the login process works

Saw your post in the other thread. The latest update seems to have
solved the issue...

/Jeppe

--

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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.

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

[Jeppe Nejsum Madsen]

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 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?
>
> > >> It's something to do with how the login form is processed - at the
> > >> moment I haven't figured out anything more with that. Essentially, the
> > >> login fails silently and returns the user to the login form upon
> > >> submission.
>
> > > That sounds like a deeper issue with MetaProtoUser.  I'd keep your
> > changes
> > > and see why MegaProtoUser is failing.
>
> > Absolutely; I just figured I didn't want to leave people with broken
> > code while I figure it out since I'm not that familiar with
> > MegaProtoUser and am not sure how long that will take.
>
> Please check the code back in and get me a test case and I'll debug it.
>
> I've got about 20 tickets I'm working on right now... one more ain't gonna
> kill me. ;-)

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 never called on
form post, so the login method is never called during post. I assume
this worked before?
2) If I change the bind for login to include a function that calls
login on submit, the login process works

Not sure what the correct semantics are wrt 1) abovebut something
definately seem to have changed...

/Jeppe

--

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.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.

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

[Kris Nuttycombe]

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 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?
>> >>
>> >> It's something to do with how the login form is processed - at the
>> >> moment I haven't figured out anything more with that. Essentially, the
>> >> login fails silently and returns the user to the login form upon
>> >> submission.
>> >
>> > That sounds like a deeper issue with MetaProtoUser.  I'd keep your
>> > changes
>> > and see why MegaProtoUser is failing.
>>
>> Absolutely; I just figured I didn't want to leave people with broken
>> code while I figure it out since I'm not that familiar with
>> MegaProtoUser and am not sure how long that will take.
>
> Please check the code back in and get me a test case and I'll debug it.
>
> I've got about 20 tickets I'm working on right now... one more ain't gonna
> kill me. ;-)

Reverted my reversion. The test case is an easy one: login in
hellolift displays the pathology.

Thanks for your help,

Kris

>>
>> > Also, it's best that people discuss these kinds of things on list rather
>> > than contacting you privately so we can all see what's going on.
>> >
>>
>> Totally agree. I should have made that more clear in the initial email.
>>
>> Kriis
>>
>> >>
>> >> Kris
>> >>
>> >> >
>> >> >>
>> >> >> 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
>> >> >> > involves a number of breaking changes. The changes and their
>> >> >> > rationale
>> >> >> > is listed below. Unless you have created your own subclasses of
>> >> >> > Loc
>> >> >> > or
>> >> >> > LocParam, these changes should not have any repercussions for you.
>> >> >> > If
>> >> >> > the effect of any of these changes on your particular codebase are
>> >> >> > excessively disruptive, please contact me and I will work with you
>> >> >> > to
>> >> >> > resolve the issue.
>> >> >> >
>> >> >> > Breaking Changes:
>> >> >> >
>> >> >> > 1) LocParam
>> >> >> >
>> >> >> > LocParam has been made a sealed trait to facilitate pattern
>> >> >> > matching
>> >> >> > within the Lift codebase and has had a contravariant type
>> >> >> > parameter
>> >> >> > added to its type to facilitate typesafe interactions with Loc[T].
>> >> >> > The
>> >> >> > new trait is hence LocParam[-T]. As LocParam is now a sealed
>> >> >> > trait, I
>> >> >> > have added an extension point for user-specified LocParam subtypes
>> >> >> > as
>> >> >> > UserLocParam[-T] extends LocParam[T]. Since the new type parameter
>> >> >> > is
>> >> >> > contravariant, LocParam subclasses that are applicable for any
>> >> >> > Loc[T]
>> >> >> > have the type LocParam[Any], and a type alias AnyLocParam has been
>> >> >> > added for this type.
>> >> >> >
>> >> >> > The Loc.checkProtected method now enforces type consistency
>> >> >> > between
>> >> >> > the evaluated Link[T] and the list of LocParam[T] which are used
>> >> >> > to
>> >> >> > evaluate whether the link is accessible given the specified
>> >> >> > parameters.
>> >> >> >
>> >> >> > 2) Renames
>> >> >> >
>> >> >> > Previously, the "Param" suffix was used for two unrelated purposes
>> >> >> > within Loc: first, to refer to the type parameter of the Loc, and
>> >> >> > secondly for the LocParam configuration. This overloading made the
>> >> >> > code and the API somewhat difficult to read, so the first usage
>> >> >> > has
>> >> >> > been removed resulting in the following renames:
>> >> >> >
>> >> >> > ParamType => T
>> >> >> > NullLocParams => //removed, Unit is sufficient!
>> >> >> > Loc.defaultParams => Loc.defaultValue
>> >> >> > Loc.forceParam => Loc.overrideValue
>> >> >> > Loc.foundParam => Loc.requestValue
>> >> >> > Loc.additionalKidParams => Loc.childValues
>> >> >> >
>> >> >> > After this change, all instances of the "param" name within Loc
>> >> >> > should
>> >> >> > refer to something having to do with LocParam instances.
>> >> >> >
>> >> >> > Non-Breaking Additions:
>> >> >> >
>> >> >> > case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
>> >> >> > extends LocParam[T]
>> >> >> > case class UnlessValue[T](test: Box[T] => Boolean, failMsg:
>> >> >> > FailMsg)
>> >> >> > extends LocParam[T]
>> >> >> > case class TestValueAccess[T](func: Box[T] => Box[LiftResponse])
>> >> >> > extends LocParam[T]
>> >> >> >
>> >> >> > If you are using a non-Unit

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

[David Pollak]

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:
> >> >
> >> >
> >> > 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?
> >>
> >> It's something to do with how the login form is processed - at the
> >> moment I haven't figured out anything more with that. Essentially, the
> >> login fails silently and returns the user to the login form upon
> >> submission.
> >
> > That sounds like a deeper issue with MetaProtoUser.  I'd keep your
> changes
> > and see why MegaProtoUser is failing.
>
> Absolutely; I just figured I didn't want to leave people with broken
> code while I figure it out since I'm not that familiar with
> MegaProtoUser and am not sure how long that will take.
>

Please check the code back in and get me a test case and I'll debug it.

I've got about 20 tickets I'm working on right now... one more ain't gonna
kill me. ;-)


>
> > Also, it's best that people discuss these kinds of things on list rather
> > than contacting you privately so we can all see what's going on.
> >
>
> Totally agree. I should have made that more clear in the initial email.
>
> Kriis
>
> >>
> >> Kris
> >>
> >> >
> >> >>
> >> >> 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
> >> >> > involves a number of breaking changes. The changes and their
> >> >> > rationale
> >> >> > is listed below. Unless you have created your own subclasses of Loc
> >> >> > or
> >> >> > LocParam, these changes should not have any repercussions for you.
> If
> >> >> > the effect of any of these changes on your particular codebase are
> >> >> > excessively disruptive, please contact me and I will work with you
> to
> >> >> > resolve the issue.
> >> >> >
> >> >> > Breaking Changes:
> >> >> >
> >> >> > 1) LocParam
> >> >> >
> >> >> > LocParam has been made a sealed trait to facilitate pattern
> matching
> >> >> > within the Lift codebase and has had a contravariant type parameter
> >> >> > added to its type to facilitate typesafe interactions with Loc[T].
> >> >> > The
> >> >> > new trait is hence LocParam[-T]. As LocParam is now a sealed trait,
> I
> >> >> > have added an extension point for user-specified LocParam subtypes
> as
> >> >> > UserLocParam[-T] extends LocParam[T]. Since the new type parameter
> is
> >> >> > contravariant, LocParam subclasses that are applicable for any
> Loc[T]
> >> >> > have the type LocParam[Any], and a type alias AnyLocParam has been
> >> >> > added for this type.
> >> >> >
> >> >> > The Loc.checkProtected method now enforces type consistency between
> >> >> > the evaluated Link[T] and the list of LocParam[T] which are used to
> >> >> > evaluate whether the link is accessible given the specified
> >> >> > parameters.
> >> >> >
> >> >> > 2) Renames
> >> >> >
> >> >> > Previously, the "Param" suffix was used for two unrelated purposes
> >> >> > within Loc: first, to refer to the type parameter of the Loc, and
> >> >> > secondly for the LocParam configuration. This overloading made the
> >> >> > code and the API somewhat difficult to read, so the first usage has
> >> >> > been removed resulting in the following renames:
> >> >> >
> >> >> > ParamType => T
> >> >> > NullLocParams => //removed, Unit is sufficient!
> >> >> > Loc.defaultParams => Loc.defaultValue
> >> >> > Loc.forceParam => Loc.overrideValue
> >> >> > Loc.foundParam => Loc.requestValue
> >> >> > Loc.additionalKidParams => Loc.childValues
> >> >> >
> >> >> > After this change, all instances of the "param" name within Loc
> >> >> > should
> >> >> > refer to something having to do with LocParam instances.
> >> >> >
> >> >> > Non-Breaking Additions:
> >> >> >
> >> >> > case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
> >> >> > extends LocParam[T]
> >> >> > case class UnlessValue[T](test: Box[T] => Boolean, failMsg:
> FailMsg)
> >> >> > extends LocParam[T]
> >> >> > case class TestValueAccess[T](func: Box[T] => Box[LiftResponse])
> >> >> > extends LocParam[T]
> >> >> >
> >> >> > If you are using a non-Unit typed Loc, you can use these LocParam
> >> >> > instances to enforce access rules at the value level.
> >> >> >
> >> >> > case class ValueTemplate[T](template: Box[T] => NodeSeq) extends
> >> >> > LocParam[T] //per-value template selection
> >> >> >
> >> >> > DataLoc[T] subclass of Loc was added to facilitate the use of the
> new
> >> >> > more typeful LocParam subtypes.
> >> >> >
> >> >> > A few changes to Link:
> >

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

[Kris Nuttycombe]

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 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?
>>
>> It's something to do with how the login form is processed - at the
>> moment I haven't figured out anything more with that. Essentially, the
>> login fails silently and returns the user to the login form upon
>> submission.
>
> That sounds like a deeper issue with MetaProtoUser.  I'd keep your changes
> and see why MegaProtoUser is failing.

Absolutely; I just figured I didn't want to leave people with broken
code while I figure it out since I'm not that familiar with
MegaProtoUser and am not sure how long that will take.

> Also, it's best that people discuss these kinds of things on list rather
> than contacting you privately so we can all see what's going on.
>

Totally agree. I should have made that more clear in the initial email.

Kriis

>>
>> Kris
>>
>> >
>> >>
>> >> 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
>> >> > involves a number of breaking changes. The changes and their
>> >> > rationale
>> >> > is listed below. Unless you have created your own subclasses of Loc
>> >> > or
>> >> > LocParam, these changes should not have any repercussions for you. If
>> >> > the effect of any of these changes on your particular codebase are
>> >> > excessively disruptive, please contact me and I will work with you to
>> >> > resolve the issue.
>> >> >
>> >> > Breaking Changes:
>> >> >
>> >> > 1) LocParam
>> >> >
>> >> > LocParam has been made a sealed trait to facilitate pattern matching
>> >> > within the Lift codebase and has had a contravariant type parameter
>> >> > added to its type to facilitate typesafe interactions with Loc[T].
>> >> > The
>> >> > new trait is hence LocParam[-T]. As LocParam is now a sealed trait, I
>> >> > have added an extension point for user-specified LocParam subtypes as
>> >> > UserLocParam[-T] extends LocParam[T]. Since the new type parameter is
>> >> > contravariant, LocParam subclasses that are applicable for any Loc[T]
>> >> > have the type LocParam[Any], and a type alias AnyLocParam has been
>> >> > added for this type.
>> >> >
>> >> > The Loc.checkProtected method now enforces type consistency between
>> >> > the evaluated Link[T] and the list of LocParam[T] which are used to
>> >> > evaluate whether the link is accessible given the specified
>> >> > parameters.
>> >> >
>> >> > 2) Renames
>> >> >
>> >> > Previously, the "Param" suffix was used for two unrelated purposes
>> >> > within Loc: first, to refer to the type parameter of the Loc, and
>> >> > secondly for the LocParam configuration. This overloading made the
>> >> > code and the API somewhat difficult to read, so the first usage has
>> >> > been removed resulting in the following renames:
>> >> >
>> >> > ParamType => T
>> >> > NullLocParams => //removed, Unit is sufficient!
>> >> > Loc.defaultParams => Loc.defaultValue
>> >> > Loc.forceParam => Loc.overrideValue
>> >> > Loc.foundParam => Loc.requestValue
>> >> > Loc.additionalKidParams => Loc.childValues
>> >> >
>> >> > After this change, all instances of the "param" name within Loc
>> >> > should
>> >> > refer to something having to do with LocParam instances.
>> >> >
>> >> > Non-Breaking Additions:
>> >> >
>> >> > case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
>> >> > extends LocParam[T]
>> >> > case class UnlessValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
>> >> > extends LocParam[T]
>> >> > case class TestValueAccess[T](func: Box[T] => Box[LiftResponse])
>> >> > extends LocParam[T]
>> >> >
>> >> > If you are using a non-Unit typed Loc, you can use these LocParam
>> >> > instances to enforce access rules at the value level.
>> >> >
>> >> > case class ValueTemplate[T](template: Box[T] => NodeSeq) extends
>> >> > LocParam[T] //per-value template selection
>> >> >
>> >> > DataLoc[T] subclass of Loc was added to facilitate the use of the new
>> >> > more typeful LocParam subtypes.
>> >> >
>> >> > A few changes to Link:
>> >> >
>> >> > Since Link.createLink creates a Box[Text] (and not a clickable link)
>> >> > a
>> >> > couple of methods were added to create the intermediate, unboxed
>> >> > values in order that subclasses can more easily manipulate the
>> >> > resulting
>> >> > path:
>> >> >
>> >> > Link.pathList(value: T): List[String] // added to facilitate creation
>> >> > of value-aware paths by subclasses.
>> >> > Link.createPath(value: T): String //creates the String representation
>> >> > of the path that is subsequently 

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

[David Pollak]

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 MetaMegaProtoUser
> >> interaction. I've reverted the commit until I can get that sorted out.
> >
> > How was it broken?
>
> It's something to do with how the login form is processed - at the
> moment I haven't figured out anything more with that. Essentially, the
> login fails silently and returns the user to the login form upon
> submission.
>

That sounds like a deeper issue with MetaProtoUser.  I'd keep your changes
and see why MegaProtoUser is failing.

Also, it's best that people discuss these kinds of things on list rather
than contacting you privately so we can all see what's going on.


>
> Kris
>
> >
> >>
> >> 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
> >> > involves a number of breaking changes. The changes and their rationale
> >> > is listed below. Unless you have created your own subclasses of Loc or
> >> > LocParam, these changes should not have any repercussions for you. If
> >> > the effect of any of these changes on your particular codebase are
> >> > excessively disruptive, please contact me and I will work with you to
> >> > resolve the issue.
> >> >
> >> > Breaking Changes:
> >> >
> >> > 1) LocParam
> >> >
> >> > LocParam has been made a sealed trait to facilitate pattern matching
> >> > within the Lift codebase and has had a contravariant type parameter
> >> > added to its type to facilitate typesafe interactions with Loc[T]. The
> >> > new trait is hence LocParam[-T]. As LocParam is now a sealed trait, I
> >> > have added an extension point for user-specified LocParam subtypes as
> >> > UserLocParam[-T] extends LocParam[T]. Since the new type parameter is
> >> > contravariant, LocParam subclasses that are applicable for any Loc[T]
> >> > have the type LocParam[Any], and a type alias AnyLocParam has been
> >> > added for this type.
> >> >
> >> > The Loc.checkProtected method now enforces type consistency between
> >> > the evaluated Link[T] and the list of LocParam[T] which are used to
> >> > evaluate whether the link is accessible given the specified
> >> > parameters.
> >> >
> >> > 2) Renames
> >> >
> >> > Previously, the "Param" suffix was used for two unrelated purposes
> >> > within Loc: first, to refer to the type parameter of the Loc, and
> >> > secondly for the LocParam configuration. This overloading made the
> >> > code and the API somewhat difficult to read, so the first usage has
> >> > been removed resulting in the following renames:
> >> >
> >> > ParamType => T
> >> > NullLocParams => //removed, Unit is sufficient!
> >> > Loc.defaultParams => Loc.defaultValue
> >> > Loc.forceParam => Loc.overrideValue
> >> > Loc.foundParam => Loc.requestValue
> >> > Loc.additionalKidParams => Loc.childValues
> >> >
> >> > After this change, all instances of the "param" name within Loc should
> >> > refer to something having to do with LocParam instances.
> >> >
> >> > Non-Breaking Additions:
> >> >
> >> > case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
> >> > extends LocParam[T]
> >> > case class UnlessValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
> >> > extends LocParam[T]
> >> > case class TestValueAccess[T](func: Box[T] => Box[LiftResponse])
> >> > extends LocParam[T]
> >> >
> >> > If you are using a non-Unit typed Loc, you can use these LocParam
> >> > instances to enforce access rules at the value level.
> >> >
> >> > case class ValueTemplate[T](template: Box[T] => NodeSeq) extends
> >> > LocParam[T] //per-value template selection
> >> >
> >> > DataLoc[T] subclass of Loc was added to facilitate the use of the new
> >> > more typeful LocParam subtypes.
> >> >
> >> > A few changes to Link:
> >> >
> >> > Since Link.createLink creates a Box[Text] (and not a clickable link) a
> >> > couple of methods were added to create the intermediate, unboxed
> >> > values in order that subclasses can more easily manipulate the
> resulting
> >> > path:
> >> >
> >> > Link.pathList(value: T): List[String] // added to facilitate creation
> >> > of value-aware paths by subclasses.
> >> > Link.createPath(value: T): String //creates the String representation
> >> > of the path that is subsequently turned into XML and boxed by
> >> > Link.createLink
> >> >
> >> > Again, please let me know if any of these changes cause you headaches!
> >> > My hope is that much of the modified functionality has not been used
> >> > by very many people yet and that as a result it's a good time to make
> >> > these changes before typeful Locs get too widely used to make breaking
> >> > changes.
> >> >
> >> > Thanks,
> >> >
> >> > Kris
> >> >
> >>
> >>
> >
> >
> >
> > --
> 

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

[Kris Nuttycombe]

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?

It's something to do with how the login form is processed - at the
moment I haven't figured out anything more with that. Essentially, the
login fails silently and returns the user to the login form upon
submission.

Kris

>
>>
>> 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
>> > involves a number of breaking changes. The changes and their rationale
>> > is listed below. Unless you have created your own subclasses of Loc or
>> > LocParam, these changes should not have any repercussions for you. If
>> > the effect of any of these changes on your particular codebase are
>> > excessively disruptive, please contact me and I will work with you to
>> > resolve the issue.
>> >
>> > Breaking Changes:
>> >
>> > 1) LocParam
>> >
>> > LocParam has been made a sealed trait to facilitate pattern matching
>> > within the Lift codebase and has had a contravariant type parameter
>> > added to its type to facilitate typesafe interactions with Loc[T]. The
>> > new trait is hence LocParam[-T]. As LocParam is now a sealed trait, I
>> > have added an extension point for user-specified LocParam subtypes as
>> > UserLocParam[-T] extends LocParam[T]. Since the new type parameter is
>> > contravariant, LocParam subclasses that are applicable for any Loc[T]
>> > have the type LocParam[Any], and a type alias AnyLocParam has been
>> > added for this type.
>> >
>> > The Loc.checkProtected method now enforces type consistency between
>> > the evaluated Link[T] and the list of LocParam[T] which are used to
>> > evaluate whether the link is accessible given the specified
>> > parameters.
>> >
>> > 2) Renames
>> >
>> > Previously, the "Param" suffix was used for two unrelated purposes
>> > within Loc: first, to refer to the type parameter of the Loc, and
>> > secondly for the LocParam configuration. This overloading made the
>> > code and the API somewhat difficult to read, so the first usage has
>> > been removed resulting in the following renames:
>> >
>> > ParamType => T
>> > NullLocParams => //removed, Unit is sufficient!
>> > Loc.defaultParams => Loc.defaultValue
>> > Loc.forceParam => Loc.overrideValue
>> > Loc.foundParam => Loc.requestValue
>> > Loc.additionalKidParams => Loc.childValues
>> >
>> > After this change, all instances of the "param" name within Loc should
>> > refer to something having to do with LocParam instances.
>> >
>> > Non-Breaking Additions:
>> >
>> > case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
>> > extends LocParam[T]
>> > case class UnlessValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
>> > extends LocParam[T]
>> > case class TestValueAccess[T](func: Box[T] => Box[LiftResponse])
>> > extends LocParam[T]
>> >
>> > If you are using a non-Unit typed Loc, you can use these LocParam
>> > instances to enforce access rules at the value level.
>> >
>> > case class ValueTemplate[T](template: Box[T] => NodeSeq) extends
>> > LocParam[T] //per-value template selection
>> >
>> > DataLoc[T] subclass of Loc was added to facilitate the use of the new
>> > more typeful LocParam subtypes.
>> >
>> > A few changes to Link:
>> >
>> > Since Link.createLink creates a Box[Text] (and not a clickable link) a
>> > couple of methods were added to create the intermediate, unboxed
>> > values in order that subclasses can more easily manipulate the resulting
>> > path:
>> >
>> > Link.pathList(value: T): List[String] // added to facilitate creation
>> > of value-aware paths by subclasses.
>> > Link.createPath(value: T): String //creates the String representation
>> > of the path that is subsequently turned into XML and boxed by
>> > Link.createLink
>> >
>> > Again, please let me know if any of these changes cause you headaches!
>> > My hope is that much of the modified functionality has not been used
>> > by very many people yet and that as a result it's a good time to make
>> > these changes before typeful Locs get too widely used to make breaking
>> > changes.
>> >
>> > Thanks,
>> >
>> > Kris
>> >
>>
>>
>
>
>
> --
> 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 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] Re: *** BREAKING CHANGES *** to Loc & LocParam

[David Pollak]

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 Nuttycombe
>  wrote:
> > Hi, all,
> >
> > I have committed a number of enhancements to Loc & LocParam which
> > involves a number of breaking changes. The changes and their rationale
> > is listed below. Unless you have created your own subclasses of Loc or
> > LocParam, these changes should not have any repercussions for you. If
> > the effect of any of these changes on your particular codebase are
> > excessively disruptive, please contact me and I will work with you to
> > resolve the issue.
> >
> > Breaking Changes:
> >
> > 1) LocParam
> >
> > LocParam has been made a sealed trait to facilitate pattern matching
> > within the Lift codebase and has had a contravariant type parameter
> > added to its type to facilitate typesafe interactions with Loc[T]. The
> > new trait is hence LocParam[-T]. As LocParam is now a sealed trait, I
> > have added an extension point for user-specified LocParam subtypes as
> > UserLocParam[-T] extends LocParam[T]. Since the new type parameter is
> > contravariant, LocParam subclasses that are applicable for any Loc[T]
> > have the type LocParam[Any], and a type alias AnyLocParam has been
> > added for this type.
> >
> > The Loc.checkProtected method now enforces type consistency between
> > the evaluated Link[T] and the list of LocParam[T] which are used to
> > evaluate whether the link is accessible given the specified
> > parameters.
> >
> > 2) Renames
> >
> > Previously, the "Param" suffix was used for two unrelated purposes
> > within Loc: first, to refer to the type parameter of the Loc, and
> > secondly for the LocParam configuration. This overloading made the
> > code and the API somewhat difficult to read, so the first usage has
> > been removed resulting in the following renames:
> >
> > ParamType => T
> > NullLocParams => //removed, Unit is sufficient!
> > Loc.defaultParams => Loc.defaultValue
> > Loc.forceParam => Loc.overrideValue
> > Loc.foundParam => Loc.requestValue
> > Loc.additionalKidParams => Loc.childValues
> >
> > After this change, all instances of the "param" name within Loc should
> > refer to something having to do with LocParam instances.
> >
> > Non-Breaking Additions:
> >
> > case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
> > extends LocParam[T]
> > case class UnlessValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
> > extends LocParam[T]
> > case class TestValueAccess[T](func: Box[T] => Box[LiftResponse])
> > extends LocParam[T]
> >
> > If you are using a non-Unit typed Loc, you can use these LocParam
> > instances to enforce access rules at the value level.
> >
> > case class ValueTemplate[T](template: Box[T] => NodeSeq) extends
> > LocParam[T] //per-value template selection
> >
> > DataLoc[T] subclass of Loc was added to facilitate the use of the new
> > more typeful LocParam subtypes.
> >
> > A few changes to Link:
> >
> > Since Link.createLink creates a Box[Text] (and not a clickable link) a
> > couple of methods were added to create the intermediate, unboxed
> > values in order that subclasses can more easily manipulate the resulting
> path:
> >
> > Link.pathList(value: T): List[String] // added to facilitate creation
> > of value-aware paths by subclasses.
> > Link.createPath(value: T): String //creates the String representation
> > of the path that is subsequently turned into XML and boxed by
> > Link.createLink
> >
> > Again, please let me know if any of these changes cause you headaches!
> > My hope is that much of the modified functionality has not been used
> > by very many people yet and that as a result it's a good time to make
> > these changes before typeful Locs get too widely used to make breaking
> > changes.
> >
> > Thanks,
> >
> > Kris
> >
>
> >
>


-- 
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 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] Re: *** BREAKING CHANGES *** to Loc & LocParam

[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
 wrote:
> Hi, all,
>
> I have committed a number of enhancements to Loc & LocParam which
> involves a number of breaking changes. The changes and their rationale
> is listed below. Unless you have created your own subclasses of Loc or
> LocParam, these changes should not have any repercussions for you. If
> the effect of any of these changes on your particular codebase are
> excessively disruptive, please contact me and I will work with you to
> resolve the issue.
>
> Breaking Changes:
>
> 1) LocParam
>
> LocParam has been made a sealed trait to facilitate pattern matching
> within the Lift codebase and has had a contravariant type parameter
> added to its type to facilitate typesafe interactions with Loc[T]. The
> new trait is hence LocParam[-T]. As LocParam is now a sealed trait, I
> have added an extension point for user-specified LocParam subtypes as
> UserLocParam[-T] extends LocParam[T]. Since the new type parameter is
> contravariant, LocParam subclasses that are applicable for any Loc[T]
> have the type LocParam[Any], and a type alias AnyLocParam has been
> added for this type.
>
> The Loc.checkProtected method now enforces type consistency between
> the evaluated Link[T] and the list of LocParam[T] which are used to
> evaluate whether the link is accessible given the specified
> parameters.
>
> 2) Renames
>
> Previously, the "Param" suffix was used for two unrelated purposes
> within Loc: first, to refer to the type parameter of the Loc, and
> secondly for the LocParam configuration. This overloading made the
> code and the API somewhat difficult to read, so the first usage has
> been removed resulting in the following renames:
>
> ParamType => T
> NullLocParams => //removed, Unit is sufficient!
> Loc.defaultParams => Loc.defaultValue
> Loc.forceParam => Loc.overrideValue
> Loc.foundParam => Loc.requestValue
> Loc.additionalKidParams => Loc.childValues
>
> After this change, all instances of the "param" name within Loc should
> refer to something having to do with LocParam instances.
>
> Non-Breaking Additions:
>
> case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
> extends LocParam[T]
> case class UnlessValue[T](test: Box[T] => Boolean, failMsg: FailMsg)
> extends LocParam[T]
> case class TestValueAccess[T](func: Box[T] => Box[LiftResponse])
> extends LocParam[T]
>
> If you are using a non-Unit typed Loc, you can use these LocParam
> instances to enforce access rules at the value level.
>
> case class ValueTemplate[T](template: Box[T] => NodeSeq) extends
> LocParam[T] //per-value template selection
>
> DataLoc[T] subclass of Loc was added to facilitate the use of the new
> more typeful LocParam subtypes.
>
> A few changes to Link:
>
> Since Link.createLink creates a Box[Text] (and not a clickable link) a
> couple of methods were added to create the intermediate, unboxed
> values in order that subclasses can more easily manipulate the resulting path:
>
> Link.pathList(value: T): List[String] // added to facilitate creation
> of value-aware paths by subclasses.
> Link.createPath(value: T): String //creates the String representation
> of the path that is subsequently turned into XML and boxed by
> Link.createLink
>
> Again, please let me know if any of these changes cause you headaches!
> My hope is that much of the modified functionality has not been used
> by very many people yet and that as a result it's a good time to make
> these changes before typeful Locs get too widely used to make breaking
> changes.
>
> Thanks,
>
> Kris
>

--~--~-~--~~~---~--~~
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: **Breaking Changes** **README** **Important**

[David Pollak]

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 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 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 change.  I guess I should move the XMPP
>> stuff over.
>>
>>
>>> If not is it possible that Scala Actors communicate with Lift Actors?
>>> At the moment I don't get my project to compile due to some type
>>> mismatch errors but that might also be my lack of understanding
>>> of the different Actor implementations.
>>>
>>> Thanks,
>>> ssid
>>>
>>> On 22 Okt., 05:37, David Pollak  wrote:
>>> > 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
>>> of
>>> > traits that allow Lift to use its own Actors or Akka Actors (or
>>> anything
>>> > else that implements that interface.)
>>> >
>>> > The two big changes that you'll have to work with are:
>>> >
>>> >- Box/Full/Empty/Failure was moved from the
>>> lift-util/net.liftweb.util
>>> >package to the lift-common/net.liftweb.common package.  The reason
>>> for this
>>> >change is that we're going to make the lift-common package a more
>>> generic,
>>> >non-web related package.  It currently contains Box and Actor, but
>>> in the
>>> >future may contain other interfaces that will have concrete
>>> implementations
>>> >outside of Lift.  We moved Box there because Box is richer than
>>> Scala's
>>> >Option class and being able to carry Exceptions around in a Box
>>> while still
>>> >being able to map/flatMap/foreach over a Box (these are unavailable
>>> for
>>> >Scala's Either).  Some we're going to actively promote using Box as
>>> a
>>> >replacement for Option in all Scala apps.  What this means for you
>>> is you
>>> >have to import net.liftweb.common._ in any file that you also import
>>> >net.liftweb.util.?
>>> >- Lift no longer support Scala Actors for Comet Actors.  The
>>> GenericActor
>>> >API offers pretty much the same client interface to Lift's Actors,
>>> so ! and
>>> >!? work the same way.  However, there's no link, self, start or exit
>>> >methods.
>>> >
>>> > Please do an "mvn -U clean install" on your code and run it against the
>>> new
>>> > code.  If you have any Comet-related weirdness, please report it
>>> > immediately.  We're planning M7 in 2 weeks, so we've got lots of time
>>> to
>>> > iron any kinks out of this code.
>>> >
>>> > Thanks,
>>> >
>>> > David
>>> >
>>> > --
>>> > 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
>>>
>>>
>>>
>>
>>
>> --
>> 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 harmonics
>>
>>
>>
>
> >
>


-- 
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 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] Re: **Breaking Changes** **README** **Important**

[Jonathan Ferguson]

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 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 change.  I guess I should move the XMPP
> stuff over.
>
>
>> If not is it possible that Scala Actors communicate with Lift Actors?
>> At the moment I don't get my project to compile due to some type
>> mismatch errors but that might also be my lack of understanding
>> of the different Actor implementations.
>>
>> Thanks,
>> ssid
>>
>> On 22 Okt., 05:37, David Pollak  wrote:
>> > 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 of
>> > traits that allow Lift to use its own Actors or Akka Actors (or anything
>> > else that implements that interface.)
>> >
>> > The two big changes that you'll have to work with are:
>> >
>> >- Box/Full/Empty/Failure was moved from the
>> lift-util/net.liftweb.util
>> >package to the lift-common/net.liftweb.common package.  The reason
>> for this
>> >change is that we're going to make the lift-common package a more
>> generic,
>> >non-web related package.  It currently contains Box and Actor, but in
>> the
>> >future may contain other interfaces that will have concrete
>> implementations
>> >outside of Lift.  We moved Box there because Box is richer than
>> Scala's
>> >Option class and being able to carry Exceptions around in a Box while
>> still
>> >being able to map/flatMap/foreach over a Box (these are unavailable
>> for
>> >Scala's Either).  Some we're going to actively promote using Box as a
>> >replacement for Option in all Scala apps.  What this means for you is
>> you
>> >have to import net.liftweb.common._ in any file that you also import
>> >net.liftweb.util.?
>> >- Lift no longer support Scala Actors for Comet Actors.  The
>> GenericActor
>> >API offers pretty much the same client interface to Lift's Actors, so
>> ! and
>> >!? work the same way.  However, there's no link, self, start or exit
>> >methods.
>> >
>> > Please do an "mvn -U clean install" on your code and run it against the
>> new
>> > code.  If you have any Comet-related weirdness, please report it
>> > immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
>> > iron any kinks out of this code.
>> >
>> > Thanks,
>> >
>> > David
>> >
>> > --
>> > 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
>>
>>
>>
>
>
> --
> 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 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] Re: **Breaking Changes** **README** **Important**

[David Pollak]

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 change.  I guess I should move the XMPP
stuff over.


> If not is it possible that Scala Actors communicate with Lift Actors?
> At the moment I don't get my project to compile due to some type
> mismatch errors but that might also be my lack of understanding
> of the different Actor implementations.
>
> Thanks,
> ssid
>
> On 22 Okt., 05:37, David Pollak  wrote:
> > 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 of
> > traits that allow Lift to use its own Actors or Akka Actors (or anything
> > else that implements that interface.)
> >
> > The two big changes that you'll have to work with are:
> >
> >- Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util
> >package to the lift-common/net.liftweb.common package.  The reason for
> this
> >change is that we're going to make the lift-common package a more
> generic,
> >non-web related package.  It currently contains Box and Actor, but in
> the
> >future may contain other interfaces that will have concrete
> implementations
> >outside of Lift.  We moved Box there because Box is richer than
> Scala's
> >Option class and being able to carry Exceptions around in a Box while
> still
> >being able to map/flatMap/foreach over a Box (these are unavailable
> for
> >Scala's Either).  Some we're going to actively promote using Box as a
> >replacement for Option in all Scala apps.  What this means for you is
> you
> >have to import net.liftweb.common._ in any file that you also import
> >net.liftweb.util.?
> >- Lift no longer support Scala Actors for Comet Actors.  The
> GenericActor
> >API offers pretty much the same client interface to Lift's Actors, so
> ! and
> >!? work the same way.  However, there's no link, self, start or exit
> >methods.
> >
> > Please do an "mvn -U clean install" on your code and run it against the
> new
> > code.  If you have any Comet-related weirdness, please report it
> > immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
> > iron any kinks out of this code.
> >
> > Thanks,
> >
> > David
> >
> > --
> > 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
>
> >
>


-- 
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 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] Re: **Breaking Changes** **README** **Important**

[David Pollak]

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: [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 my project to compile due to some type
> mismatch errors but that might also be my lack of understanding
> of the different Actor implementations.
>
> Thanks,
> ssid
>
> On 22 Okt., 05:37, David Pollak  wrote:
> > 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 of
> > traits that allow Lift to use its own Actors or Akka Actors (or anything
> > else that implements that interface.)
> >
> > The two big changes that you'll have to work with are:
> >
> >- Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util
> >package to the lift-common/net.liftweb.common package.  The reason for
> this
> >change is that we're going to make the lift-common package a more
> generic,
> >non-web related package.  It currently contains Box and Actor, but in
> the
> >future may contain other interfaces that will have concrete
> implementations
> >outside of Lift.  We moved Box there because Box is richer than
> Scala's
> >Option class and being able to carry Exceptions around in a Box while
> still
> >being able to map/flatMap/foreach over a Box (these are unavailable
> for
> >Scala's Either).  Some we're going to actively promote using Box as a
> >replacement for Option in all Scala apps.  What this means for you is
> you
> >have to import net.liftweb.common._ in any file that you also import
> >net.liftweb.util.?
> >- Lift no longer support Scala Actors for Comet Actors.  The
> GenericActor
> >API offers pretty much the same client interface to Lift's Actors, so
> ! and
> >!? work the same way.  However, there's no link, self, start or exit
> >methods.
> >
> > Please do an "mvn -U clean install" on your code and run it against the
> new
> > code.  If you have any Comet-related weirdness, please report it
> > immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
> > iron any kinks out of this code.
> >
> > Thanks,
> >
> > David
> >
> > --
> > 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
>
>
>
> >
>


-- 
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 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] Re: **Breaking Changes** **README** **Important**

[Jim Barrows]

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 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 my project to compile due to some type
mismatch errors but that might also be my lack of understanding
of the different Actor implementations.

Thanks,
ssid

On 22 Okt., 05:37, David Pollak  wrote:
> 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 of
> traits that allow Lift to use its own Actors or Akka Actors (or anything
> else that implements that interface.)
>
> The two big changes that you'll have to work with are:
>
>    - Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util
>    package to the lift-common/net.liftweb.common package.  The reason for this
>    change is that we're going to make the lift-common package a more generic,
>    non-web related package.  It currently contains Box and Actor, but in the
>    future may contain other interfaces that will have concrete implementations
>    outside of Lift.  We moved Box there because Box is richer than Scala's
>    Option class and being able to carry Exceptions around in a Box while still
>    being able to map/flatMap/foreach over a Box (these are unavailable for
>    Scala's Either).  Some we're going to actively promote using Box as a
>    replacement for Option in all Scala apps.  What this means for you is you
>    have to import net.liftweb.common._ in any file that you also import
>    net.liftweb.util.?
>    - Lift no longer support Scala Actors for Comet Actors.  The GenericActor
>    API offers pretty much the same client interface to Lift's Actors, so ! and
>    !? work the same way.  However, there's no link, self, start or exit
>    methods.
>
> Please do an "mvn -U clean install" on your code and run it against the new
> code.  If you have any Comet-related weirdness, please report it
> immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
> iron any kinks out of this code.
>
> Thanks,
>
> David
>
> --
> 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] Re: **Breaking Changes** **README** **Important**

[ssid]

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 my project to compile due to some type
mismatch errors but that might also be my lack of understanding
of the different Actor implementations.

Thanks,
ssid

On 22 Okt., 05:37, David Pollak  wrote:
> 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 of
> traits that allow Lift to use its own Actors or Akka Actors (or anything
> else that implements that interface.)
>
> The two big changes that you'll have to work with are:
>
>    - Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util
>    package to the lift-common/net.liftweb.common package.  The reason for this
>    change is that we're going to make the lift-common package a more generic,
>    non-web related package.  It currently contains Box and Actor, but in the
>    future may contain other interfaces that will have concrete implementations
>    outside of Lift.  We moved Box there because Box is richer than Scala's
>    Option class and being able to carry Exceptions around in a Box while still
>    being able to map/flatMap/foreach over a Box (these are unavailable for
>    Scala's Either).  Some we're going to actively promote using Box as a
>    replacement for Option in all Scala apps.  What this means for you is you
>    have to import net.liftweb.common._ in any file that you also import
>    net.liftweb.util.?
>    - Lift no longer support Scala Actors for Comet Actors.  The GenericActor
>    API offers pretty much the same client interface to Lift's Actors, so ! and
>    !? work the same way.  However, there's no link, self, start or exit
>    methods.
>
> Please do an "mvn -U clean install" on your code and run it against the new
> code.  If you have any Comet-related weirdness, please report it
> immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
> iron any kinks out of this code.
>
> Thanks,
>
> David
>
> --
> 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] Re: **Breaking Changes** **README** **Important**

[george]

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...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

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

[Dano]

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  wrote:
> 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 22, 10:00 am, Dano  wrote:
>
>
>
> > 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]
>
> > > ?
--~--~-~--~~~---~--~~
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: **Breaking Changes** **README** **Important**

[Dano]

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 22, 10:00 am, Dano  wrote:
> 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]
>
> > ?
--~--~-~--~~~---~--~~
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: **Breaking Changes** **README** **Important**

[Dano]

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]
>
> ?
--~--~-~--~~~---~--~~
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: **Breaking Changes** **README** **Important**

[george]

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@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: **Breaking Changes** **README** **Important**

[Timothy Perrett]

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 change would you suggest to have my code compile?

Checkout the declaration:

trait GenericActor[R] extends TypedActor[Any, R]

You need to pass it a type argument to populate R in order for your
code to compile.

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

If I remember rightly there was a discussion about this on list not so
long ago - looking at the code, scheduleAtFixedRate has been removed.
The preferred idiom is to generally have a method that reschedules the
actor on every "ping".

Cheers, Tim

--~--~-~--~~~---~--~~
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: **Breaking Changes** **README** **Important**

[Viktor Klang]

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, Oct 22, 2009 at 12:37 PM, george  wrote:

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


-- 
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

--~--~-~--~~~---~--~~
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: **Breaking Changes** **README** **Important**

[george]

> - 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 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: **Breaking Changes** **README** **Important**

[soumik]

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 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 change would you suggest to have my code compile?
- 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?

Thanks,
Soumik

On Oct 22, 10:35 am, Indrajit Raychaudhuri 
wrote:
> 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 wrote:
>
> > 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 of traits that allow Lift to use its own Actors or Akka
> >     Actors (or anything else that implements that interface.)
>
> >     The two big changes that you'll have to work with are:
>
> >         * Box/Full/Empty/Failure was moved from the
> >           lift-util/net.liftweb.util package to the
> >           lift-common/net.liftweb.common package.  The reason for this
> >           change is that we're going to make the lift-common package a
> >           more generic, non-web related package.  It currently contains
> >           Box and Actor, but in the future may contain other interfaces
> >           that will have concrete implementations outside of Lift.  We
> >           moved Box there because Box is richer than Scala's Option
> >           class and being able to carry Exceptions around in a Box while
> >           still being able to map/flatMap/foreach over a Box (these are
> >           unavailable for Scala's Either).  Some we're going to actively
> >           promote using Box as a replacement for Option in all Scala
> >           apps.  What this means for you is you have to import
> >           net.liftweb.common._ in any file that you also import
> >           net.liftweb.util.?
> >         * Lift no longer support Scala Actors for Comet Actors.  The
> >           GenericActor API offers pretty much the same client interface
> >           to Lift's Actors, so ! and !? work the same way.  However,
> >           there's no link, self, start or exit methods.
>
> >     Please do an "mvn -U clean install" on your code and run it against
> >     the new code.  If you have any Comet-related weirdness, please
> >     report it immediately.  We're planning M7 in 2 weeks, so we've got
> >     lots of time to iron any kinks out of this code.
>
> >     Thanks,
>
> >     David
>
> >     --
> >     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] Re: **Breaking Changes** **README** **Important**

[Jonathan Ferguson]

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 code change... at least that's been the
> case for all the projects I've converted.
>
>
>>
>> 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 of
>>> traits that allow Lift to use its own Actors or Akka Actors (or anything
>>> else that implements that interface.)
>>>
>>> The two big changes that you'll have to work with are:
>>>
>>>- Box/Full/Empty/Failure was moved from the
>>>lift-util/net.liftweb.util package to the lift-common/net.liftweb.common
>>>package.  The reason for this change is that we're going to make the
>>>lift-common package a more generic, non-web related package.  It 
>>> currently
>>>contains Box and Actor, but in the future may contain other interfaces 
>>> that
>>>will have concrete implementations outside of Lift.  We moved Box there
>>>because Box is richer than Scala's Option class and being able to carry
>>>Exceptions around in a Box while still being able to map/flatMap/foreach
>>>over a Box (these are unavailable for Scala's Either).  Some we're going 
>>> to
>>>actively promote using Box as a replacement for Option in all Scala apps.
>>> What this means for you is you have to import net.liftweb.common._ in 
>>> any
>>>file that you also import net.liftweb.util.?
>>>- Lift no longer support Scala Actors for Comet Actors.  The
>>>GenericActor API offers pretty much the same client interface to Lift's
>>>Actors, so ! and !? work the same way.  However, there's no link, self,
>>>start or exit methods.
>>>
>>> Please do an "mvn -U clean install" on your code and run it against the
>>> new code.  If you have any Comet-related weirdness, please report it
>>> immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
>>> iron any kinks out of this code.
>>>
>>> Thanks,
>>>
>>> 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 harmonics
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> 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 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] Re: **Breaking Changes** **README** **Important**

[Indrajit Raychaudhuri]

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 wrote:
> 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 of traits that allow Lift to use its own Actors or Akka
> Actors (or anything else that implements that interface.)
>
> The two big changes that you'll have to work with are:
>
> * Box/Full/Empty/Failure was moved from the
>   lift-util/net.liftweb.util package to the
>   lift-common/net.liftweb.common package.  The reason for this
>   change is that we're going to make the lift-common package a
>   more generic, non-web related package.  It currently contains
>   Box and Actor, but in the future may contain other interfaces
>   that will have concrete implementations outside of Lift.  We
>   moved Box there because Box is richer than Scala's Option
>   class and being able to carry Exceptions around in a Box while
>   still being able to map/flatMap/foreach over a Box (these are
>   unavailable for Scala's Either).  Some we're going to actively
>   promote using Box as a replacement for Option in all Scala
>   apps.  What this means for you is you have to import
>   net.liftweb.common._ in any file that you also import
>   net.liftweb.util.?
> * Lift no longer support Scala Actors for Comet Actors.  The
>   GenericActor API offers pretty much the same client interface
>   to Lift's Actors, so ! and !? work the same way.  However,
>   there's no link, self, start or exit methods.
>
> Please do an "mvn -U clean install" on your code and run it against
> the new code.  If you have any Comet-related weirdness, please
> report it immediately.  We're planning M7 in 2 weeks, so we've got
> lots of time to iron any kinks out of this code.
>
> Thanks,
>
> 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 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] Re: **Breaking Changes** **README** **Important**

[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 code change... at least that's been the
case for all the projects I've converted.


>
> 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 of
>> traits that allow Lift to use its own Actors or Akka Actors (or anything
>> else that implements that interface.)
>>
>> The two big changes that you'll have to work with are:
>>
>>- Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util
>>package to the lift-common/net.liftweb.common package.  The reason for 
>> this
>>change is that we're going to make the lift-common package a more generic,
>>non-web related package.  It currently contains Box and Actor, but in the
>>future may contain other interfaces that will have concrete 
>> implementations
>>outside of Lift.  We moved Box there because Box is richer than Scala's
>>Option class and being able to carry Exceptions around in a Box while 
>> still
>>being able to map/flatMap/foreach over a Box (these are unavailable for
>>Scala's Either).  Some we're going to actively promote using Box as a
>>replacement for Option in all Scala apps.  What this means for you is you
>>have to import net.liftweb.common._ in any file that you also import
>>net.liftweb.util.?
>>- Lift no longer support Scala Actors for Comet Actors.  The
>>GenericActor API offers pretty much the same client interface to Lift's
>>Actors, so ! and !? work the same way.  However, there's no link, self,
>>start or exit methods.
>>
>> Please do an "mvn -U clean install" on your code and run it against the
>> new code.  If you have any Comet-related weirdness, please report it
>> immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
>> iron any kinks out of this code.
>>
>> Thanks,
>>
>> 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 harmonics
>>
>>
>>
>
> >
>


-- 
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 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] Re: **Breaking Changes** **README** **Important**

[Jonathan Ferguson]

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 of
> traits that allow Lift to use its own Actors or Akka Actors (or anything
> else that implements that interface.)
>
> The two big changes that you'll have to work with are:
>
>- Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util
>package to the lift-common/net.liftweb.common package.  The reason for this
>change is that we're going to make the lift-common package a more generic,
>non-web related package.  It currently contains Box and Actor, but in the
>future may contain other interfaces that will have concrete implementations
>outside of Lift.  We moved Box there because Box is richer than Scala's
>Option class and being able to carry Exceptions around in a Box while still
>being able to map/flatMap/foreach over a Box (these are unavailable for
>Scala's Either).  Some we're going to actively promote using Box as a
>replacement for Option in all Scala apps.  What this means for you is you
>have to import net.liftweb.common._ in any file that you also import
>net.liftweb.util.?
>- Lift no longer support Scala Actors for Comet Actors.  The
>GenericActor API offers pretty much the same client interface to Lift's
>Actors, so ! and !? work the same way.  However, there's no link, self,
>start or exit methods.
>
> Please do an "mvn -U clean install" on your code and run it against the new
> code.  If you have any Comet-related weirdness, please report it
> immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
> iron any kinks out of this code.
>
> Thanks,
>
> 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 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] Re: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[Heiko Seeberger]

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 to common interfaces to
swap in others like Akka

Heiko

2009/9/16 David Pollak 

>
>
> 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 corrected actor implementation that we have
>> direct control of. I know DPP would certainly have this be his preference
>> despite Jonas, Viktor and myself being commiters on both projects :-)
>>
>> Bottom line here is that we need this fixed, asap and the path of least
>> resistance is to use lift-actor until EPFL fix the core actor code.
>>
>
> If we make the change, we're not switching back.  If EPFL wants to make
> their Actors conform to a common Akka/Lift interface, that would allow them
> to be used, but otherwise, if we go down this path I'm not messing with EPFL
> Actors anymore.
>
>
>>
>> Cheers, Tim
>>
>>
>>
>> On 16 Sep 2009, at 14:27, Kevin Wright wrote:
>>
>> 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 epic battle with Scala actors
>>> and their memory retention issues.
>>>
>>> I finally wrote a Lift Actor library that made all the Scala
>>> Actor-related issues go away for the short-lived Actors that Lift uses as
>>> listeners for comet long-polling.
>>>
>>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>>> in Scala 2.8.
>>>
>>> I can make a change in Lift to move to Lift Actors in CometActor code.
>>>  It means that if you're using Scala Actors beyond !, !! and !? methods, you
>>> will have to change your code, otherwise it will just be a recompile.
>>>
>>> What do people think?
>>>
>>> Thanks,
>>>
>>> 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
>>> Git some: http://github.com/dpp
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[Derek Chen-Becker]

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 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 know DPP would certainly have this be his preference
>> despite Jonas, Viktor and myself being commiters on both projects :-)
>>
>> Bottom line here is that we need this fixed, asap and the path of least
>> resistance is to use lift-actor until EPFL fix the core actor code.
>>
>
> If we make the change, we're not switching back.  If EPFL wants to make
> their Actors conform to a common Akka/Lift interface, that would allow them
> to be used, but otherwise, if we go down this path I'm not messing with EPFL
> Actors anymore.
>
>
>>
>> Cheers, Tim
>>
>>
>>
>> On 16 Sep 2009, at 14:27, Kevin Wright wrote:
>>
>> 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 epic battle with Scala actors
>>> and their memory retention issues.
>>>
>>> I finally wrote a Lift Actor library that made all the Scala
>>> Actor-related issues go away for the short-lived Actors that Lift uses as
>>> listeners for comet long-polling.
>>>
>>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>>> in Scala 2.8.
>>>
>>> I can make a change in Lift to move to Lift Actors in CometActor code.
>>>  It means that if you're using Scala Actors beyond !, !! and !? methods, you
>>> will have to change your code, otherwise it will just be a recompile.
>>>
>>> What do people think?
>>>
>>> Thanks,
>>>
>>> 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
>>> Git some: http://github.com/dpp
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[David Pollak]

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 corrected actor implementation that we have
> direct control of. I know DPP would certainly have this be his preference
> despite Jonas, Viktor and myself being commiters on both projects :-)
>
> Bottom line here is that we need this fixed, asap and the path of least
> resistance is to use lift-actor until EPFL fix the core actor code.
>

If we make the change, we're not switching back.  If EPFL wants to make
their Actors conform to a common Akka/Lift interface, that would allow them
to be used, but otherwise, if we go down this path I'm not messing with EPFL
Actors anymore.


>
> Cheers, Tim
>
>
>
> On 16 Sep 2009, at 14:27, Kevin Wright wrote:
>
> 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 epic battle with Scala actors and
>> their memory retention issues.
>>
>> I finally wrote a Lift Actor library that made all the Scala Actor-related
>> issues go away for the short-lived Actors that Lift uses as listeners for
>> comet long-polling.
>>
>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>> in Scala 2.8.
>>
>> I can make a change in Lift to move to Lift Actors in CometActor code.  It
>> means that if you're using Scala Actors beyond !, !! and !? methods, you
>> will have to change your code, otherwise it will just be a recompile.
>>
>> What do people think?
>>
>> Thanks,
>>
>> 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
>> Git some: http://github.com/dpp
>>
>>
>>
>
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[Viktor Klang]

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 corrected actor implementation that we have
> direct control of. I know DPP would certainly have this be his preference
> despite Jonas, Viktor and myself being commiters on both projects :-)
>
> Bottom line here is that we need this fixed, asap and the path of least
> resistance is to use lift-actor until EPFL fix the core actor code.
>

Seconded.


>
> Cheers, Tim
>
>
>
> On 16 Sep 2009, at 14:27, Kevin Wright wrote:
>
> 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 epic battle with Scala actors and
>> their memory retention issues.
>>
>> I finally wrote a Lift Actor library that made all the Scala Actor-related
>> issues go away for the short-lived Actors that Lift uses as listeners for
>> comet long-polling.
>>
>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>> in Scala 2.8.
>>
>> I can make a change in Lift to move to Lift Actors in CometActor code.  It
>> means that if you're using Scala Actors beyond !, !! and !? methods, you
>> will have to change your code, otherwise it will just be a recompile.
>>
>> What do people think?
>>
>> Thanks,
>>
>> 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
>> Git some: http://github.com/dpp
>>
>>
>>
>
>
>
>
> >
>


-- 
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[Timothy Perrett]

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 know DPP would  
certainly have this be his preference despite Jonas, Viktor and myself  
being commiters on both projects :-)

Bottom line here is that we need this fixed, asap and the path of  
least resistance is to use lift-actor until EPFL fix the core actor  
code.

Cheers, Tim



On 16 Sep 2009, at 14:27, Kevin Wright wrote:

> 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  
> actors and their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor- 
> related issues go away for the short-lived Actors that Lift uses as  
> listeners for comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be  
> gone in Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor  
> code.  It means that if you're using Scala Actors beyond !, !!  
> and !? methods, you will have to change your code, otherwise it will  
> just be a recompile.
>
> What do people think?
>
> Thanks,
>
> 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
> 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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[David Pollak]

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 and will be able to
work together on this.

In terms of the light-weight nature of a lot of CometActors, I'd opt, by
default, to go with Lift Actors.


>
>
> 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 epic battle with Scala actors and
>> their memory retention issues.
>>
>> I finally wrote a Lift Actor library that made all the Scala Actor-related
>> issues go away for the short-lived Actors that Lift uses as listeners for
>> comet long-polling.
>>
>> It seems that the Actor issue is not gone.  I'm not sure it will be gone
>> in Scala 2.8.
>>
>> I can make a change in Lift to move to Lift Actors in CometActor code.  It
>> means that if you're using Scala Actors beyond !, !! and !? methods, you
>> will have to change your code, otherwise it will just be a recompile.
>>
>> What do people think?
>>
>> Thanks,
>>
>> 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
>> Git some: http://github.com/dpp
>>
>>
>>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[Viktor Klang]

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çois Arcand (Atmosphere dude) has shown interest in
integrating it into Lift.


>
> -
> TylerWeir wrote:
>
>
> 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 November 2008 - June 2009, I did an epic battle with Scala actors
> and
> > their memory retention issues.
> >
> > I finally wrote a Lift Actor library that made all the Scala
> Actor-related
> > issues go away for the short-lived Actors that Lift uses as listeners for
> > comet long-polling.
> >
> > It seems that the Actor issue is not gone. ?I'm not sure it will be gone
> in
> > Scala 2.8.
> >
> > I can make a change in Lift to move to Lift Actors in CometActor code.
> ?It
> > means that if you're using Scala Actors beyond !, !! and !? methods, you
> > will have to change your code, otherwise it will just be a recompile.
> >
> > What do people think?
> >
> > Thanks,
> >
> > David
> >
> > --
> > 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
>
>
> >
>


-- 
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[Naftoli Gugenheim]

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 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 November 2008 - June 2009, I did an epic battle with Scala actors and
> their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor-related
> issues go away for the short-lived Actors that Lift uses as listeners for
> comet long-polling.
>
> It seems that the Actor issue is not gone. ?I'm not sure it will be gone in
> Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor code. ?It
> means that if you're using Scala Actors beyond !, !! and !? methods, you
> will have to change your code, otherwise it will just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> --
> 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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[marius d.]

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 wrote a Lift Actor library that made all the Scala Actor-related
> issues go away for the short-lived Actors that Lift uses as listeners for
> comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be gone in
> Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor code.  It
> means that if you're using Scala Actors beyond !, !! and !? methods, you
> will have to change your code, otherwise it will just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> --
> 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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[Timothy Perrett]

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

Tim

Sent from my iPhone

On 16 Sep 2009, at 14:14, 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 wrote a Lift Actor library that made all the Scala Actor- 
> related issues go away for the short-lived Actors that Lift uses as  
> listeners for comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be  
> gone in Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor  
> code.  It means that if you're using Scala Actors beyond !, !!  
> and !? methods, you will have to change your code, otherwise it will  
> just be a recompile.
>
> What do people think?
>
> Thanks,
>
> 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
> 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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[TylerWeir]

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 November 2008 - June 2009, I did an epic battle with Scala actors and
> their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor-related
> issues go away for the short-lived Actors that Lift uses as listeners for
> comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be gone in
> Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor code.  It
> means that if you're using Scala Actors beyond !, !! and !? methods, you
> will have to change your code, otherwise it will just be a recompile.
>
> What do people think?
>
> Thanks,
>
> David
>
> --
> 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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors

[Kevin Wright]

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 actors and
> their memory retention issues.
>
> I finally wrote a Lift Actor library that made all the Scala Actor-related
> issues go away for the short-lived Actors that Lift uses as listeners for
> comet long-polling.
>
> It seems that the Actor issue is not gone.  I'm not sure it will be gone in
> Scala 2.8.
>
> I can make a change in Lift to move to Lift Actors in CometActor code.  It
> means that if you're using Scala Actors beyond !, !! and !? methods, you
> will have to change your code, otherwise it will just be a recompile.
>
> What do people think?
>
> Thanks,
>
> 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
> 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: *** BREAKING CHANGES COMMITTED ***

[David Pollak]

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 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 breaking changes:
>>
>> 1. S.servletRequest is now S.containerRequest, S.servletSession is now
>> S.containerSession. The reason is that the servlet term seems
>> inapropriate now as we not necessarily talking about servlets anymore.
>> 2. LiftRules.enableServletSessions is now
>> LiftRules.enableContainerSessions
>>
>> I won't enumerate here all methods from the new abstractions but the
>> traits are:
>>
>> 1. HTTPRequest
>> 2. HTTPResponse
>> 3. HTTPCookie
>> 4. HTTPParam
>> 5. HTTPProvider - This is the entry point in Lift. See how
>> ServletFilterProvider uses it.
>> 6. HTTPSession
>> 7. HTTPContext
>>
>> To see how these trait map to JEE servlets world please see
>> refinements from net.liftweb.http.provider.servlet package
>>
>> If your application does not explicitly relies on usage on
>> javax.servlet._ package you should have very little or no changes to
>> make.
>>
>> Br's,
>> Marius
>>
>> On Aug 5, 3:05 pm, "marius d."  wrote:
>> > 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, 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,
>> >
>> > > > > > 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 is:
>> >
>> > > > > > 1. Lift will work with its own traits that abstracts HTTP
>> request,
>> > > > > > response, HTTP sessions etc.
>> > > > > > 2. By default there will be the servlet implementation and it'll
>> work
>> > > > > > as currently.
>> > > > > > 3. Certain function names will slightly change.
>> > > > > > 4. If your application explicitly wants to use
>> HttpServletRequest
>> > > > > > obtained from S some explicit casts would be needed. Generally
>> Lift
>> > > > > > application should probably not explicitly use javax.servlet._
>> > > > > > references.
>> >
>> > > > > > I will post the details of the changes when I'll merge it to
>> master
>> > > > > > (hopefully this week).
>> >
>> > > > > > Br's,
>> > > > > > Marius
>>
>>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: *** BREAKING CHANGES COMMITTED ***

[Kevin Wright]

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
> even your own implementation of a HTTP server etc.
>
> This effort lead to several breaking changes:
>
> 1. S.servletRequest is now S.containerRequest, S.servletSession is now
> S.containerSession. The reason is that the servlet term seems
> inapropriate now as we not necessarily talking about servlets anymore.
> 2. LiftRules.enableServletSessions is now
> LiftRules.enableContainerSessions
>
> I won't enumerate here all methods from the new abstractions but the
> traits are:
>
> 1. HTTPRequest
> 2. HTTPResponse
> 3. HTTPCookie
> 4. HTTPParam
> 5. HTTPProvider - This is the entry point in Lift. See how
> ServletFilterProvider uses it.
> 6. HTTPSession
> 7. HTTPContext
>
> To see how these trait map to JEE servlets world please see
> refinements from net.liftweb.http.provider.servlet package
>
> If your application does not explicitly relies on usage on
> javax.servlet._ package you should have very little or no changes to
> make.
>
> Br's,
> Marius
>
> On Aug 5, 3:05 pm, "marius d."  wrote:
> > 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, 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,
> >
> > > > > > 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 is:
> >
> > > > > > 1. Lift will work with its own traits that abstracts HTTP
> request,
> > > > > > response, HTTP sessions etc.
> > > > > > 2. By default there will be the servlet implementation and it'll
> work
> > > > > > as currently.
> > > > > > 3. Certain function names will slightly change.
> > > > > > 4. If your application explicitly wants to use HttpServletRequest
> > > > > > obtained from S some explicit casts would be needed. Generally
> Lift
> > > > > > application should probably not explicitly use javax.servlet._
> > > > > > references.
> >
> > > > > > I will post the details of the changes when I'll merge it to
> master
> > > > > > (hopefully this week).
> >
> > > > > > Br's,
> > > > > > Marius
> >
>

--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES COMMITTED ***

[marius d.]

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 breaking changes:

1. S.servletRequest is now S.containerRequest, S.servletSession is now
S.containerSession. The reason is that the servlet term seems
inapropriate now as we not necessarily talking about servlets anymore.
2. LiftRules.enableServletSessions is now
LiftRules.enableContainerSessions

I won't enumerate here all methods from the new abstractions but the
traits are:

1. HTTPRequest
2. HTTPResponse
3. HTTPCookie
4. HTTPParam
5. HTTPProvider - This is the entry point in Lift. See how
ServletFilterProvider uses it.
6. HTTPSession
7. HTTPContext

To see how these trait map to JEE servlets world please see
refinements from net.liftweb.http.provider.servlet package

If your application does not explicitly relies on usage on
javax.servlet._ package you should have very little or no changes to
make.

Br's,
Marius

On Aug 5, 3:05 pm, "marius d."  wrote:
> 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, 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,
>
> > > > > 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 is:
>
> > > > > 1. Lift will work with its own traits that abstracts HTTP request,
> > > > > response, HTTP sessions etc.
> > > > > 2. By default there will be the servlet implementation and it'll work
> > > > > as currently.
> > > > > 3. Certain function names will slightly change.
> > > > > 4. If your application explicitly wants to use HttpServletRequest
> > > > > obtained from S some explicit casts would be needed. Generally Lift
> > > > > application should probably not explicitly use javax.servlet._
> > > > > references.
>
> > > > > I will post the details of the changes when I'll merge it to master
> > > > > (hopefully this week).
>
> > > > > Br's,
> > > > > Marius
--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES COMING UP SOON ***

[marius d.]

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, 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,
>
> > > > 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 is:
>
> > > > 1. Lift will work with its own traits that abstracts HTTP request,
> > > > response, HTTP sessions etc.
> > > > 2. By default there will be the servlet implementation and it'll work
> > > > as currently.
> > > > 3. Certain function names will slightly change.
> > > > 4. If your application explicitly wants to use HttpServletRequest
> > > > obtained from S some explicit casts would be needed. Generally Lift
> > > > application should probably not explicitly use javax.servlet._
> > > > references.
>
> > > > I will post the details of the changes when I'll merge it to master
> > > > (hopefully this week).
>
> > > > Br's,
> > > > Marius
--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES COMING UP SOON ***

[Timothy Perrett]

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,
>
> > > 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 is:
>
> > > 1. Lift will work with its own traits that abstracts HTTP request,
> > > response, HTTP sessions etc.
> > > 2. By default there will be the servlet implementation and it'll work
> > > as currently.
> > > 3. Certain function names will slightly change.
> > > 4. If your application explicitly wants to use HttpServletRequest
> > > obtained from S some explicit casts would be needed. Generally Lift
> > > application should probably not explicitly use javax.servlet._
> > > references.
>
> > > I will post the details of the changes when I'll merge it to master
> > > (hopefully this week).
>
> > > Br's,
> > > Marius
--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES COMING UP SOON ***

[Derek Chen-Becker]

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 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 is:
> >
> > > 1. Lift will work with its own traits that abstracts HTTP request,
> > > response, HTTP sessions etc.
> > > 2. By default there will be the servlet implementation and it'll work
> > > as currently.
> > > 3. Certain function names will slightly change.
> > > 4. If your application explicitly wants to use HttpServletRequest
> > > obtained from S some explicit casts would be needed. Generally Lift
> > > application should probably not explicitly use javax.servlet._
> > > references.
> >
> > > I will post the details of the changes when I'll merge it to master
> > > (hopefully this week).
> >
> > > Br's,
> > > Marius
> >
>

--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES COMING UP SOON ***

[marius d.]

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-
> > abstractions.
>
> > I still need to nail down a few things but the idea is:
>
> > 1. Lift will work with its own traits that abstracts HTTP request,
> > response, HTTP sessions etc.
> > 2. By default there will be the servlet implementation and it'll work
> > as currently.
> > 3. Certain function names will slightly change.
> > 4. If your application explicitly wants to use HttpServletRequest
> > obtained from S some explicit casts would be needed. Generally Lift
> > application should probably not explicitly use javax.servlet._
> > references.
>
> > I will post the details of the changes when I'll merge it to master
> > (hopefully this week).
>
> > Br's,
> > Marius
--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES COMING UP SOON ***

[Yousry Abdallah]

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 is:
>
> 1. Lift will work with its own traits that abstracts HTTP request,
> response, HTTP sessions etc.
> 2. By default there will be the servlet implementation and it'll work
> as currently.
> 3. Certain function names will slightly change.
> 4. If your application explicitly wants to use HttpServletRequest
> obtained from S some explicit casts would be needed. Generally Lift
> application should probably not explicitly use javax.servlet._
> references.
>
> I will post the details of the changes when I'll merge it to master
> (hopefully this week).
>
> Br's,
> Marius

--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES COMING UP SOON ***

[Timothy Perrett]

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 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 don't use the javax.servlet API? Just
> >> curious.
>
> > Yes, Jersey directly, portlets, etc.
>
> >> 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: javax.servlet._ The code is currently in wip-marius-http-
> >>> abstractions.
>
> >>> I still need to nail down a few things but the idea is:
>
> >>> 1. Lift will work with its own traits that abstracts HTTP request,
> >>> response, HTTP sessions etc.
> >>> 2. By default there will be the servlet implementation and it'll work
> >>> as currently.
> >>> 3. Certain function names will slightly change.
> >>> 4. If your application explicitly wants to use HttpServletRequest
> >>> obtained from S some explicit casts would be needed. Generally Lift
> >>> application should probably not explicitly use javax.servlet._
> >>> references.
>
> >>> I will post the details of the changes when I'll merge it to master
> >>> (hopefully this week).
>
> >>> Br's,
> >>> Marius
>
> > --
> > 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: *** BREAKING CHANGES COMING UP SOON ***

[marius d.]

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, Aug 4, 2009 at 1:51 PM, 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 is:
>
> > 1. Lift will work with its own traits that abstracts HTTP request,
> > response, HTTP sessions etc.
> > 2. By default there will be the servlet implementation and it'll work
> > as currently.
> > 3. Certain function names will slightly change.
> > 4. If your application explicitly wants to use HttpServletRequest
> > obtained from S some explicit casts would be needed. Generally Lift
> > application should probably not explicitly use javax.servlet._
> > references.
>
> > I will post the details of the changes when I'll merge it to master
> > (hopefully this week).
>
> > Br's,
> > Marius
--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES COMING UP SOON ***

[Derek Chen-Becker]

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 don't use the javax.servlet API? Just
>> curious.
>
>
> Yes, Jersey directly, portlets, etc.
>
>>
>>
>> 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: javax.servlet._ The code is currently in wip-marius-http-
>>> abstractions.
>>>
>>> I still need to nail down a few things but the idea is:
>>>
>>> 1. Lift will work with its own traits that abstracts HTTP request,
>>> response, HTTP sessions etc.
>>> 2. By default there will be the servlet implementation and it'll work
>>> as currently.
>>> 3. Certain function names will slightly change.
>>> 4. If your application explicitly wants to use HttpServletRequest
>>> obtained from S some explicit casts would be needed. Generally Lift
>>> application should probably not explicitly use javax.servlet._
>>> references.
>>>
>>> I will post the details of the changes when I'll merge it to master
>>> (hopefully this week).
>>>
>>> Br's,
>>> Marius
>>>
>>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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: *** BREAKING CHANGES COMING UP SOON ***

[David Pollak]

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:51 PM, 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 is:
>>
>> 1. Lift will work with its own traits that abstracts HTTP request,
>> response, HTTP sessions etc.
>> 2. By default there will be the servlet implementation and it'll work
>> as currently.
>> 3. Certain function names will slightly change.
>> 4. If your application explicitly wants to use HttpServletRequest
>> obtained from S some explicit casts would be needed. Generally Lift
>> application should probably not explicitly use javax.servlet._
>> references.
>>
>> I will post the details of the changes when I'll merge it to master
>> (hopefully this week).
>>
>> Br's,
>> Marius
>>
>>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: *** BREAKING CHANGES COMING UP SOON ***

[Derek Chen-Becker]

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: javax.servlet._ The code is currently in wip-marius-http-
> abstractions.
>
> I still need to nail down a few things but the idea is:
>
> 1. Lift will work with its own traits that abstracts HTTP request,
> response, HTTP sessions etc.
> 2. By default there will be the servlet implementation and it'll work
> as currently.
> 3. Certain function names will slightly change.
> 4. If your application explicitly wants to use HttpServletRequest
> obtained from S some explicit casts would be needed. Generally Lift
> application should probably not explicitly use javax.servlet._
> references.
>
> I will post the details of the changes when I'll merge it to master
> (hopefully this week).
>
> Br's,
> Marius
> >
>

--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES ***

[David Pollak]

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. Sometimes I can't
> add 1 + 1
>

No worries.  We're here to help make you successful.


>
> On Wed, Feb 11, 2009 at 10:26 AM, David Pollak
>  wrote:
> >
> >
> > 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 my choices now are
> >>
> >> 1) To back out my reliance on the stable version of lift 0.10
> >> 2) To look at the source code for lift and try to figure out the problem
> >> 3) To remove my applications reliance on this code
> >
> > I just inserted:
> >
> > LiftRules.exceptionHandler.prepend {
> >   case (mode, state, ex) => RedirectResponse("/error")
> > }
> >
> > Into Boot.scala in a newly created Lift 0.10 app.  It worked without
> > complaint.
> >
> > Please try doing an mvn -U clean install and see if that works.  I'm also
> > happy to look at your source off-list to see if I can puzzle through the
> > problem.
> >
> > And, yes the API changes are going to be minimal from here on out.
> >
> >>
> >> I am going to be glad when Lift gets to version 1.0, because
> >> presumably there will be less breaking changes (I hope)
> >>
> >> On Wed, Feb 11, 2009 at 9:58 AM, 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:
> >> >> 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 = {
> >> >>>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
> >> >>> > application.
> >> >>> >
> >> >>> > 1. LiftRules.logAndReturnExceptionToBrowser and
> >> >>> > LiftRules.browserResponseToException have been removed. These were
> >> >>> > two
> >> >>> > different variables that did pretty much the same thing in fact
> the
> >> >>> > first ultimately called the former. These have been replaced with:
> >> >>> >
> >> >>> >
> >> >>> > var exceptionHandler = RulesSeq[ExceptionHandlerPF]
> >> >>> >
> >> >>> > having
> >> >>> >
> >> >>> > type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value,
> >> >>> > Req,
> >> >>> > Throwable), LiftResponse]
> >> >>> >
> >> >>> > By default a partial function is appended and it is the same code
> >> >>> > that
> >> >>> > used to be for LiftRules.browserResponseToException.
> >> >>> >
> >> >>> > So up until now probably your application was using something
> like:
> >> >>> >
> >> >>> > LiftRules.logAndReturnExceptionToBrowser = {
> >> >>> >case (state, ex) => RedirectResponse("/error")
> >> >>> > }
> >> >>> >
> >> >>> > now this turns into:
> >> >>> >
> >> >>> > LiftRules.exceptionHandler.prepend = {
> >> >>> >case (mode, state, ex) => RedirectResponse("/error")
> >> >>> > }
> >> >>> >
> >> >>> >
> >> >>> > 2. More unification of Ajax notices with "static" notices. So far
> to
> >> >>> > apply styling information (css classes etc) to Ajax notices we
> used
> >> >>> > three LiftRules variables:
> >> >>> >
> >> >>> >  var ajaxNoticeMeta: Can[AjaxMessageMeta]
> >> >>> >  var ajaxWarningMeta: Can[AjaxMessageMeta]
> >> >>> >  var ajaxErrorMeta: Can[AjaxMessageMeta]
> >> >>> >
> >> >>> > the motivation was that in order for Lift to send down the correct
> >> >>> > style information for Ajax/Comet notices it needed to maintain
> this
> >> >>> > information. Now I finally found time to do it. The above
> variables
> >> >>> > are gone. Instead the same styling information that you use for
> >> >>> > lift:msgs and lift:msg snippets will be applied for AJax and Comet
> >> >>> > notices. The styling information is captured when these snippets
> are
> >> >>> > executed and used whenever you're using notices for AJax response
> or
> >> >>> > from a Comet actor.
> >> >>> >
> >> >>> >
> >> >>> > Br's,
> >> >>> > Marius
> >> >>> > >
> >> >>> >
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.

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

[Oliver]

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:26 AM, David Pollak
 wrote:
>
>
> 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 my choices now are
>>
>> 1) To back out my reliance on the stable version of lift 0.10
>> 2) To look at the source code for lift and try to figure out the problem
>> 3) To remove my applications reliance on this code
>
> I just inserted:
>
> LiftRules.exceptionHandler.prepend {
>   case (mode, state, ex) => RedirectResponse("/error")
> }
>
> Into Boot.scala in a newly created Lift 0.10 app.  It worked without
> complaint.
>
> Please try doing an mvn -U clean install and see if that works.  I'm also
> happy to look at your source off-list to see if I can puzzle through the
> problem.
>
> And, yes the API changes are going to be minimal from here on out.
>
>>
>> I am going to be glad when Lift gets to version 1.0, because
>> presumably there will be less breaking changes (I hope)
>>
>> On Wed, Feb 11, 2009 at 9:58 AM, 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:
>> >> 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 = {
>> >>>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
>> >>> > application.
>> >>> >
>> >>> > 1. LiftRules.logAndReturnExceptionToBrowser and
>> >>> > LiftRules.browserResponseToException have been removed. These were
>> >>> > two
>> >>> > different variables that did pretty much the same thing in fact the
>> >>> > first ultimately called the former. These have been replaced with:
>> >>> >
>> >>> >
>> >>> > var exceptionHandler = RulesSeq[ExceptionHandlerPF]
>> >>> >
>> >>> > having
>> >>> >
>> >>> > type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value,
>> >>> > Req,
>> >>> > Throwable), LiftResponse]
>> >>> >
>> >>> > By default a partial function is appended and it is the same code
>> >>> > that
>> >>> > used to be for LiftRules.browserResponseToException.
>> >>> >
>> >>> > So up until now probably your application was using something like:
>> >>> >
>> >>> > LiftRules.logAndReturnExceptionToBrowser = {
>> >>> >case (state, ex) => RedirectResponse("/error")
>> >>> > }
>> >>> >
>> >>> > now this turns into:
>> >>> >
>> >>> > LiftRules.exceptionHandler.prepend = {
>> >>> >case (mode, state, ex) => RedirectResponse("/error")
>> >>> > }
>> >>> >
>> >>> >
>> >>> > 2. More unification of Ajax notices with "static" notices. So far to
>> >>> > apply styling information (css classes etc) to Ajax notices we used
>> >>> > three LiftRules variables:
>> >>> >
>> >>> >  var ajaxNoticeMeta: Can[AjaxMessageMeta]
>> >>> >  var ajaxWarningMeta: Can[AjaxMessageMeta]
>> >>> >  var ajaxErrorMeta: Can[AjaxMessageMeta]
>> >>> >
>> >>> > the motivation was that in order for Lift to send down the correct
>> >>> > style information for Ajax/Comet notices it needed to maintain this
>> >>> > information. Now I finally found time to do it. The above variables
>> >>> > are gone. Instead the same styling information that you use for
>> >>> > lift:msgs and lift:msg snippets will be applied for AJax and Comet
>> >>> > notices. The styling information is captured when these snippets are
>> >>> > executed and used whenever you're using notices for AJax response or
>> >>> > from a Comet actor.
>> >>> >
>> >>> >
>> >>> > Br's,
>> >>> > Marius
>> >>> > >
>> >>> >
>> >>>
>> >>>
>> >>
>> >>
>> >> >>
>> >>
>> >
>>
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://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 m

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

[David Pollak]

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 my choices now are
>
> 1) To back out my reliance on the stable version of lift 0.10
> 2) To look at the source code for lift and try to figure out the problem
> 3) To remove my applications reliance on this code


I just inserted:

LiftRules.exceptionHandler.prepend {
  case (mode, state, ex) => RedirectResponse("/error")
}

Into Boot.scala in a newly created Lift 0.10 app.  It worked without
complaint.

Please try doing an mvn -U clean install and see if that works.  I'm also
happy to look at your source off-list to see if I can puzzle through the
problem.

And, yes the API changes are going to be minimal from here on out.


>
>
> I am going to be glad when Lift gets to version 1.0, because
> presumably there will be less breaking changes (I hope)
>
> On Wed, Feb 11, 2009 at 9:58 AM, 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:
> >> 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 = {
> >>>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
> application.
> >>> >
> >>> > 1. LiftRules.logAndReturnExceptionToBrowser and
> >>> > LiftRules.browserResponseToException have been removed. These were
> two
> >>> > different variables that did pretty much the same thing in fact the
> >>> > first ultimately called the former. These have been replaced with:
> >>> >
> >>> >
> >>> > var exceptionHandler = RulesSeq[ExceptionHandlerPF]
> >>> >
> >>> > having
> >>> >
> >>> > type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value, Req,
> >>> > Throwable), LiftResponse]
> >>> >
> >>> > By default a partial function is appended and it is the same code
> that
> >>> > used to be for LiftRules.browserResponseToException.
> >>> >
> >>> > So up until now probably your application was using something like:
> >>> >
> >>> > LiftRules.logAndReturnExceptionToBrowser = {
> >>> >case (state, ex) => RedirectResponse("/error")
> >>> > }
> >>> >
> >>> > now this turns into:
> >>> >
> >>> > LiftRules.exceptionHandler.prepend = {
> >>> >case (mode, state, ex) => RedirectResponse("/error")
> >>> > }
> >>> >
> >>> >
> >>> > 2. More unification of Ajax notices with "static" notices. So far to
> >>> > apply styling information (css classes etc) to Ajax notices we used
> >>> > three LiftRules variables:
> >>> >
> >>> >  var ajaxNoticeMeta: Can[AjaxMessageMeta]
> >>> >  var ajaxWarningMeta: Can[AjaxMessageMeta]
> >>> >  var ajaxErrorMeta: Can[AjaxMessageMeta]
> >>> >
> >>> > the motivation was that in order for Lift to send down the correct
> >>> > style information for Ajax/Comet notices it needed to maintain this
> >>> > information. Now I finally found time to do it. The above variables
> >>> > are gone. Instead the same styling information that you use for
> >>> > lift:msgs and lift:msg snippets will be applied for AJax and Comet
> >>> > notices. The styling information is captured when these snippets are
> >>> > executed and used whenever you're using notices for AJax response or
> >>> > from a Comet actor.
> >>> >
> >>> >
> >>> > Br's,
> >>> > Marius
> >>> > >
> >>> >
> >>>
> >>>
> >>
> >>
> >> >>
> >>
> >
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: *** BREAKING CHANGES ***

[Oliver]

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 stable version of lift 0.10
2) To look at the source code for lift and try to figure out the problem
3) To remove my applications reliance on this code

I am going to be glad when Lift gets to version 1.0, because
presumably there will be less breaking changes (I hope)

On Wed, Feb 11, 2009 at 9:58 AM, 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:
>> 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 = {
>>>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 application.
>>> >
>>> > 1. LiftRules.logAndReturnExceptionToBrowser and
>>> > LiftRules.browserResponseToException have been removed. These were two
>>> > different variables that did pretty much the same thing in fact the
>>> > first ultimately called the former. These have been replaced with:
>>> >
>>> >
>>> > var exceptionHandler = RulesSeq[ExceptionHandlerPF]
>>> >
>>> > having
>>> >
>>> > type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value, Req,
>>> > Throwable), LiftResponse]
>>> >
>>> > By default a partial function is appended and it is the same code that
>>> > used to be for LiftRules.browserResponseToException.
>>> >
>>> > So up until now probably your application was using something like:
>>> >
>>> > LiftRules.logAndReturnExceptionToBrowser = {
>>> >case (state, ex) => RedirectResponse("/error")
>>> > }
>>> >
>>> > now this turns into:
>>> >
>>> > LiftRules.exceptionHandler.prepend = {
>>> >case (mode, state, ex) => RedirectResponse("/error")
>>> > }
>>> >
>>> >
>>> > 2. More unification of Ajax notices with "static" notices. So far to
>>> > apply styling information (css classes etc) to Ajax notices we used
>>> > three LiftRules variables:
>>> >
>>> >  var ajaxNoticeMeta: Can[AjaxMessageMeta]
>>> >  var ajaxWarningMeta: Can[AjaxMessageMeta]
>>> >  var ajaxErrorMeta: Can[AjaxMessageMeta]
>>> >
>>> > the motivation was that in order for Lift to send down the correct
>>> > style information for Ajax/Comet notices it needed to maintain this
>>> > information. Now I finally found time to do it. The above variables
>>> > are gone. Instead the same styling information that you use for
>>> > lift:msgs and lift:msg snippets will be applied for AJax and Comet
>>> > notices. The styling information is captured when these snippets are
>>> > executed and used whenever you're using notices for AJax response or
>>> > from a Comet actor.
>>> >
>>> >
>>> > Br's,
>>> > Marius
>>> > >
>>> >
>>>
>>>
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES ***

[David Pollak]

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:
> > 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 = {
> >>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 application.
> >> >
> >> > 1. LiftRules.logAndReturnExceptionToBrowser and
> >> > LiftRules.browserResponseToException have been removed. These were two
> >> > different variables that did pretty much the same thing in fact the
> >> > first ultimately called the former. These have been replaced with:
> >> >
> >> >
> >> > var exceptionHandler = RulesSeq[ExceptionHandlerPF]
> >> >
> >> > having
> >> >
> >> > type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value, Req,
> >> > Throwable), LiftResponse]
> >> >
> >> > By default a partial function is appended and it is the same code that
> >> > used to be for LiftRules.browserResponseToException.
> >> >
> >> > So up until now probably your application was using something like:
> >> >
> >> > LiftRules.logAndReturnExceptionToBrowser = {
> >> >case (state, ex) => RedirectResponse("/error")
> >> > }
> >> >
> >> > now this turns into:
> >> >
> >> > LiftRules.exceptionHandler.prepend = {
> >> >case (mode, state, ex) => RedirectResponse("/error")
> >> > }
> >> >
> >> >
> >> > 2. More unification of Ajax notices with "static" notices. So far to
> >> > apply styling information (css classes etc) to Ajax notices we used
> >> > three LiftRules variables:
> >> >
> >> >  var ajaxNoticeMeta: Can[AjaxMessageMeta]
> >> >  var ajaxWarningMeta: Can[AjaxMessageMeta]
> >> >  var ajaxErrorMeta: Can[AjaxMessageMeta]
> >> >
> >> > the motivation was that in order for Lift to send down the correct
> >> > style information for Ajax/Comet notices it needed to maintain this
> >> > information. Now I finally found time to do it. The above variables
> >> > are gone. Instead the same styling information that you use for
> >> > lift:msgs and lift:msg snippets will be applied for AJax and Comet
> >> > notices. The styling information is captured when these snippets are
> >> > executed and used whenever you're using notices for AJax response or
> >> > from a Comet actor.
> >> >
> >> >
> >> > Br's,
> >> > Marius
> >> > >
> >> >
> >>
> >>
> >
> >
> > >
> >
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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: *** BREAKING CHANGES ***

[Oliver]

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")
> }
> --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 = {
>>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 application.
>> >
>> > 1. LiftRules.logAndReturnExceptionToBrowser and
>> > LiftRules.browserResponseToException have been removed. These were two
>> > different variables that did pretty much the same thing in fact the
>> > first ultimately called the former. These have been replaced with:
>> >
>> >
>> > var exceptionHandler = RulesSeq[ExceptionHandlerPF]
>> >
>> > having
>> >
>> > type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value, Req,
>> > Throwable), LiftResponse]
>> >
>> > By default a partial function is appended and it is the same code that
>> > used to be for LiftRules.browserResponseToException.
>> >
>> > So up until now probably your application was using something like:
>> >
>> > LiftRules.logAndReturnExceptionToBrowser = {
>> >case (state, ex) => RedirectResponse("/error")
>> > }
>> >
>> > now this turns into:
>> >
>> > LiftRules.exceptionHandler.prepend = {
>> >case (mode, state, ex) => RedirectResponse("/error")
>> > }
>> >
>> >
>> > 2. More unification of Ajax notices with "static" notices. So far to
>> > apply styling information (css classes etc) to Ajax notices we used
>> > three LiftRules variables:
>> >
>> >  var ajaxNoticeMeta: Can[AjaxMessageMeta]
>> >  var ajaxWarningMeta: Can[AjaxMessageMeta]
>> >  var ajaxErrorMeta: Can[AjaxMessageMeta]
>> >
>> > the motivation was that in order for Lift to send down the correct
>> > style information for Ajax/Comet notices it needed to maintain this
>> > information. Now I finally found time to do it. The above variables
>> > are gone. Instead the same styling information that you use for
>> > lift:msgs and lift:msg snippets will be applied for AJax and Comet
>> > notices. The styling information is captured when these snippets are
>> > executed and used whenever you're using notices for AJax response or
>> > from a Comet actor.
>> >
>> >
>> > Br's,
>> > Marius
>> > >
>> >
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES ***

[Jorge Ortiz]

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 = {
>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 application.
> >
> > 1. LiftRules.logAndReturnExceptionToBrowser and
> > LiftRules.browserResponseToException have been removed. These were two
> > different variables that did pretty much the same thing in fact the
> > first ultimately called the former. These have been replaced with:
> >
> >
> > var exceptionHandler = RulesSeq[ExceptionHandlerPF]
> >
> > having
> >
> > type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value, Req,
> > Throwable), LiftResponse]
> >
> > By default a partial function is appended and it is the same code that
> > used to be for LiftRules.browserResponseToException.
> >
> > So up until now probably your application was using something like:
> >
> > LiftRules.logAndReturnExceptionToBrowser = {
> >case (state, ex) => RedirectResponse("/error")
> > }
> >
> > now this turns into:
> >
> > LiftRules.exceptionHandler.prepend = {
> >case (mode, state, ex) => RedirectResponse("/error")
> > }
> >
> >
> > 2. More unification of Ajax notices with "static" notices. So far to
> > apply styling information (css classes etc) to Ajax notices we used
> > three LiftRules variables:
> >
> >  var ajaxNoticeMeta: Can[AjaxMessageMeta]
> >  var ajaxWarningMeta: Can[AjaxMessageMeta]
> >  var ajaxErrorMeta: Can[AjaxMessageMeta]
> >
> > the motivation was that in order for Lift to send down the correct
> > style information for Ajax/Comet notices it needed to maintain this
> > information. Now I finally found time to do it. The above variables
> > are gone. Instead the same styling information that you use for
> > lift:msgs and lift:msg snippets will be applied for AJax and Comet
> > notices. The styling information is captured when these snippets are
> > executed and used whenever you're using notices for AJax response or
> > from a Comet actor.
> >
> >
> > Br's,
> > Marius
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES ***

[Oliver]

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 application.
>
> 1. LiftRules.logAndReturnExceptionToBrowser and
> LiftRules.browserResponseToException have been removed. These were two
> different variables that did pretty much the same thing in fact the
> first ultimately called the former. These have been replaced with:
>
>
> var exceptionHandler = RulesSeq[ExceptionHandlerPF]
>
> having
>
> type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value, Req,
> Throwable), LiftResponse]
>
> By default a partial function is appended and it is the same code that
> used to be for LiftRules.browserResponseToException.
>
> So up until now probably your application was using something like:
>
> LiftRules.logAndReturnExceptionToBrowser = {
>case (state, ex) => RedirectResponse("/error")
> }
>
> now this turns into:
>
> LiftRules.exceptionHandler.prepend = {
>case (mode, state, ex) => RedirectResponse("/error")
> }
>
>
> 2. More unification of Ajax notices with "static" notices. So far to
> apply styling information (css classes etc) to Ajax notices we used
> three LiftRules variables:
>
>  var ajaxNoticeMeta: Can[AjaxMessageMeta]
>  var ajaxWarningMeta: Can[AjaxMessageMeta]
>  var ajaxErrorMeta: Can[AjaxMessageMeta]
>
> the motivation was that in order for Lift to send down the correct
> style information for Ajax/Comet notices it needed to maintain this
> information. Now I finally found time to do it. The above variables
> are gone. Instead the same styling information that you use for
> lift:msgs and lift:msg snippets will be applied for AJax and Comet
> notices. The styling information is captured when these snippets are
> executed and used whenever you're using notices for AJax response or
> from a Comet actor.
>
>
> Br's,
> Marius
> >
>

--~--~-~--~~~---~--~~
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: *Breaking Changes* Getting down and CRUDy

[David Pollak]

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 of the CRUD stuff in
> mapper.
> > One word: supercalifragilisticexpialidocious!
> >
> > On Thu, Nov 20, 2008 at 7:23 PM, David Pollak <
> feeder.of.the.be...@gmail.com>
> > wrote: > > Folks, > ...
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
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: *Breaking Changes* Getting down and CRUDy

[TylerWeir]

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 Thu, Nov 20, 2008 at 7:23 PM, David Pollak 
> wrote: > > Folks, > ...
--~--~-~--~~~---~--~~
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: *Breaking Changes* Getting down and CRUDy

[David Pollak]

:-)

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


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

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

[Derek Chen-Becker]

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 in sitemap.Loc:
>
>- the "stuff" method has been renamed to "params"
>- the Loc.LocStuff trait has been renamed to Loc.LocParam
>
> Now the goodies:
>
>- Loc can carry around location specific snippets of code.  Lots of
>ways to do this, but the easiest is to include Loc.Snippet(name, NodeSeq =>
>NodeSeq) in the Loc's params.  This lets you do page specific snippets.
>- Loc can carry around a default template (this makes templating much
>easier for stuff like CRUD).  Include the Loc.Template(() => NodeSeq) in 
> the
>Loc's params.
>- Loc.breadCrumbs will build a list of Loc[_] to the current page.
>- SiteMap.buildMenu(Can[Loc[_]]) will build a complete menu given the
>current access control rules.
>- The CRUDify trait can be mixed into any KeyedMetaMapper to give you
>CRUD scaffolding.  Here's how it works:
>object Book extends Book with LongKeyedMetaMapper[Book] with
>CRUDify[Long, Book]
>and in boot, make sure that the menus into Book.menu
>That's all there is to making full CRUD apps in Lift
>
> Thanks,
>
> David
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

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

[Marius]

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 initialization.
>       This makes code cleaner.
>     * SHtml.submit() and SHtml.hidden() no longer take a "by-name"
>       parameter.  Instead the function to call on form submission must
>       be an explicit function.  This means that it's more apparent
>       what's happening.
>
> Thanks,
>
> David
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *breaking changes* Gravatar widget

[Tim Perrett]

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 this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *breaking changes* Gravatar widget

[TylerWeir]

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 class, its an object with overloaded
> apply methods. So, now, rather than:
>
> val g = new Gravatar()
> g.render("[EMAIL PROTECTED]")
>
> You need to do:
>
> Gravatar("[EMAIL PROTECTED]")
>
> Or, if you want an image with a set size, you do:
>
> Gravatar("[EMAIL PROTECTED]", 50)
>
> Or, if you want to produce one thats for a set rating (other than the
> default "G") do:
>
> Gravatar("[EMAIL PROTECTED]", 50, "R")
>
> Hope thats all ok for everyone
>
> Cheers, Tim
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *breaking changes* Gravatar widget

[David Pollak]

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 methods. So, now, rather than:
>
> val g = new Gravatar()
> g.render("[EMAIL PROTECTED]")
>
> You need to do:
>
> Gravatar("[EMAIL PROTECTED]")
>
> Or, if you want an image with a set size, you do:
>
> Gravatar("[EMAIL PROTECTED]", 50)
>
> Or, if you want to produce one thats for a set rating (other than the
> default "G") do:
>
> Gravatar("[EMAIL PROTECTED]", 50, "R")
>
> Hope thats all ok for everyone
>
> Cheers, Tim
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---