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

2010-02-12 Thread Marius
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

2010-02-11 Thread harryh
What is the advantage of doing it this way as opposed to having a
collection of Field types who's value is a Box[Whatever]
(OptionalStringField, OptionalLongField, etc).

I'm finding the e-mail you sent to the list moderately confusing.
Maybe it's just that more explanation is needed?

-harryh

On Feb 11, 11:49 pm, Ross Mellgren 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

2010-02-11 Thread Ross Mellgren
Originally I had implemented this like you suggest, with separate field types. 
Marius reviewed it and preferred it to be baked into the basic field type.

The advantages over that method are:
 - Not requiring 2x the number of field types everywhere. For example any 
record implementation that extends fields needs double (e.g. DBIntField, 
DBOptionalIntField)
 - Less code
 - Centralizes error handling.

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

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

-Ross

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

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


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

 What is the advantage of doing it this way as opposed to having a
 collection of Field types who's value is a Box[Whatever]
 (OptionalStringField, OptionalLongField, etc).
 
 I'm finding the e-mail you sent to the list moderately confusing.
 Maybe it's just that more explanation is needed?
 
 -harryh
 
 On Feb 11, 11:49 pm, Ross Mellgren 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

2009-12-27 Thread joseph hirn
Hello Indrajitr,

When using archetype:generate without the command line args, why does
it not build the latest release of the archetype? I saw that 1.1-M8 is
in central but the version it builds uses lift-core 0.8.

I'm not 100% on how it chooses the archetype version from the normal
selection menu but it would be nice to get something relatively more
up to date.

Sorry if this is discussed elsewhere.


On Dec 1, 8:28 am, Indrajit Raychaudhuri 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

2009-12-27 Thread Indrajit Raychaudhuri
Hello Joseph,

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

Thus, what you see by default is the internal list that is picked up 
from archetype-catalog.xml that is bundled internally. That catalog is 
an old one.

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

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

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

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

Cheers, Indrajit


On 28/12/09 1:35 AM, joseph hirn wrote:
 Hello Indrajitr,

 When using archetype:generate without the command line args, why does
 it not build the latest release of the archetype? I saw that 1.1-M8 is
 in central but the version it builds uses lift-core 0.8.

 I'm not 100% on how it chooses the archetype version from the normal
 selection menu but it would be nice to get something relatively more
 up to date.

 Sorry if this is discussed elsewhere.


 On Dec 1, 8:28 am, Indrajit 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

2009-11-17 Thread Jeppe Nejsum Madsen
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

2009-11-17 Thread Jeppe Nejsum Madsen


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

2009-11-17 Thread Kris Nuttycombe
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

2009-11-17 Thread David Pollak
On Tue, Nov 17, 2009 at 7:30 AM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:

 On Tue, Nov 17, 2009 at 7:37 AM, Jeppe Nejsum Madsen je...@ingolfs.dk
 wrote:
  On Nov 17, 12:11 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
  On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe
  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

2009-11-16 Thread Kris Nuttycombe

Hi, all,

I was just informed that my changes broke MetaMegaProtoUser
interaction. I've reverted the commit until I can get that sorted out.

Sorry,

Kris

On Mon, Nov 16, 2009 at 11:27 AM, Kris Nuttycombe
kris.nuttyco...@gmail.com wrote:
 Hi, all,

 I have committed a number of enhancements to 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

2009-11-16 Thread David Pollak
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

2009-11-16 Thread Kris Nuttycombe

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

2009-11-16 Thread David Pollak
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

2009-11-16 Thread Kris Nuttycombe

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

2009-11-16 Thread David Pollak
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

2009-11-16 Thread Kris Nuttycombe

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

2009-10-22 Thread Jonathan Ferguson
You're right, my bad - an old pom was looking at the wrong repo, all happy
now.

Cheers
Jono

2009/10/22 David Pollak 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**

2009-10-22 Thread soumik

Hi,
I've a few question regarding the changes made.
- Firstly, with the changes made, how do I have a method which can now
accept both scala Actor as well as a CometActor??
  Prior to the changes, I had a function def registerActor(act:
Actor) which could handle both scala Actor as well as CometActor,; now
if I change this to def registerActor(act: GenericActor) it throws
compilation error asking to a type to be specified for the
GenericActor. What change would you suggest to have my code compile?
- Secondly, I also get compilation error for calling
scheduleAtFixedRate method on ActorPing. Says no such method. Has this
method been deprecated and if so, what is the method I should be
calling instead?

