[Lift] Re: Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields
Excellent work Ross !
On Feb 12, 6:49 am, Ross Mellgren dri...@gmail.com wrote:
I just committed a change to lift-record in 2.0-SNAPSHOT that will possibly
(probably?) break your build if you use it.
This change makes it possible to have any record field be optional -- that
is, 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.
[Lift] Re: Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields
What is the advantage of doing it this way as opposed to having a
collection of Field types who's value is a Box[Whatever]
(OptionalStringField, OptionalLongField, etc).
I'm finding the e-mail you sent to the list moderately confusing.
Maybe it's just that more explanation is needed?
-harryh
On Feb 11, 11:49 pm, Ross Mellgren dri...@gmail.com wrote:
I just committed a change to lift-record in 2.0-SNAPSHOT that will possibly
(probably?) break your build if you use it.
This change makes it possible to have any record field be optional -- that
is, 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
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 dri...@gmail.com wrote:
I just committed a change to lift-record in 2.0-SNAPSHOT that will possibly
(probably?) break your build if you use it.
This change makes it possible to have any record field be optional -- that
is, 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**: Use mvn archetype:generate to generate 1.1-SNAPSHOT archetypes
Hello Indrajitr, When using archetype:generate without the command line args, why does it not build the latest release of the archetype? I saw that 1.1-M8 is in central but the version it builds uses lift-core 0.8. I'm not 100% on how it chooses the archetype version from the normal selection 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 indraj...@gmail.com 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**: Use mvn archetype:generate to generate 1.1-SNAPSHOT archetypes
Hello Joseph, Archetype list is picked up from the archetype catalog [1]. This is controlled by the parameter 'archetypeCatalog' when you invoke the goal 'archetype:generate' (defaults to 'internal,local') [2]. Thus, what you see by default is the internal list that is picked up from archetype-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 Raychaudhuriindraj...@gmail.com 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 *** to Loc LocParam
On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: On Mon, Nov 16, 2009 at 4:02 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:12 PM, 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. 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
On Nov 17, 3:37 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com wrote: [...] Did this ever get resolved? I'm still seeing this after an update to latest. This is pretty major, so I looked into it and found this: 1) The 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=.
Re: [Lift] Re: *** BREAKING CHANGES *** to Loc LocParam
On Tue, Nov 17, 2009 at 7:37 AM, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: On Mon, Nov 16, 2009 at 4:02 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:12 PM, 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. 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=.
Re: [Lift] Re: *** BREAKING CHANGES *** to Loc LocParam
On Tue, Nov 17, 2009 at 7:30 AM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: On Tue, Nov 17, 2009 at 7:37 AM, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: On Mon, Nov 16, 2009 at 4:02 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: Hi, all, I was just informed that my changes broke MetaMegaProtoUser interaction. I've reverted the commit until I can get 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.comliftweb%2bunsubscr...@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=.
[Lift] Re: *** BREAKING CHANGES *** to Loc LocParam
Hi, all, I was just informed that my changes broke MetaMegaProtoUser interaction. I've reverted the commit until I can get that sorted out. Sorry, Kris On Mon, Nov 16, 2009 at 11:27 AM, Kris Nuttycombe kris.nuttyco...@gmail.com 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 *** to Loc LocParam
On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: Hi, all, I was just informed that my changes broke MetaMegaProtoUser interaction. I've reverted the commit until I can get that sorted out. How was it broken? Sorry, Kris On Mon, Nov 16, 2009 at 11:27 AM, Kris Nuttycombe kris.nuttyco...@gmail.com 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
On Mon, Nov 16, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: Hi, all, I was just informed that my changes broke MetaMegaProtoUser interaction. I've reverted the commit until I can get 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 kris.nuttyco...@gmail.com 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
On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: On Mon, Nov 16, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: Hi, all, I was just informed 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 kris.nuttyco...@gmail.com 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 -- 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
[Lift] Re: *** BREAKING CHANGES *** to Loc LocParam
On Mon, Nov 16, 2009 at 4:02 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:12 PM, 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. 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 kris.nuttyco...@gmail.com 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
On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: On Mon, Nov 16, 2009 at 4:02 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: Hi, all, I was just informed that my changes broke MetaMegaProtoUser interaction. I've reverted the commit until I can get 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 kris.nuttyco...@gmail.com 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
On Mon, Nov 16, 2009 at 4:11 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Mon, Nov 16, 2009 at 4:02 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe kris.nuttyco...@gmail.com wrote: On Mon, Nov 16, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Nov 16, 2009 at 2:12 PM, 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. 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 kris.nuttyco...@gmail.com 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
[Lift] Re: **Breaking Changes** **README** **Important**
You're right, my bad - an old pom was looking at the wrong repo, all happy now. Cheers Jono 2009/10/22 David Pollak feeder.of.the.be...@gmail.com On Wed, Oct 21, 2009 at 10:27 PM, Jonathan Ferguson j...@spiralarm.comwrote: Do we need to update our pom's or should it be code changes only ? 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 feeder.of.the.be...@gmail.com Folks, As the title of this email indicates, there are breaking changes in Lift that just got pushed to master. We've migrated from Scala Actors to Lift 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**
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 indraj...@gmail.com 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 feeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com Folks, As the title of this email indicates, there are breaking changes in Lift that just got pushed to master. We've migrated from Scala Actors to Lift 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**
- 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**
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 geo...@mattandgeorge.com 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**
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**
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**
It would be good to have an example like George's verified as it is not clear how to convert our Actor code. Dan On Oct 22, 4:48 am, george geo...@mattandgeorge.com wrote: ok so.. object LocalSmtp extends Actor should become object LocalSmtp extends GenericActor[LocalSmtp] ? --~--~-~--~~~---~--~~ 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**
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 olearydani...@gmail.com 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 geo...@mattandgeorge.com 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**
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 olearydani...@gmail.com 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 olearydani...@gmail.com 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 geo...@mattandgeorge.com 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**
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**
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 feeder.of.the.be...@gmail.com 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**
RrttrRrrrtrtrtrrrtrtrtrrttÞ Sent on the Now Network™ from my Sprint® BlackBerry -Original Message- From: ssid j.gat...@googlemail.com Date: Thu, 22 Oct 2009 18:03:25 To: Liftliftweb@googlegroups.com Subject: [Lift] Re: **Breaking Changes** **README** **Important** Hi all, 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 feeder.of.the.be...@gmail.com 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**
On Thu, Oct 22, 2009 at 6:28 PM, Jim Barrows jim.barr...@gmail.com wrote: RrttrRrrrtrtrtrrrtrtrtrrttÞ bless you. Sent on the Now Network™ from my Sprint® BlackBerry -Original Message- From: ssid j.gat...@googlemail.com Date: Thu, 22 Oct 2009 18:03:25 To: Liftliftweb@googlegroups.com Subject: [Lift] Re: **Breaking Changes** **README** **Important** Hi all, 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 feeder.of.the.be...@gmail.com 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**
On Thu, Oct 22, 2009 at 6:03 PM, ssid j.gat...@googlemail.com wrote: Hi all, I'm using XMPP in my little LiftApp and tried to migrate my code to the new Lift Actors. Somehow it seems that net.liftweb.xmpp still uses Scala Actors. Is this intentional or about to change? I was lazy and 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 feeder.of.the.be...@gmail.com 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**
If we are using Actors for non Comet based stuff I assume we are free to leave them as is as long as we don't come asking for support ? I am thinking about moving through switching them over, but I'd like to do it at a leisurely pace. Jono 2009/10/23 David Pollak feeder.of.the.be...@gmail.com On Thu, Oct 22, 2009 at 6:03 PM, ssid j.gat...@googlemail.com wrote: Hi all, I'm using XMPP in my little LiftApp and tried to migrate my code to the new Lift Actors. Somehow it seems that net.liftweb.xmpp still uses Scala Actors. Is this intentional or about to change? I was lazy and 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 feeder.of.the.be...@gmail.com 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**
On Thu, Oct 22, 2009 at 8:54 PM, Jonathan Ferguson j...@spiralarm.comwrote: If we are using Actors for non Comet based stuff I assume we are free to leave them as is as long as we don't come asking for support ? Absolutely. Use the Actor library that best suits your needs. I am thinking about moving through switching them over, but I'd like to do it at a leisurely pace. Jono 2009/10/23 David Pollak feeder.of.the.be...@gmail.com On Thu, Oct 22, 2009 at 6:03 PM, ssid j.gat...@googlemail.com wrote: Hi all, I'm using XMPP in my little LiftApp and tried to migrate my code to the new Lift Actors. Somehow it seems that net.liftweb.xmpp still uses Scala Actors. Is this intentional or about to change? I was lazy and 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 feeder.of.the.be...@gmail.com 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**
Do we need to update our pom's or should it be code changes only ? Cheers Jono 2009/10/22 David Pollak feeder.of.the.be...@gmail.com Folks, As the title of this email indicates, there are breaking changes in Lift that just got pushed to master. We've migrated from Scala Actors to Lift 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**
On Wed, Oct 21, 2009 at 10:27 PM, Jonathan Ferguson j...@spiralarm.comwrote: Do we need to update our pom's or should it be code changes only ? You likely only need to make the code change... at least that's been the case for all the projects I've converted. Cheers Jono 2009/10/22 David Pollak feeder.of.the.be...@gmail.com Folks, As the title of this email indicates, there are breaking changes in Lift that just got pushed to master. We've migrated from Scala Actors to Lift 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**
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 feeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com Folks, As the title of this email indicates, there are breaking changes in Lift that just got pushed to master. We've migrated from Scala Actors to Lift 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
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 --~--~-~--~~~---~--~~ 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
Given the on again/off again nature of the issue, I'm voting for adding your change. We can rely on your code working until the issue is sorted with the Scala team. So, +1 to dpp's code. On Sep 16, 9:14 am, David Pollak feeder.of.the.be...@gmail.com wrote: Guys, The Scala Actor issue has 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
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 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 --~--~-~--~~~---~--~~ 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
What is the problem this time? .. same thing essentially? Br's, Marius On Sep 16, 8:14 am, David Pollak feeder.of.the.be...@gmail.com wrote: Guys, The Scala Actor issue has raised its head again. From November 2008 - June 2009, I did an epic battle with Scala actors and their memory 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
I haven't used comet, but would it be worthwhile to abstract it with implementations (potentially) for Scala, Lift, and Akka actors? - TylerWeirtyler.w...@gmail.com wrote: Given the on again/off again nature of the issue, I'm voting for adding your change. We can rely on your code working until the issue is sorted with the Scala team. So, +1 to dpp's code. On Sep 16, 9:14?am, David Pollak feeder.of.the.be...@gmail.com wrote: Guys, The Scala Actor issue has 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
On Wed, Sep 16, 2009 at 3:42 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: I haven't used comet, but would it be worthwhile to abstract it with implementations (potentially) for Scala, Lift, and Akka actors? I've integrated Atmosphere http://atmosphere.dev.java.net/ into Akka, and I know that Jeanfrançois Arcand (Atmosphere dude) has shown interest in integrating it into Lift. - TylerWeirtyler.w...@gmail.com 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 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 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
On Wed, Sep 16, 2009 at 6:27 AM, Kevin Wright kev.lee.wri...@googlemail.com wrote: Is there any reason not to go with something like the Akka framework? I believe it has a lift-friendly license. I can work on a way to make CometActors work with Akka Actors or Lift Actors. Jonas and I have 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
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 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 --~--~-~--~~~---~--~~ 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
On Wed, Sep 16, 2009 at 4:50 PM, Timothy Perrett timo...@getintheloop.euwrote: Kevin, To clarify, your talking about akka-actors? The preferred route I think would be to use a fixed EPFL implementation, however, in leu of that i think from a project perspective it would be beneficial for 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
On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett timo...@getintheloop.euwrote: Kevin, To clarify, your talking about akka-actors? The preferred route I think would be to use a fixed EPFL implementation, however, in leu of that i think from a project perspective it would be beneficial for 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
I vote for lift-actor. On Wed, Sep 16, 2009 at 10:46 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett timo...@getintheloop.euwrote: Kevin, To clarify, your talking about akka-actors? The preferred route I think would be to use a 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
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 feeder.of.the.be...@gmail.com On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett timo...@getintheloop.euwrote: Kevin, To clarify, your talking about akka-actors? The preferred route I think would be to use a fixed EPFL implementation, however, in leu of that i think from a project perspective it would be beneficial for 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 COMMITTED ***
Dear all, I'f committed today in the master the support for abstracting HTTP stack in lift so that Lift itself does not depend on javax.servlet._ classes. This allows us to add support for Netty, AsyncWeb, etc. or even your own implementation of a HTTP server etc. This effort lead to several 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. marius.dan...@gmail.com wrote: And looks to perform a bit better then MINA. On Aug 5, 2:13 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: Netty looks really cool. On a quick read it sounds maybe a little like MINA, although it definitely looks like it has a more high-level API to simplify things. On Wed, Aug 5, 2009 at 5:08 AM, marius d. marius.dan...@gmail.com wrote: Sounds good to me On Aug 5, 1:51 pm, Yousry Abdallah yous...@gmail.com wrote: Could you setup a milestone before the merge? On 4 Aug., 21:51, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code 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 ***
Impressive stuff :) On Fri, Aug 7, 2009 at 6:54 PM, marius d. marius.dan...@gmail.com wrote: Dear all, I'f committed today in the master the support for abstracting HTTP stack in lift so that Lift itself does not depend on javax.servlet._ classes. This allows us to add support for Netty, 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. marius.dan...@gmail.com wrote: And looks to perform a bit better then MINA. On Aug 5, 2:13 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: Netty looks really cool. On a quick read it sounds maybe a little like MINA, although it definitely looks like it has a more high-level API to simplify things. On Wed, Aug 5, 2009 at 5:08 AM, marius d. marius.dan...@gmail.com wrote: Sounds good to me On Aug 5, 1:51 pm, Yousry Abdallah yous...@gmail.com wrote: Could you setup a milestone before the merge? On 4 Aug., 21:51, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code 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 ***
On Fri, Aug 7, 2009 at 12:35 PM, Kevin Wright kev.lee.wri...@googlemail.com wrote: Impressive stuff :) +1 Way to go Marius. On Fri, Aug 7, 2009 at 6:54 PM, marius d. marius.dan...@gmail.com wrote: Dear all, I'f committed today in the master the support for abstracting HTTP stack 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. marius.dan...@gmail.com wrote: And looks to perform a bit better then MINA. On Aug 5, 2:13 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: Netty looks really cool. On a quick read it sounds maybe a little like MINA, although it definitely looks like it has a more high-level API to simplify things. On Wed, Aug 5, 2009 at 5:08 AM, marius d. marius.dan...@gmail.com wrote: Sounds good to me On Aug 5, 1:51 pm, Yousry Abdallah yous...@gmail.com wrote: Could you setup a milestone before the merge? On 4 Aug., 21:51, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code 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 ***
Portlets have some mixed press, so im not sure how much of a win that will be. The AsyncWeb / Netty stuff does look pretty freaking cool tho. Cheers, Tim On Aug 4, 10:40 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: Cool. I'll have to look at portlets and see what they do. Derek On Tue, Aug 4, 2009 at 2:38 PM, David Pollak feeder.of.the.be...@gmail.comwrote: On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: I don't necessarily have a problem with this, but what's the 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 marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code is currently in wip-marius-http- abstractions. I still need to nail down a few 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 ***
Could you setup a milestone before the merge? On 4 Aug., 21:51, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code is currently in wip-marius-http- abstractions. I still need to nail down a few 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 ***
Sounds good to me On Aug 5, 1:51 pm, Yousry Abdallah yous...@gmail.com wrote: Could you setup a milestone before the merge? On 4 Aug., 21:51, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code 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 ***
Netty looks really cool. On a quick read it sounds maybe a little like MINA, although it definitely looks like it has a more high-level API to simplify things. On Wed, Aug 5, 2009 at 5:08 AM, marius d. marius.dan...@gmail.com wrote: Sounds good to me On Aug 5, 1:51 pm, Yousry Abdallah yous...@gmail.com wrote: Could you setup a milestone before the merge? On 4 Aug., 21:51, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code 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 ***
And looks to perform a bit better then MINA. On Aug 5, 2:13 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: Netty looks really cool. On a quick read it sounds maybe a little like MINA, although it definitely looks like it has a more high-level API to simplify things. On Wed, Aug 5, 2009 at 5:08 AM, marius d. marius.dan...@gmail.com wrote: Sounds good to me On Aug 5, 1:51 pm, Yousry Abdallah yous...@gmail.com wrote: Could you setup a milestone before the merge? On 4 Aug., 21:51, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code 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 ***
On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: I don't necessarily have a problem with this, but what's the gain? Are there other HTTP frameworks that don't use the javax.servlet API? Just curious. Yes, Jersey directly, portlets, etc. Derek On Tue, Aug 4, 2009 at 1:51 PM, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code is currently in wip-marius-http- abstractions. I still need to nail down a few 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 ***
Cool. I'll have to look at portlets and see what they do. Derek On Tue, Aug 4, 2009 at 2:38 PM, David Pollak feeder.of.the.be...@gmail.comwrote: On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: I don't necessarily have a problem with this, but what's the 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 marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code is currently in wip-marius-http- abstractions. I still need to nail down a few 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 ***
Things like AsyncWeb, some HTTP stacks on top of Netty ... Br's, Marius On Aug 4, 11:37 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I don't necessarily have a problem with this, but what's the gain? Are there other HTTP frameworks that don't use the javax.servlet API? Just curious. Derek On Tue, Aug 4, 2009 at 1:51 PM, Marius marius.dan...@gmail.com wrote: Folks, I spent a few days decoupling Lift from JEE web container dependencies: javax.servlet._ The code is currently in wip-marius-http- abstractions. I still need to nail down a few 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 ***
Doesn't look right and If I do this I get the following error -
constructor cannot be instantiated to the expected type
On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz jorge.or...@gmail.com wrote:
Try (without the = sign):
LiftRules.exceptionHandler.prepend {
case (mode, state, ex) = RedirectResponse(/error)
}
--j
On Mon, Feb 9, 2009 at 10:47 PM, Oliver ola...@gmail.com 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 marius.dan...@gmail.com 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,
What version of Lift are you using?
Thanks,
David
On Tue, Feb 10, 2009 at 2:58 PM, Oliver ola...@gmail.com wrote:
Doesn't look right and If I do this I get the following error -
constructor cannot be instantiated to the expected type
On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz jorge.or...@gmail.com
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 ola...@gmail.com 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 marius.dan...@gmail.com
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 ***
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 ola...@gmail.com wrote:
Doesn't look right and If I do this I get the following error -
constructor cannot be instantiated to the expected type
On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz jorge.or...@gmail.com 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 ola...@gmail.com 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 marius.dan...@gmail.com 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 ***
On Tue, Feb 10, 2009 at 3:13 PM, Oliver ola...@gmail.com wrote:
I've just updated my code to rely on the stable version of lift 0.10
rather than an earlier snapshot.
Unfortunately the removal of LiftRules.logAndReturnExceptionToBrowser
and non working status of
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 ola...@gmail.com wrote:
Doesn't look right and If I do this I get the following error -
constructor cannot be instantiated to the expected type
On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz jorge.or...@gmail.com
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 ola...@gmail.com 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 marius.dan...@gmail.com
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 ***
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
feeder.of.the.be...@gmail.com wrote:
On Tue, Feb 10, 2009 at 3:13 PM, Oliver ola...@gmail.com wrote:
I've just updated my code to rely on the stable version of lift 0.10
rather than an earlier snapshot.
Unfortunately the removal of LiftRules.logAndReturnExceptionToBrowser
and non working status of
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 ola...@gmail.com wrote:
Doesn't look right and If I do this I get the following error -
constructor cannot be instantiated to the expected type
On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz jorge.or...@gmail.com
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 ola...@gmail.com 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 marius.dan...@gmail.com
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 ***
On Tue, Feb 10, 2009 at 3:52 PM, Oliver ola...@gmail.com wrote:
My apologies, it works as shown by your code and in the way Jorge
described. I had changed simply cut and pasted Marius's example
and deleted it when it didn't work. Then I changed my own code without
modifying the case 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
feeder.of.the.be...@gmail.com wrote:
On Tue, Feb 10, 2009 at 3:13 PM, Oliver ola...@gmail.com wrote:
I've just updated my code to rely on the stable version of lift 0.10
rather than an earlier snapshot.
Unfortunately the removal of LiftRules.logAndReturnExceptionToBrowser
and non working status of
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 ola...@gmail.com wrote:
Doesn't look right and If I do this I get the following error -
constructor cannot be instantiated to the expected type
On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz jorge.or...@gmail.com
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 ola...@gmail.com 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 marius.dan...@gmail.com
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
--
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
[Lift] Re: *** BREAKING CHANGES ***
If I try to use the following, I get a reassignment to Val error - any ideas?
LiftRules.exceptionHandler.prepend = {
case (mode, state, ex) = RedirectResponse(/error)
}
On Wed, Dec 24, 2008 at 5:41 AM, Marius marius.dan...@gmail.com 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
CRUDify is sweeet! (extra e for extra sweet) On Dec 2 2008, 2:02 pm, David Pollak feeder.of.the.be...@gmail.com wrote: :-) On Dec 2, 2008 11:00 AM, Derek Chen-Becker dchenbec...@gmail.com wrote: I just found this email while researching all of the CRUD stuff in mapper. One word: supercalifragilisticexpialidocious! On Thu, Nov 20, 2008 at 7:23 PM, David Pollak feeder.of.the.be...@gmail.com 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
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* Getting down and CRUDy
:-) On Dec 2, 2008 11:00 AM, Derek Chen-Becker [EMAIL PROTECTED] wrote: I just found this email while researching all of the CRUD stuff in mapper. One word: supercalifragilisticexpialidocious! On Thu, Nov 20, 2008 at 7:23 PM, David Pollak [EMAIL PROTECTED] wrote: Folks, ... --~--~-~--~~~---~--~~ 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()
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
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 -~--~~~~--~~--~--~---
[Lift] Re: *breaking changes* Gravatar widget
Much better than my initial impl. Thanks and good stuff. On Nov 1, 7:18 am, Tim Perrett [EMAIL PROTECTED] wrote: Hey guys, I've updated the Gravatar widget that was origionally created by Ty. The implementation now is actually very different. No longer is the Gravatar class an 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 -~--~~~~--~~--~--~---