Thanks,
Soumik

On Oct 22, 10:35 am, Indrajit Raychaudhuri 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**

2009-10-22 Thread george

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

I have this problem also.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



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

2009-10-22 Thread Viktor Klang
DPP (and I) recommend just doing schedule and then re-schedule after message
recieved.

schedule(actor,MyMsg(),3 seconds)

in the actor

{
   case MyMsg() = {
doMyStuff
schedule(this,MyMsg(),3 seconds)
}
}

Makes sense?

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

2009-10-22 Thread Timothy Perrett


Guys,

   Prior to the changes, I had a function def registerActor(act:
 Actor) which could handle both scala Actor as well as CometActor,; now
 if I change this to def registerActor(act: GenericActor) it throws
 compilation error asking to a type to be specified for the
 GenericActor. What change would you suggest to have my code compile?

Checkout the declaration:

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

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

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

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

Cheers, Tim

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



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

2009-10-22 Thread george

ok so..

object LocalSmtp extends Actor

should become

object LocalSmtp extends GenericActor[LocalSmtp]

?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



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

2009-10-22 Thread Dano

It would be good to have an example like George's verified as it is
not clear how to convert our Actor code.



Dan

On Oct 22, 4:48 am, george 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**

2009-10-22 Thread Dano

I did a quick check in the lift sources and could not find example or
test code for the new LiftActors.  Perhaps additions to these areas
would help those that are trying to convert their Actor code.

Thanks in advance for any help for those still struggling to make the
conversion.


Dan

On Oct 22, 10:00 am, Dano 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**

2009-10-22 Thread Dano

Code for our app now compiles.  Needed to replace Actor with
LiftActor.  Also, needed to define the messageHandler partial
function.

So, George, I think the answer to your question is:

object LocalSmtp extends Actor

becomes

object LocalSmtp extends LiftActor


Dan

On Oct 22, 11:19 am, Dano 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**

2009-10-22 Thread george

Thanks Dan, I will try that.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



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

2009-10-22 Thread ssid

Hi all,
I'm using XMPP in my little LiftApp and tried to migrate my code to
the new Lift Actors.
Somehow it seems that net.liftweb.xmpp still uses Scala Actors.
Is this intentional or about to change?
If not is it possible that Scala Actors communicate with Lift Actors?
At the moment I don't get my project to compile due to some type
mismatch errors but that might also be my lack of understanding
of the different Actor implementations.

Thanks,
ssid

On 22 Okt., 05:37, David Pollak 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**

2009-10-22 Thread Jim Barrows
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**

2009-10-22 Thread David Pollak
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**

2009-10-22 Thread David Pollak
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**

2009-10-22 Thread Jonathan Ferguson
If we are using Actors for non Comet based stuff I assume we are free to
leave them as is as long as we don't come asking for support ?
I am thinking about moving through switching them over, but I'd like to do
it at a leisurely pace.

Jono


2009/10/23 David Pollak 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**

2009-10-22 Thread David Pollak
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**

2009-10-21 Thread Jonathan Ferguson
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**

2009-10-21 Thread David Pollak
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**

2009-10-21 Thread Indrajit Raychaudhuri

Code change should suffice.

pom.xml updates won't be necessary since lift-util has lift-common as 
dependency and your application (which must be having lift-util as 
dependency) would resolve the lift-common dependency transitively.

Cheers, Indrajit

On 22/10/09 10:57 AM, Jonathan Ferguson wrote:
 Do we need to update our pom's or should it be code changes only ?

 Cheers

 Jono

 2009/10/22 David Pollak 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

2009-09-16 Thread Kevin Wright
Is there any reason not to go with something like the Akka framework?  I
believe it has a lift-friendly license.

On Wed, Sep 16, 2009 at 2:14 PM, David Pollak 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

2009-09-16 Thread TylerWeir

Given the on again/off again nature of the issue, I'm voting for
adding your change.
We can rely on your code working until the issue is sorted with the
Scala team.

So, +1 to dpp's code.

On Sep 16, 9:14 am, David Pollak 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

2009-09-16 Thread Timothy Perrett
Hey David,

Are you saying that scala actors are leaking outside of large rate  
construction / destruction situations? At least, I remember that was  
what was tickling the EPFL bug last time :-)

This has pretty major ramifications if it is! Personally, I'm happy to  
move to lift-actor.

Cheers

Tim

Sent from my iPhone

On 16 Sep 2009, at 14:14, David Pollak 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

2009-09-16 Thread marius d.

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

2009-09-16 Thread Naftoli Gugenheim

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

2009-09-16 Thread Viktor Klang
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

2009-09-16 Thread David Pollak
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

2009-09-16 Thread Timothy Perrett
Kevin,

To clarify, your talking about akka-actors?

The preferred route I think would be to use a fixed EPFL  
implementation, however, in leu of that i think from a project  
perspective it would be beneficial for lift to have a corrected actor  
implementation that we have direct control of. I know DPP would  
certainly have this be his preference despite Jonas, Viktor and myself  
being commiters on both projects :-)

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

Cheers, Tim



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

 Is there any reason not to go with something like the Akka  
 framework?  I believe it has a lift-friendly license.

 On Wed, Sep 16, 2009 at 2:14 PM, David Pollak 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

2009-09-16 Thread Viktor Klang
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

2009-09-16 Thread David Pollak
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

2009-09-16 Thread Derek Chen-Becker
I vote for lift-actor.

On Wed, Sep 16, 2009 at 10:46 AM, David Pollak 
feeder.of.the.be...@gmail.com wrote:



 On Wed, Sep 16, 2009 at 7:50 AM, Timothy Perrett 
 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

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

Heiko

2009/9/16 David Pollak 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 ***

2009-08-07 Thread marius d.

Dear all,

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

This effort lead to several breaking changes:

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

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

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

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

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

Br's,
Marius

On Aug 5, 3:05 pm, marius d. 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 ***

2009-08-07 Thread Kevin Wright
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 ***

2009-08-07 Thread David Pollak
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 ***

2009-08-05 Thread Timothy Perrett

Portlets have some mixed press, so im not sure how much of a win that
will be. The AsyncWeb / Netty stuff does look pretty freaking cool
tho.

Cheers, Tim

On Aug 4, 10:40 pm, Derek Chen-Becker 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 ***

2009-08-05 Thread Yousry Abdallah

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

2009-08-05 Thread marius d.

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

2009-08-05 Thread Derek Chen-Becker
Netty looks really cool. On a quick read it sounds maybe a little like MINA,
although it definitely looks like it has a more high-level API to simplify
things.

On Wed, Aug 5, 2009 at 5:08 AM, marius d. 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 ***

2009-08-05 Thread marius d.

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

2009-08-04 Thread David Pollak
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 ***

2009-08-04 Thread Derek Chen-Becker
Cool. I'll have to look at portlets and see what they do.

Derek

On Tue, Aug 4, 2009 at 2:38 PM, David Pollak
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 ***

2009-08-04 Thread marius d.

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

2009-02-10 Thread Oliver

Doesn't look right and If I do this I get the following error -
constructor cannot be instantiated to the expected type

On Tue, Feb 10, 2009 at 8:57 PM, Jorge Ortiz 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 ***

2009-02-10 Thread David Pollak
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 ***

2009-02-10 Thread Oliver

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

1) To back out my reliance on the stable version of lift 0.10
2) To look at the source code for lift and try to figure out the problem
3) To remove my applications reliance on this code

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

On Wed, Feb 11, 2009 at 9:58 AM, Oliver 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 ***

2009-02-10 Thread David Pollak
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 ***

2009-02-10 Thread Oliver

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

On Wed, Feb 11, 2009 at 10:26 AM, David Pollak
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 ***

2009-02-10 Thread David Pollak
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 ***

2009-02-09 Thread Oliver

If I try to use the following, I get a reassignment to Val error - any ideas?

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

On Wed, Dec 24, 2008 at 5:41 AM, Marius 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

2009-01-19 Thread TylerWeir

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

2008-12-02 Thread Derek Chen-Becker
I just found this email while researching all of the CRUD stuff in mapper.
One word: supercalifragilisticexpialidocious!

On Thu, Nov 20, 2008 at 7:23 PM, David Pollak [EMAIL PROTECTED]
 wrote:

 Folks,

 I've been cleaning up code and adding features left and right.

 First, the breaking changes in sitemap.Loc:

- the stuff method has been renamed to params
- the Loc.LocStuff trait has been renamed to Loc.LocParam

 Now the goodies:

- Loc can carry around location specific snippets of code.  Lots of
ways to do this, but the easiest is to include Loc.Snippet(name, NodeSeq =
NodeSeq) in the Loc's params.  This lets you do page specific snippets.
- Loc can carry around a default template (this makes templating much
easier for stuff like CRUD).  Include the Loc.Template(() = NodeSeq) in 
 the
Loc's params.
- Loc.breadCrumbs will build a list of Loc[_] to the current page.
- SiteMap.buildMenu(Can[Loc[_]]) will build a complete menu given the
current access control rules.
- The CRUDify trait can be mixed into any KeyedMetaMapper to give you
CRUD scaffolding.  Here's how it works:
object Book extends Book with LongKeyedMetaMapper[Book] with
CRUDify[Long, Book]
and in boot, make sure that the menus into Book.menu
That's all there is to making full CRUD apps in Lift

 Thanks,

 David



 --
 Lift, the simply functional web framework http://liftweb.net
 Collaborative Task Management http://much4.us
 Follow me: http://twitter.com/dpp
 Git some: http://github.com/dpp

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



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

2008-12-02 Thread David Pollak


:-)

On Dec 2, 2008 11:00 AM, Derek Chen-Becker [EMAIL PROTECTED] wrote:

I just found this email while researching all of the CRUD stuff in mapper. 
One word: supercalifragilisticexpialidocious!

On Thu, Nov 20, 2008 at 7:23 PM, David Pollak [EMAIL PROTECTED] 
wrote:   Folks,  ...


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



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

2008-11-08 Thread Marius

Nice stuff for CometActor ... it's really handy having the session
etc. to be injected automatically by Lift

Br's,
Marius

On Nov 7, 3:14 am, David Pollak [EMAIL PROTECTED] wrote:
 Folks,

 I've make some breaking changes to Lift:

     * CometActors no longer take any parameters during initialization.
       This makes code cleaner.
     * SHtml.submit() and SHtml.hidden() no longer take a by-name
       parameter.  Instead the function to call on form submission must
       be an explicit function.  This means that it's more apparent
       what's happening.

 Thanks,

 David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: *breaking changes* Gravatar widget

2008-11-01 Thread David Pollak
Excellent stuff!

On 11/1/08, Tim Perrett [EMAIL PROTECTED] wrote:


 Hey guys,

 I've updated the Gravatar widget that was origionally created by Ty.
 The implementation now is actually very different. No longer is the
 Gravatar class an instansiable class, its an object with overloaded
 apply methods. So, now, rather than:

 val g = new Gravatar()
 g.render([EMAIL PROTECTED])

 You need to do:

 Gravatar([EMAIL PROTECTED])

 Or, if you want an image with a set size, you do:

 Gravatar([EMAIL PROTECTED], 50)

 Or, if you want to produce one thats for a set rating (other than the
 default G) do:

 Gravatar([EMAIL PROTECTED], 50, R)

 Hope thats all ok for everyone

 Cheers, Tim
 



-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: *breaking changes* Gravatar widget

2008-11-01 Thread TylerWeir

Much better than my initial impl.  Thanks and good stuff.

On Nov 1, 7:18 am, Tim Perrett [EMAIL PROTECTED] wrote:
 Hey guys,

 I've updated the Gravatar widget that was origionally created by Ty.
 The implementation now is actually very different. No longer is the
 Gravatar class an instansiable class, its an object with overloaded
 apply methods. So, now, rather than:

 val g = new Gravatar()
 g.render([EMAIL PROTECTED])

 You need to do:

 Gravatar([EMAIL PROTECTED])

 Or, if you want an image with a set size, you do:

 Gravatar([EMAIL PROTECTED], 50)

 Or, if you want to produce one thats for a set rating (other than the
 default G) do:

 Gravatar([EMAIL PROTECTED], 50, R)

 Hope thats all ok for everyone

 Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: *breaking changes* Gravatar widget

2008-11-01 Thread Tim Perrett

Glad you like it guys :-)

On Nov 1, 4:26 pm, TylerWeir [EMAIL PROTECTED] wrote:
 Much better than my initial impl.  Thanks and good stuff.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---