[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors

2009-10-23 Thread Heiko Seeberger
One small step for Lift and Akka, one giant leap for Scala!
Thanks, David and Jonas!

Heiko

2009/10/22 Marius marius.dan...@gmail.com


 Just Simple  Beautiful ! ... Nice work Dave and Jonas.

 Br's,
 Marius

 On Oct 22, 9:57 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  Folks,
 
  I wrote a quick blog piece about migrating from Scala Actors to Lift
 Actors
  athttp://blog.lostlake.org/index.php?/archives/96-Migrating-from-Scala-.
 ..
 
  I hope this addresses questions that folks on the list have about the
  affirmative steps they need to take to make the migration.
 
  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
 



-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--~--~-~--~~~---~--~~
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: catch a URL

2009-10-23 Thread Jeppe Nejsum Madsen

Chris Lewis burningodzi...@gmail.com writes:

 Hi list,

 I'm working on an appengine app, and need to store some user 
 information. I authenticate the user with their google account, and I 
 need to create their local entity only if it's their first time 
 logging in.

 When a user logs in via google, they are redirected back to your app, to 
 a URL of your choosing. My thought was to catch the request as it comes 
 back and, if it's their first time logging in, create a User entity. My 
 question then is how can I do this without:

 a) Using a snippet, called from the return landing page and emitting 
 NodeSeq.Empty - hack.

 b) Using custom dispatch and then redirecting. That may work, but it's 
 an unneeded round trip.

 Any thoughts? Thanks!

Not sure if the landing page is static, has parameters etc and what you
want to do afterwards. 

Assume you need to render some template and the landing page is not
static (if it is you could just use a normal Loc) I would probably wrap
the landing page in a RewriteRequest, and when a match is made, do the
user creation/lookup thing and then just render the template.

Tim wrote and article about rewriting
http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework

Also, I've been using the Locs from CRUDify as an example of how to do
more custom-type Locs with rewriting.

/Jeppe

--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread jlist9

Ross,

 Personally I think that Python is great for small simple things, but
 as soon as you start to scale the lack of statically checked
 guarantees starts to bite you.

What you said about the problems with dynamically typed
scripting language is very true. Python is so powerful but the
code is so fragile. You need to write a lot of tests. This is
exactly why I'm trying to learn Scala.

Thanks for your explanation about operators.

 Regarding () and {} BTW, you can replace a single-argument argument
 list with {}, e.g.

 def myFunction(a: String): Unit = println(a)

 myFunction(foobar)
 myFunction { foobar }

I find the following three lines of code do the same thing.
Thanks for your explanation again. I now understand
why the first and second line are equivalent. (But why
does Scala allow {} here? Isn't () good enough?)

I'm not sure what the {} does in the third line, though.

args.foreach{ arg = greeting += (arg +  ) }
args.foreach( arg = greeting += (arg +  ) )
args.foreach( arg = { greeting += (arg +  ) } )

 The two calls are equivalent. It makes more sense with the latter
 format with multiple argument lists or DSL-like things. I could write
 up an example if you're interested, but it might be somewhat involved
 if you're not familiar with Scala or Lift.

Thanks. Let me finish the tutorials first :-)

 Overall, my suggestion would be to stick with it and ask questions. I
 think it's worth it, and the people here are really helpful.

Yes. I plan to bite the bullet and continue with my learning.
And indeed, this is a very friendly and  helpful list.

jlist9

--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Ross Mellgren
On Oct 23, 2009, at 2:31 AM, jlist9 wrote:
 Regarding () and {} BTW, you can replace a single-argument argument
 list with {}, e.g.

 def myFunction(a: String): Unit = println(a)

 myFunction(foobar)
 myFunction { foobar }

 I find the following three lines of code do the same thing.
 Thanks for your explanation again. I now understand
 why the first and second line are equivalent. (But why
 does Scala allow {} here? Isn't () good enough?)

I find it's good when you're doing a block-like thing where it really  
expects a single value. Most often I use this with functions that do  
something scoped, e.g. acquire a resource and release it, or set  
some kind of semi-global variable temporarily (RequestVar.doWith,  
ThreadGlobal.doWith, for example).


 I'm not sure what the {} does in the third line, though.

 args.foreach{ arg = greeting += (arg +  ) }
 args.foreach( arg = greeting += (arg +  ) )
 args.foreach( arg = { greeting += (arg +  ) } )

The {}s in this case would allow you to have multiple statements  
there. To contrast:

args.map(arg = println(arg); arg.length)   // won't compile
args.map { arg = println(arg); arg.length }  // compiles
args.map(arg = { println(arg); arg.length }) // compiles

I personally prefer the last form because my editor will happily eat  
it and I get some consistency when there's arguments before the  
function argument. Of course, this is an aesthetic thing, I'm sure  
other people prefer the parenless form.

-Ross


--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Jonas Bonér

I love the _ operator.

2009/10/22 Timothy Perrett timo...@getintheloop.eu:

 I think this is a bit of a running joke in the scala comunity right
 now - your right, underscore really does have a number of meanings; I
 think this will be changed in some future Scala release.

 Your also forgetting:

 import some.package._

 Cheers, Tim

 On 22 Oct 2009, at 12:57, tiro wrote:

 underscore. At least four different uses:
 - it for defining anonymous functions like above
 - default value
 - matching placeholder whose value is ignored
 - use for constructing setter method names boolean functions (empty_?)


 




-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://scalablesolutions.se
code:   http://github.com/jboner
code:   http://akkasource.org
also:http://letitcrash.com

--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Joni Freeman

I love it too. While it is used in many different places it always
means stuff that I do not care to name.

BTW. high priest of the lambda calculus loves it too :) It has its
roots in Haskell...

http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-4-of-13/

Cheers Joni

On 23 loka, 09:48, Jonas Bonér jbo...@gmail.com wrote:
 I love the _ operator.

 2009/10/22 Timothy Perrett timo...@getintheloop.eu:





  I think this is a bit of a running joke in the scala comunity right
  now - your right, underscore really does have a number of meanings; I
  think this will be changed in some future Scala release.

  Your also forgetting:

  import some.package._

  Cheers, Tim

  On 22 Oct 2009, at 12:57, tiro wrote:

  underscore. At least four different uses:
  - it for defining anonymous functions like above
  - default value
  - matching placeholder whose value is ignored
  - use for constructing setter method names boolean functions (empty_?)

 --
 Jonas Bonér

 twitter: @jboner
 blog:    http://jonasboner.com
 work:  http://scalablesolutions.se
 code:  http://github.com/jboner
 code:  http://akkasource.org
 also:    http://letitcrash.com
--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Viktor Klang
My personal interpretation is sh!t I don't know here or don't care what it
is

On Fri, Oct 23, 2009 at 9:08 AM, Joni Freeman freeman.j...@gmail.comwrote:


 I love it too. While it is used in many different places it always
 means stuff that I do not care to name.

 BTW. high priest of the lambda calculus loves it too :) It has its
 roots in Haskell...


 http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-4-of-13/

 Cheers Joni

 On 23 loka, 09:48, Jonas Bonér jbo...@gmail.com wrote:
  I love the _ operator.
 
  2009/10/22 Timothy Perrett timo...@getintheloop.eu:
 
 
 
 
 
   I think this is a bit of a running joke in the scala comunity right
   now - your right, underscore really does have a number of meanings; I
   think this will be changed in some future Scala release.
 
   Your also forgetting:
 
   import some.package._
 
   Cheers, Tim
 
   On 22 Oct 2009, at 12:57, tiro wrote:
 
   underscore. At least four different uses:
   - it for defining anonymous functions like above
   - default value
   - matching placeholder whose value is ignored
   - use for constructing setter method names boolean functions (empty_?)
 
  --
  Jonas Bonér
 
  twitter: @jboner
  blog:http://jonasboner.com
  work:  http://scalablesolutions.se
  code:  http://github.com/jboner
  code:  http://akkasource.org
  also:http://letitcrash.com
 



-- 
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: A Critique On Lift

2009-10-23 Thread Chris Lewis

I *think* you're referring to a thread I started some time ago:

http://www.nabble.com/functional-newbie,-domain-entities-td22957479.html

It turned out to be a lively discussion. On a related note, Jonas Boner 
  gisted this in August:

http://gist.github.com/173921

It's not full code, but it gives you an idea how an immutable data model 
might be composed and backed with JPA. There are pain points (java 
collections) and unanswered questions here (how will the JPA provider 
initialize such a class), but there's what I feel is a language-level 
issue. In Scala, if you want methods to immutably evolve an objects' 
state, then you must, as Jonas did, write your own setters that yield 
a new instance with the modification. Sounds like boilerplate to me, 
that's another topic.

For the record, I'm not yet fully convinced of the gains in using 
immutability in a domain model. Domain entities represent the state of 
an application, and in many cases that changes frequently and naturally. 
Period. How and why those changes occur are often the result of human 
behavior (twitter, facebook). These behaviors are not functional in the 
mathematical sense (at least, not that we've discovered), and so I'm not 
clear on what we stand to gain in a typical domain model.

Naftoli Gugenheim wrote:
 How hard can automatic save be?
 But how would immutable DAOs work? There was a thread, I think on scala-user, 
 a long time ago discussing it, that pretty much concluded it would be very 
 problematic. David weighed in and said after a long time he concluded that 
 databases represent state.
 
 
 -
 Timothy Perretttimo...@getintheloop.eu wrote:
 
 
 Right, no one likes mutable anything :-)
 
 I kinda wondered why you haven't pushed forward any more with the  
 current record implementation... can one assume that is why - because  
 it didn't feel right?
 
 Some of this stuff is going to be fundamental to how we move forward -  
 id love to perhaps discuss something that would be better than what we  
 have already. Even if its just pie in the sky talk...
 
 Cheers, Tim
 
 On 22 Oct 2009, at 17:22, David Pollak wrote:
 
 I don't like mutable fields.  I don't like manual saving.  Dunno...  
 it's hard to articulate... it just feels wrong in my tummy.  Also, I  
 want to be clear that I think Marius did a great job of cleaning up  
 some of the problems with Mapper when he did Record... my comments  
 are not a negative to him... there's just something unsatisfying  
 about the whole approach.

 Bet that was less than helpful.
 
 
 
 
  
 

--~--~-~--~~~---~--~~
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: Welcome Dirk Louwers to the Lift committers

2009-10-23 Thread Dirk Louwers

Hi all,

Sorry for the late update. Had a few busy weeks business wise.

I am a Dutch self taught software writer. I am running my own company
from home and planning to use lift to make rich web applications.
Meanwhile I work part time as a coder for a healthcare company to pay
the bills. I have mainly focussed on web applications so far. I
started with PHP, then moved to C# (.NET) and am finally looking at
the java side of web applications through scala since recently. I have
done some small open source contributions, like Spring.NET Db4o
(object database) integration.

Like David said, I am indeed planning to integrate Ext 3 Core into
Lift, which is a modest contribution. After that I am planning to
create an Ext Direct stack which will probably be an external module.

Best,

Dirk

On 15 okt, 19:16, Timothy Perrett timo...@getintheloop.eu wrote:
 Welcome to the team dude - care to give some information about
 yourself and background?

 Cheers, Tim

 On Oct 15, 4:46 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:

  Folks,
  Please join me in welcoming Dirk to theLift committers.  Dirk is going to
  integrate Ext.Js (the MIT licensed part of it) into Lift.

  Welcome Dirk and we look forward to your contributions!

  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] Announcing the Lift Announce group/mailing list **IMPORTANT**

2009-10-23 Thread David Pollak
Folks,

After yesterday's issues surrounding the breaking changes in Lift, I've
decided to create a low volume group called Lift Announce.  You can see the
group at http://groups.google.com/group/lift-announce?lnk=gcimh

This group is an announce-only group which means that only the Lift
committers will post to the group.

Lift Announce will contain: announcements of Lift releases and milestone
releases, invitations to comment about release planning (basically, if we're
having a release planning discussion on the main list, we'll announce this
so folks can participate in choosing features for the next release), and
announcements about breaking changes.

I expect than on average, there will be 1 post per week to this list.

If you are using Lift actively, it is very important to subscribe to this
list.  It will be your guide to changes in Lift.

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: A Critique On Lift

2009-10-23 Thread Jeremy Day
All,

the _ name is also used frequently in C++ for template-based lambdas.  At
least it is in many of the Boost libraries.

Jeremy

On Fri, Oct 23, 2009 at 2:37 AM, Viktor Klang viktor.kl...@gmail.comwrote:

 My personal interpretation is sh!t I don't know here or don't care what it
 is


 On Fri, Oct 23, 2009 at 9:08 AM, Joni Freeman freeman.j...@gmail.comwrote:


 I love it too. While it is used in many different places it always
 means stuff that I do not care to name.

 BTW. high priest of the lambda calculus loves it too :) It has its
 roots in Haskell...


 http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-4-of-13/

 Cheers Joni

 On 23 loka, 09:48, Jonas Bonér jbo...@gmail.com wrote:
  I love the _ operator.
 
  2009/10/22 Timothy Perrett timo...@getintheloop.eu:
 
 
 
 
 
   I think this is a bit of a running joke in the scala comunity right
   now - your right, underscore really does have a number of meanings; I
   think this will be changed in some future Scala release.
 
   Your also forgetting:
 
   import some.package._
 
   Cheers, Tim
 
   On 22 Oct 2009, at 12:57, tiro wrote:
 
   underscore. At least four different uses:
   - it for defining anonymous functions like above
   - default value
   - matching placeholder whose value is ignored
   - use for constructing setter method names boolean functions
 (empty_?)
 
  --
  Jonas Bonér
 
  twitter: @jboner
  blog:http://jonasboner.com
  work:  http://scalablesolutions.se
  code:  http://github.com/jboner
  code:  http://akkasource.org
  also:http://letitcrash.com




 --
 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: Welcome Dirk Louwers to the Lift committers

2009-10-23 Thread Michel Klijn

Welkom Dirk,
Je moet de HU ook echt te makkelijk vinden? je zit nu in de tweede?

I'll continue in english ;) . As a fellow Dutchman I couldn't resist
googlening you. I found out that we're going to the same School (HU).
I'm a third year student and doing my internship in the US atm. I'll
be back at the HU in the second semester, we should definitely meet
up!

groeten,

Michel

On Oct 23, 8:39 am, Dirk Louwers dirk.louw...@stormlantern.nl wrote:
 Hi all,

 Sorry for the late update. Had a few busy weeks business wise.

 I am a Dutch self taught software writer. I am running my own company
 from home and planning to use lift to make rich web applications.
 Meanwhile I work part time as a coder for a healthcare company to pay
 the bills. I have mainly focussed on web applications so far. I
 started with PHP, then moved to C# (.NET) and am finally looking at
 the java side of web applications through scala since recently. I have
 done some small open source contributions, like Spring.NET Db4o
 (object database) integration.

 Like David said, I am indeed planning to integrate Ext 3 Core into
 Lift, which is a modest contribution. After that I am planning to
 create an Ext Direct stack which will probably be an external module.

 Best,

 Dirk

 On 15 okt, 19:16, Timothy Perrett timo...@getintheloop.eu wrote:



  Welcome to the team dude - care to give some information about
  yourself and background?

  Cheers, Tim

  On Oct 15, 4:46 pm, David Pollak feeder.of.the.be...@gmail.com
  wrote:

   Folks,
   Please join me in welcoming Dirk to theLift committers.  Dirk is going to
   integrate Ext.Js (the MIT licensed part of it) into Lift.

   Welcome Dirk and we look forward to your contributions!

   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] How to create an rss?

2009-10-23 Thread wibblecp

hi guys,
I'm looking for a way to generate an rss feed with lift, I'm working
on something like this (from lift-book):

object OwnRssFeed extends XMLApiHelper {
  def dispatch: LiftRules.DispatchPF = {
case Req(rss ::   Nil, , GetRequest) = () = showArticles()
case Req(rss :: _ :: Nil, ,  _) = failure _
  }


def failure() : LiftResponse = {
  val ret: Box[NodeSeq] = Full(op id=FAILURE/op)
  NotFoundResponse()
}

def createTag(in: NodeSeq) = {
  println([CreateTag]  + in)
  rss version=2.0
  channel
  titletitle/title
  linkhttp://example.org/link
  descriptionExample.org/description
  languageen-us/language

  generatorLift WebFramework/generator
  {in}
  /channel
  /rss
}


def showArticles(): LiftResponse = {
  val a: Box[NodeSeq] = for(a - Article.find(By
(Article.published, true))) yield {
 a.toXML
  }
  a
}
}

obviously the yield into the definition of showArticles method break
the cycle to the first one.

Could you suggest me what I can do? I am evaluating lift and scala
just in a while.
Thanks for your attention.
w.
--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread bob

i believe that one of the best ways to learn a new programming
language is to read software written in it

when reading Scala code, I rarely say i don't understand how that
works and when I do, there's usually a good explanation of it
somewhere on the web.

usually I find myself asking where is that defined? or what part of
the language is that?

Scala is not like, for example, BASIC, where you can look up FOR, IF/
THEN/ELSE. there's lots of individual and compound punctuation marks
that are very difficult to search for online and in PDFs (try
searching for !).

a lot of scala also relies on syntactic sugar, such as omitted types
(no : T after a val/var/def); the dreaded underbar; operator
overloading; and implicit conversions. you can hate on Java's
verbosity (i know i have), but brevity has its own difficulties.

On Oct 22, 11:44 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 The last use of _, as in empty_?, is not a special scala meaning. As on Java, 
 underscores can be part of an identifier. Scala takes advantage of this to 
 combine letters and symbols in one name. These names, like empty_?, are a 
 Lift convention, as well as ..._! for use-with-care methods. The scala 
 library uses isEmpty. David, is it your original convention?.

 -

 tirotim.romb...@googlemail.com wrote:
  override def validations = validPriority _ :: super.validations

 funny, I had stumbled on exactly the same line of code when beginning.
 Took me more than a day to understand what's going on. Especially
 because when you copied code from the PDF version of the Liftbook/Lift
 getting started guide, it would mess up spaces, so I would keep
 loooking for a _:: operator.
 The Scala guys have really pushed it a bit hard on the use of the
 underscore. At least four different uses:
 - it for defining anonymous functions like above
 - default value
 - matching placeholder whose value is ignored
 - use for constructing setter method names boolean functions (empty_?)
--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Chris Lewis



bob wrote:
 i believe that one of the best ways to learn a new programming
 language is to read software written in it
 
 when reading Scala code, I rarely say i don't understand how that
 works and when I do, there's usually a good explanation of it
 somewhere on the web.
 
 usually I find myself asking where is that defined? or what part of
 the language is that?
 
 Scala is not like, for example, BASIC, where you can look up FOR, IF/
 THEN/ELSE. there's lots of individual and compound punctuation marks
 that are very difficult to search for online and in PDFs (try
 searching for !).


Indeed, but even cursory survey of scala will reveal that scala has no 
operators, only methods. This leads the user to search for docs on type 
of instance on which the punctuated invocation is made. I don't see the 
confusion there. You could of course make an argument on implicits ...

 
 a lot of scala also relies on syntactic sugar, such as omitted types
 (no : T after a val/var/def); the dreaded underbar; operator
 overloading; and implicit conversions. you can hate on Java's
 verbosity (i know i have), but brevity has its own difficulties.
 
 On Oct 22, 11:44 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 The last use of _, as in empty_?, is not a special scala meaning. As on 
 Java, underscores can be part of an identifier. Scala takes advantage of 
 this to combine letters and symbols in one name. These names, like empty_?, 
 are a Lift convention, as well as ..._! for use-with-care methods. The scala 
 library uses isEmpty. David, is it your original convention?.

 -

 tirotim.romb...@googlemail.com wrote:
 override def validations = validPriority _ :: super.validations
 funny, I had stumbled on exactly the same line of code when beginning.
 Took me more than a day to understand what's going on. Especially
 because when you copied code from the PDF version of the Liftbook/Lift
 getting started guide, it would mess up spaces, so I would keep
 loooking for a _:: operator.
 The Scala guys have really pushed it a bit hard on the use of the
 underscore. At least four different uses:
 - it for defining anonymous functions like above
 - default value
 - matching placeholder whose value is ignored
 - use for constructing setter method names boolean functions (empty_?)
  
 

--~--~-~--~~~---~--~~
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] Problem to process a PUT request in a lift API

2009-10-23 Thread GA

Hello guys,

I have created an API to process a PUT request and a GET request. The  
GET works perfectly fine, but with the PUT the XML seems to be lost in  
its way. I have the following code:

  def dispatch: LiftRules.DispatchPF = {
 case Req(api :: person :: userName :: Nil, ,  
GetRequest) =
 () = showPerson(userName)

   case r @ Req(List(api, person), , PutRequest) =
 () = addPerson(r)
 }

In the addPerson method I have the following code:

req.xml match {
 case Full(person{parameters @_*}/person) = {
 for(parameter - parameters){ parameter match {

All the XML parsing

 }
 }

 try {
 person.validate match {
 case Nil =
 person.save
 CreatedResponse(wrapXmlBody 
(operation id=addPerson success=true/operation), text/xml)
 case _ =
 CreatedResponse(wrapXmlBody 
(operation id=addPerson success=false/operation), text/xml)
 }
 }
 catch {
 case e = Log.error(Could not add person,  
e); BadResponse()
 }
 }
 case _ = Log.error(Request was malformed +req.view);  
BadResponse()
 }

The method always goes through the last case: Request was malformed.

I was checking the values to req.view and req.xml.toString and the  
results are person and empty, respectively.

Any ideas about what it could be happening?

Thanks in advance,

GA


--~--~-~--~~~---~--~~
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: catch a URL

2009-10-23 Thread Chris Lewis

Thanks for that link, however it doesn't seem like rewrite rules fire 
for paths that are mapped in the SiteMap. Can anyone confirm that? I 
could have the redirect point to a non-existing URL, and do logic + 
rewrite there. I'm curious though, are rewrites considered if the URL 
matches a page in the SiteMap?

Jeppe Nejsum Madsen wrote:
 Chris Lewis burningodzi...@gmail.com writes:
 
 Hi list,

 I'm working on an appengine app, and need to store some user 
 information. I authenticate the user with their google account, and I 
 need to create their local entity only if it's their first time 
 logging in.

 When a user logs in via google, they are redirected back to your app, to 
 a URL of your choosing. My thought was to catch the request as it comes 
 back and, if it's their first time logging in, create a User entity. My 
 question then is how can I do this without:

 a) Using a snippet, called from the return landing page and emitting 
 NodeSeq.Empty - hack.

 b) Using custom dispatch and then redirecting. That may work, but it's 
 an unneeded round trip.

 Any thoughts? Thanks!
 
 Not sure if the landing page is static, has parameters etc and what you
 want to do afterwards. 
 
 Assume you need to render some template and the landing page is not
 static (if it is you could just use a normal Loc) I would probably wrap
 the landing page in a RewriteRequest, and when a match is made, do the
 user creation/lookup thing and then just render the template.
 
 Tim wrote and article about rewriting
 http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework
 
 Also, I've been using the Locs from CRUDify as an example of how to do
 more custom-type Locs with rewriting.
 
 /Jeppe
 
  
 

--~--~-~--~~~---~--~~
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: catch a URL

2009-10-23 Thread Timothy Perrett

Chris,

SiteMap deals with what pages you are saying should be visible. Here,  
I term page as the physical xhtml  file that represents the stuff  
the users sees - its a file on your system.

Rewritten URLs dont need to feature in SiteMap because lift is clever  
enough to know that the page you are rewriting to already has (or has  
not) been allowed access via sitemap.

Sounds like your trying to add rewritten URLs to your sitemap?

Cheers, Tim

PS: Jeppe, thanks for the link recycling!!

On 23 Oct 2009, at 16:43, Chris Lewis wrote:


 Thanks for that link, however it doesn't seem like rewrite rules fire
 for paths that are mapped in the SiteMap. Can anyone confirm that? I
 could have the redirect point to a non-existing URL, and do logic +
 rewrite there. I'm curious though, are rewrites considered if the URL
 matches a page in the SiteMap?

 Jeppe Nejsum Madsen wrote:
 Chris Lewis burningodzi...@gmail.com writes:

 Hi list,

 I'm working on an appengine app, and need to store some user
 information. I authenticate the user with their google account,  
 and I
 need to create their local entity only if it's their first time
 logging in.

 When a user logs in via google, they are redirected back to your  
 app, to
 a URL of your choosing. My thought was to catch the request as it  
 comes
 back and, if it's their first time logging in, create a User  
 entity. My
 question then is how can I do this without:

 a) Using a snippet, called from the return landing page and emitting
 NodeSeq.Empty - hack.

 b) Using custom dispatch and then redirecting. That may work, but  
 it's
 an unneeded round trip.

 Any thoughts? Thanks!

 Not sure if the landing page is static, has parameters etc and what  
 you
 want to do afterwards.

 Assume you need to render some template and the landing page is not
 static (if it is you could just use a normal Loc) I would probably  
 wrap
 the landing page in a RewriteRequest, and when a match is made, do  
 the
 user creation/lookup thing and then just render the template.

 Tim wrote and article about rewriting
 http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework

 Also, I've been using the Locs from CRUDify as an example of how to  
 do
 more custom-type Locs with rewriting.

 /Jeppe




 



--~--~-~--~~~---~--~~
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] Foreign Key Constraints in PostgreSQL through MappedLongForeignKey fields?

2009-10-23 Thread yk

I was running the models of One-To-Many example from WiKi (http://
wiki.github.com/dpp/liftweb/how-to-work-with-one-to-many-
relationships) against PostgreSQL hoping to see a foreign key
constraint on the Book table. I got an index instead.

Is there a way to get schemifier to acknowledge the foreign key
constraints?
--~--~-~--~~~---~--~~
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: catch a URL

2009-10-23 Thread Chris Lewis

Hi Tim,

I don't specifically want to rewrite anything. What I want is to be able 
to run some initialization code when a specific page is requested. As I 
said, I'm writing a google app engine app that uses google's 
authentication service to auth users (using their google account). I'm 
instructing the auth service to returned the authenticated user to their 
home page, a page protected and mapped via SiteMap. However, if it's 
their first time logging in, I need to bootstrap them in my app. 
Rewriting was suggested by Jeppe, and I had thought that way might work. 
It doesn't seem to, b/c Lift doesn't appear to fire the rewriters on 
URLs mapped in SiteMap.

I'm not married to the idea of rewrites to solve this problem, I just 
need a non-snippet way to solve it.

-chris

Timothy Perrett wrote:
 Chris,
 
 SiteMap deals with what pages you are saying should be visible. Here,  
 I term page as the physical xhtml  file that represents the stuff  
 the users sees - its a file on your system.
 
 Rewritten URLs dont need to feature in SiteMap because lift is clever  
 enough to know that the page you are rewriting to already has (or has  
 not) been allowed access via sitemap.
 
 Sounds like your trying to add rewritten URLs to your sitemap?
 
 Cheers, Tim
 
 PS: Jeppe, thanks for the link recycling!!
 
 On 23 Oct 2009, at 16:43, Chris Lewis wrote:
 
 Thanks for that link, however it doesn't seem like rewrite rules fire
 for paths that are mapped in the SiteMap. Can anyone confirm that? I
 could have the redirect point to a non-existing URL, and do logic +
 rewrite there. I'm curious though, are rewrites considered if the URL
 matches a page in the SiteMap?

 Jeppe Nejsum Madsen wrote:
 Chris Lewis burningodzi...@gmail.com writes:

 Hi list,

 I'm working on an appengine app, and need to store some user
 information. I authenticate the user with their google account,  
 and I
 need to create their local entity only if it's their first time
 logging in.

 When a user logs in via google, they are redirected back to your  
 app, to
 a URL of your choosing. My thought was to catch the request as it  
 comes
 back and, if it's their first time logging in, create a User  
 entity. My
 question then is how can I do this without:

 a) Using a snippet, called from the return landing page and emitting
 NodeSeq.Empty - hack.

 b) Using custom dispatch and then redirecting. That may work, but  
 it's
 an unneeded round trip.

 Any thoughts? Thanks!
 Not sure if the landing page is static, has parameters etc and what  
 you
 want to do afterwards.

 Assume you need to render some template and the landing page is not
 static (if it is you could just use a normal Loc) I would probably  
 wrap
 the landing page in a RewriteRequest, and when a match is made, do  
 the
 user creation/lookup thing and then just render the template.

 Tim wrote and article about rewriting
 http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework

 Also, I've been using the Locs from CRUDify as an example of how to  
 do
 more custom-type Locs with rewriting.

 /Jeppe

 
 
  
 

--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Chris Lewis

My head just exploded. Twice.

ngocdaothanh wrote:
 Because Lift's ad is so good.

*boom*

  For example:
 
 Lift is the only new framework in the last four years to offer fresh
 and innovative approaches to web development. It's not just some
 incremental improvements over the status quo, it redefines the state
 of the art. If you are a web developer, you should learn Lift. Even if
 you don't wind up using it everyday, it will change the way you
 approach web applications.
 
 Lift can't be used without Scala. Is there a plan to implement Lift in
 Clojure, for example? :D

*BOOM*

 
 
 On Oct 22, 3:47 pm, TylerWeir tyler.w...@gmail.com wrote:
 On Oct 22, 2:02 am, ngocdaothanh ngocdaoth...@gmail.com wrote:

 jlist9,
 This is a Lift group, but I have to say I feel the same about Scala.
 I had to ask for advice 
 here:http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...
 Scala may help me to get my work done for the day. But I don't feel
 happy with Scala. Scala makes me feel I'm a slave all the day to
 machines (or Scala itself!).
 If it makes you feel like a slave, why are you using Scala at all
 then?



 On Oct 22, 2:13 pm, jlist9 jli...@gmail.com wrote:
 override def validations = validPriority _ :: super.validations
 This is a more of a comment about Scala than one about Lift - this does
 look cryptic to me. And this is just one of the simpler syntax that 
 confuses
 people, who are new to the language. And I'm one of them.
 I understand that you don't have to learn all the tricks/syntax to start
 coding in Scala but you do have to understand it when you read
 source code of libraries written by someone with much more advanced
 language skills.
 In David's book he says After more than two years of coding Scala, ...
 My brain has finally stopped hurting. This sounds like a very high
 barrier to entry.
 I'm just wondering why Scala has to be so complicated. I'm sure a lot
 of things in Scala have their reasons but at the mean time I also
 suspect that many of the odd things are there to reduce
 typing, which is advertised as one of the advantages of this language -
 conciseness. (I could be very wrong due to my lack of understanding.)
 If the latter is true, I feel that I'd rather type a little more to make 
 the
 code easier to read.
 Just feeling a little frustrated learning Scala. I think it's much
 easier learning
 Java. Not much surprise. Not sure if anyone shares my experience
 (and opinion, if there is one.)
 On Wed, Oct 21, 2009 at 3:56 PM, Randinn rand...@gmail.com wrote:
 http://localhost3000.de/2009/10/a-quick-glance-at-lift/
 The site above is a blog post from a Rails developer, he had some good
 and bad things to say about Lift and since I do not know enough to
 debate with him I thought I'd post it here.
 
  
 

--~--~-~--~~~---~--~~
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: catch a URL

2009-10-23 Thread Timothy Perrett

Ah. In that case, does this help:

 Menu(Loc(Some, List(some,page), Some,
   EarlyResponse(() = {
// do some response here,
 // return Empty if you dont want
 // a response but a filter style
 // intercept.
 Empty
   })
 ))

Does that help?

Cheers, Tim

On 23 Oct 2009, at 17:07, Chris Lewis wrote:


 Hi Tim,

 I don't specifically want to rewrite anything. What I want is to be  
 able
 to run some initialization code when a specific page is requested.  
 As I
 said, I'm writing a google app engine app that uses google's
 authentication service to auth users (using their google account). I'm
 instructing the auth service to returned the authenticated user to  
 their
 home page, a page protected and mapped via SiteMap. However, if it's
 their first time logging in, I need to bootstrap them in my app.
 Rewriting was suggested by Jeppe, and I had thought that way might  
 work.
 It doesn't seem to, b/c Lift doesn't appear to fire the rewriters on
 URLs mapped in SiteMap.

 I'm not married to the idea of rewrites to solve this problem, I just
 need a non-snippet way to solve it.

 -chris

 Timothy Perrett wrote:
 Chris,

 SiteMap deals with what pages you are saying should be visible. Here,
 I term page as the physical xhtml  file that represents the stuff
 the users sees - its a file on your system.

 Rewritten URLs dont need to feature in SiteMap because lift is clever
 enough to know that the page you are rewriting to already has (or has
 not) been allowed access via sitemap.

 Sounds like your trying to add rewritten URLs to your sitemap?

 Cheers, Tim

 PS: Jeppe, thanks for the link recycling!!

 On 23 Oct 2009, at 16:43, Chris Lewis wrote:

 Thanks for that link, however it doesn't seem like rewrite rules  
 fire
 for paths that are mapped in the SiteMap. Can anyone confirm that? I
 could have the redirect point to a non-existing URL, and do logic +
 rewrite there. I'm curious though, are rewrites considered if the  
 URL
 matches a page in the SiteMap?

 Jeppe Nejsum Madsen wrote:
 Chris Lewis burningodzi...@gmail.com writes:

 Hi list,

 I'm working on an appengine app, and need to store some user
 information. I authenticate the user with their google account,
 and I
 need to create their local entity only if it's their first time
 logging in.

 When a user logs in via google, they are redirected back to your
 app, to
 a URL of your choosing. My thought was to catch the request as it
 comes
 back and, if it's their first time logging in, create a User
 entity. My
 question then is how can I do this without:

 a) Using a snippet, called from the return landing page and  
 emitting
 NodeSeq.Empty - hack.

 b) Using custom dispatch and then redirecting. That may work, but
 it's
 an unneeded round trip.

 Any thoughts? Thanks!
 Not sure if the landing page is static, has parameters etc and what
 you
 want to do afterwards.

 Assume you need to render some template and the landing page is not
 static (if it is you could just use a normal Loc) I would probably
 wrap
 the landing page in a RewriteRequest, and when a match is made, do
 the
 user creation/lookup thing and then just render the template.

 Tim wrote and article about rewriting
 http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework

 Also, I've been using the Locs from CRUDify as an example of how to
 do
 more custom-type Locs with rewriting.

 /Jeppe






 



--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Jim Barrows
On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis burningodzi...@gmail.comwrote:


 My head just exploded. Twice.


That explains the wet face this morning when I woke up... thought it was the
dog licking it... :)



 ngocdaothanh wrote:
  Because Lift's ad is so good.

 *boom*


It was good.  My first thought was Yeah
rIGHT!  Let's see what they mean.
And voila... here I am.. so it was good, if only because it was right :)



  For example:
 
  Lift is the only new framework in the last four years to offer fresh
  and innovative approaches to web development. It's not just some
  incremental improvements over the status quo, it redefines the state
  of the art. If you are a web developer, you should learn Lift. Even if
  you don't wind up using it everyday, it will change the way you
  approach web applications.
 
  Lift can't be used without Scala. Is there a plan to implement Lift in
  Clojure, for example? :D

 *BOOM*


Ummm.. ok.. This one I understand.



 
 
  On Oct 22, 3:47 pm, TylerWeir tyler.w...@gmail.com wrote:
  On Oct 22, 2:02 am, ngocdaothanh ngocdaoth...@gmail.com wrote:
 
  jlist9,
  This is a Lift group, but I have to say I feel the same about Scala.
  I had to ask for advice here:
 http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...
  Scala may help me to get my work done for the day. But I don't feel
  happy with Scala. Scala makes me feel I'm a slave all the day to
  machines (or Scala itself!).
  If it makes you feel like a slave, why are you using Scala at all
  then?
 
 
 
  On Oct 22, 2:13 pm, jlist9 jli...@gmail.com wrote:
  override def validations = validPriority _ :: super.validations
  This is a more of a comment about Scala than one about Lift - this
 does
  look cryptic to me. And this is just one of the simpler syntax that
 confuses
  people, who are new to the language. And I'm one of them.
  I understand that you don't have to learn all the tricks/syntax to
 start
  coding in Scala but you do have to understand it when you read
  source code of libraries written by someone with much more advanced
  language skills.
  In David's book he says After more than two years of coding Scala,
 ...
  My brain has finally stopped hurting. This sounds like a very high
  barrier to entry.
  I'm just wondering why Scala has to be so complicated. I'm sure a lot
  of things in Scala have their reasons but at the mean time I also
  suspect that many of the odd things are there to reduce
  typing, which is advertised as one of the advantages of this language
 -
  conciseness. (I could be very wrong due to my lack of understanding.)
  If the latter is true, I feel that I'd rather type a little more to
 make the
  code easier to read.
  Just feeling a little frustrated learning Scala. I think it's much
  easier learning
  Java. Not much surprise. Not sure if anyone shares my experience
  (and opinion, if there is one.)
  On Wed, Oct 21, 2009 at 3:56 PM, Randinn rand...@gmail.com wrote:
  http://localhost3000.de/2009/10/a-quick-glance-at-lift/
  The site above is a blog post from a Rails developer, he had some
 good
  and bad things to say about Lift and since I do not know enough to
  debate with him I thought I'd post it here.
 
  
 

 



-- 
James A Barrows

--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 9:29 AM, Jim Barrows jim.barr...@gmail.com wrote:


 On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis burningodzi...@gmail.comwrote:


 My head just exploded. Twice.


 That explains the wet face this morning when I woke up... thought it was
 the dog licking it... :)



 ngocdaothanh wrote:
  Because Lift's ad is so good.

 *boom*


 It was good.  My first thought was Yeah
 rIGHT!  Let's see what they mean.
 And voila... here I am.. so it was good, if only because it was right :)



  For example:
 
  Lift is the only new framework in the last four years to offer fresh
  and innovative approaches to web development. It's not just some
  incremental improvements over the status quo, it redefines the state
  of the art. If you are a web developer, you should learn Lift. Even if
  you don't wind up using it everyday, it will change the way you
  approach web applications.
 
  Lift can't be used without Scala. Is there a plan to implement Lift in
  Clojure, for example? :D


I've thought about it and even done some initial poking around with
Clojure.  It could be done, but I really like static typing so don't want to
spend a lot of time in Clojure's unityped land.



 *BOOM*


 Ummm.. ok.. This one I understand.



 
 
  On Oct 22, 3:47 pm, TylerWeir tyler.w...@gmail.com wrote:
  On Oct 22, 2:02 am, ngocdaothanh ngocdaoth...@gmail.com wrote:
 
  jlist9,
  This is a Lift group, but I have to say I feel the same about Scala.
  I had to ask for advice here:
 http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...
  Scala may help me to get my work done for the day. But I don't feel
  happy with Scala. Scala makes me feel I'm a slave all the day to
  machines (or Scala itself!).
  If it makes you feel like a slave, why are you using Scala at all
  then?
 
 
 
  On Oct 22, 2:13 pm, jlist9 jli...@gmail.com wrote:
  override def validations = validPriority _ :: super.validations
  This is a more of a comment about Scala than one about Lift - this
 does
  look cryptic to me. And this is just one of the simpler syntax that
 confuses
  people, who are new to the language. And I'm one of them.
  I understand that you don't have to learn all the tricks/syntax to
 start
  coding in Scala but you do have to understand it when you read
  source code of libraries written by someone with much more advanced
  language skills.
  In David's book he says After more than two years of coding Scala,
 ...
  My brain has finally stopped hurting. This sounds like a very high
  barrier to entry.
  I'm just wondering why Scala has to be so complicated. I'm sure a lot
  of things in Scala have their reasons but at the mean time I also
  suspect that many of the odd things are there to reduce
  typing, which is advertised as one of the advantages of this language
 -
  conciseness. (I could be very wrong due to my lack of understanding.)
  If the latter is true, I feel that I'd rather type a little more to
 make the
  code easier to read.
  Just feeling a little frustrated learning Scala. I think it's much
  easier learning
  Java. Not much surprise. Not sure if anyone shares my experience
  (and opinion, if there is one.)
  On Wed, Oct 21, 2009 at 3:56 PM, Randinn rand...@gmail.com wrote:
  http://localhost3000.de/2009/10/a-quick-glance-at-lift/
  The site above is a blog post from a Rails developer, he had some
 good
  and bad things to say about Lift and since I do not know enough to
  debate with him I thought I'd post it here.
 
  
 





 --
 James A Barrows



 



-- 
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: How to create an rss?

2009-10-23 Thread glenn

I don't know if this will help, but I use a simple createTag to just
enclose the full xml so it has a root element:

   def createTag(in: NodeSeq) = {
   apbul_apii{in}/apbul_api

  }

and then showArticles would call into a feed wrapper, passing in the
result of yield,  like this for an Atom feed:

//Reacts to Get all reguest
   def showArticles():AtomResponse = {
 val eList = for(e - Content.findAll) yield {
e.toAtom
  }

 AtomResponse(feedWrapper(eList))

   }

Glenn


On Oct 23, 6:24 am, wibblecp wibbl...@gmail.com wrote:
 hi guys,
 I'm looking for a way to generate an rss feed with lift, I'm working
 on something like this (from lift-book):

 object OwnRssFeed extends XMLApiHelper {
   def dispatch: LiftRules.DispatchPF = {
     case Req(rss ::   Nil, , GetRequest) = () = showArticles()
     case Req(rss :: _ :: Nil, ,  _) = failure _
   }

     def failure() : LiftResponse = {
       val ret: Box[NodeSeq] = Full(op id=FAILURE/op)
       NotFoundResponse()
     }

     def createTag(in: NodeSeq) = {
       println([CreateTag]  + in)
       rss version=2.0
           channel
               titletitle/title
               linkhttp://example.org/link
               descriptionExample.org/description
               languageen-us/language

               generatorLift WebFramework/generator
                   {in}
           /channel
       /rss
     }

     def showArticles(): LiftResponse = {
       val a: Box[NodeSeq] = for(a - Article.find(By
 (Article.published, true))) yield {
          a.toXML
       }
       a
     }

 }

 obviously the yield into the definition of showArticles method break
 the cycle to the first one.

 Could you suggest me what I can do? I am evaluating lift and scala
 just in a while.
 Thanks for your attention.
 w.
--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread jlist9

It's often hard to describe some (I'd say most) of the Scala syntax
if you want to search for an answer online.

It would be great if the eclipse plugin can tell you what the code is
trying to do and what kind of syntax is that, for example, linking
an operator back to a method name.

On Fri, Oct 23, 2009 at 6:27 AM, bob rbpas...@gmail.com wrote:

 i believe that one of the best ways to learn a new programming
 language is to read software written in it

 when reading Scala code, I rarely say i don't understand how that
 works and when I do, there's usually a good explanation of it
 somewhere on the web.

 usually I find myself asking where is that defined? or what part of
 the language is that?

 Scala is not like, for example, BASIC, where you can look up FOR, IF/
 THEN/ELSE. there's lots of individual and compound punctuation marks
 that are very difficult to search for online and in PDFs (try
 searching for !).

 a lot of scala also relies on syntactic sugar, such as omitted types
 (no : T after a val/var/def); the dreaded underbar; operator
 overloading; and implicit conversions. you can hate on Java's
 verbosity (i know i have), but brevity has its own difficulties.

 On Oct 22, 11:44 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 The last use of _, as in empty_?, is not a special scala meaning. As on 
 Java, underscores can be part of an identifier. Scala takes advantage of 
 this to combine letters and symbols in one name. These names, like empty_?, 
 are a Lift convention, as well as ..._! for use-with-care methods. The scala 
 library uses isEmpty. David, is it your original convention?.

 -

 tirotim.romb...@googlemail.com wrote:
  override def validations = validPriority _ :: super.validations

 funny, I had stumbled on exactly the same line of code when beginning.
 Took me more than a day to understand what's going on. Especially
 because when you copied code from the PDF version of the Liftbook/Lift
 getting started guide, it would mess up spaces, so I would keep
 loooking for a _:: operator.
 The Scala guys have really pushed it a bit hard on the use of the
 underscore. At least four different uses:
 - it for defining anonymous functions like above
 - default value
 - matching placeholder whose value is ignored
 - use for constructing setter method names boolean functions (empty_?)
 


--~--~-~--~~~---~--~~
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: Problem to process a PUT request in a lift API

2009-10-23 Thread GA

I have printed Req in the log and it looks like the XML is really empty:

Req(List(), Map(), ParsePath(List(api, person),,true,false), ,  
PutRequest, Empty)

This is how I send the XML:

def post(url:URL):String = {

 val message =
 person
 userNameJohn/userName
 firstNameJohn/firstName
 lastNameSmith/lastName
 passworda/password
 emaila...@.com/email
 createdon10/12/2009/createdon
 createdbyJohn/createdby
 updatedon10/12/2009/updatedon
 updatedbyJohn/updatedby
 /person

 url.openConnection match { case conn: HttpURLConnection = {
 conn.setRequestMethod(PUT)
 conn.setDoOutput(true)
 //conn.connect
 conn.getOutputStream.write 
(message.mkString.getBytes)
 scala.io.Source.fromInputStream 
(conn.getInputStream).getLines.mkString
 }
}
}

Any suggestions?

Cheers,

GA




On Oct 23, 2009, at 5:15 PM, GA wrote:


 Hello guys,

 I have created an API to process a PUT request and a GET request. The
 GET works perfectly fine, but with the PUT the XML seems to be lost in
 its way. I have the following code:

  def dispatch: LiftRules.DispatchPF = {
 case Req(api :: person :: userName :: Nil, ,
 GetRequest) =
 () = showPerson(userName)

   case r @ Req(List(api, person), , PutRequest) =
 () = addPerson(r)
 }

 In the addPerson method I have the following code:

 req.xml match {
 case Full(person{parameters @_*}/person) = {
 for(parameter - parameters){ parameter match {

   All the XML parsing

 }
 }

 try {
 person.validate match {
 case Nil =
 person.save
 CreatedResponse(wrapXmlBody
 (operation id=addPerson success=true/operation), text/xml)
 case _ =
 CreatedResponse(wrapXmlBody
 (operation id=addPerson success=false/operation), text/xml)
 }
 }
 catch {
 case e = Log.error(Could not add person,
 e); BadResponse()
 }
 }
 case _ = Log.error(Request was malformed +req.view);
 BadResponse()
 }

 The method always goes through the last case: Request was malformed.

 I was checking the values to req.view and req.xml.toString and the
 results are person and empty, respectively.

 Any ideas about what it could be happening?

 Thanks in advance,

 GA


 


--~--~-~--~~~---~--~~
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: Problem to process a PUT request in a lift API

2009-10-23 Thread David Pollak
In order to trigger XML parsing, you have to set the Content-Type to
text/xml

On Fri, Oct 23, 2009 at 10:30 AM, GA my_li...@me.com wrote:


 I have printed Req in the log and it looks like the XML is really empty:

 Req(List(), Map(), ParsePath(List(api, person),,true,false), ,
 PutRequest, Empty)

 This is how I send the XML:

 def post(url:URL):String = {

 val message =
 person
 userNameJohn/userName
 firstNameJohn/firstName
 lastNameSmith/lastName
 passworda/password
 emaila...@.com/email
 createdon10/12/2009/createdon
 createdbyJohn/createdby
 updatedon10/12/2009/updatedon
 updatedbyJohn/updatedby
 /person

 url.openConnection match { case conn: HttpURLConnection = {
 conn.setRequestMethod(PUT)
 conn.setDoOutput(true)
 //conn.connect
 conn.getOutputStream.write
 (message.mkString.getBytes)
 scala.io.Source.fromInputStream
 (conn.getInputStream).getLines.mkString
 }
 }
 }

 Any suggestions?

 Cheers,

 GA




 On Oct 23, 2009, at 5:15 PM, GA wrote:

 
  Hello guys,
 
  I have created an API to process a PUT request and a GET request. The
  GET works perfectly fine, but with the PUT the XML seems to be lost in
  its way. I have the following code:
 
   def dispatch: LiftRules.DispatchPF = {
  case Req(api :: person :: userName :: Nil, ,
  GetRequest) =
  () = showPerson(userName)
 
case r @ Req(List(api, person), , PutRequest) =
  () = addPerson(r)
  }
 
  In the addPerson method I have the following code:
 
  req.xml match {
  case Full(person{parameters @_*}/person) = {
  for(parameter - parameters){ parameter match {
 
All the XML parsing
 
  }
  }
 
  try {
  person.validate match {
  case Nil =
  person.save
  CreatedResponse(wrapXmlBody
  (operation id=addPerson success=true/operation), text/xml)
  case _ =
  CreatedResponse(wrapXmlBody
  (operation id=addPerson success=false/operation), text/xml)
  }
  }
  catch {
  case e = Log.error(Could not add person,
  e); BadResponse()
  }
  }
  case _ = Log.error(Request was malformed +req.view);
  BadResponse()
  }
 
  The method always goes through the last case: Request was malformed.
 
  I was checking the values to req.view and req.xml.toString and the
  results are person and empty, respectively.
 
  Any ideas about what it could be happening?
 
  Thanks in advance,
 
  GA
 
 
  


 



-- 
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: A Critique On Lift

2009-10-23 Thread Chris Lewis



jlist9 wrote:
 It's often hard to describe some (I'd say most) of the Scala syntax
 if you want to search for an answer online.

I can't relate with that. I've been coding scala for 3-4 months, and 
I've never had any problem finding method definitions. Most of this 
probably had to do with that fact that I was reading through several 
language overviews and tutorials.

 It would be great if the eclipse plugin can tell you what the code is
 trying to do and what kind of syntax is that, for example, linking
 an operator back to a method name.

I'll repeat: there are no operators in scala. Not a single one. linking 
an operator back to a method name doesn't make sense. Accept that 
_everything_ in scala, except methods, is an object, and as such adheres 
to its respective class contract. If you need to look up the meaning of 
an operator, all you need to know is the type on which it is being 
invoked. The only real complexity in this resolution then is introduced 
by implicits.

 
 On Fri, Oct 23, 2009 at 6:27 AM, bob rbpas...@gmail.com wrote:
 i believe that one of the best ways to learn a new programming
 language is to read software written in it

 when reading Scala code, I rarely say i don't understand how that
 works and when I do, there's usually a good explanation of it
 somewhere on the web.

 usually I find myself asking where is that defined? or what part of
 the language is that?

 Scala is not like, for example, BASIC, where you can look up FOR, IF/
 THEN/ELSE. there's lots of individual and compound punctuation marks
 that are very difficult to search for online and in PDFs (try
 searching for !).

 a lot of scala also relies on syntactic sugar, such as omitted types
 (no : T after a val/var/def); the dreaded underbar; operator
 overloading; and implicit conversions. you can hate on Java's
 verbosity (i know i have), but brevity has its own difficulties.

 On Oct 22, 11:44 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 The last use of _, as in empty_?, is not a special scala meaning. As on 
 Java, underscores can be part of an identifier. Scala takes advantage of 
 this to combine letters and symbols in one name. These names, like empty_?, 
 are a Lift convention, as well as ..._! for use-with-care methods. The 
 scala library uses isEmpty. David, is it your original convention?.

 -

 tirotim.romb...@googlemail.com wrote:
 override def validations = validPriority _ :: super.validations
 funny, I had stumbled on exactly the same line of code when beginning.
 Took me more than a day to understand what's going on. Especially
 because when you copied code from the PDF version of the Liftbook/Lift
 getting started guide, it would mess up spaces, so I would keep
 loooking for a _:: operator.
 The Scala guys have really pushed it a bit hard on the use of the
 underscore. At least four different uses:
 - it for defining anonymous functions like above
 - default value
 - matching placeholder whose value is ignored
 - use for constructing setter method names boolean functions (empty_?)

 
  
 

--~--~-~--~~~---~--~~
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: Testing for SQL Server drivers

2009-10-23 Thread Naftoli Gugenheim
Don't you have a Windows machine that you can install SQL Server Express on?

On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 Hi,
 I've made some changes to Mapper to better support SQL Server,
 particularly with Unicode text. Does anyone out there use SQL Server that
 would be willing to test the code on the wip-dcb-issue-16-sql-server branch
 to make sure nothing breaks?

 Thanks,

 Derek

 


--~--~-~--~~~---~--~~
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: catch a URL

2009-10-23 Thread Jeppe Nejsum Madsen

Timothy Perrett timo...@getintheloop.eu writes:

 Ah. In that case, does this help:

  Menu(Loc(Some, List(some,page), Some,
EarlyResponse(() = {
   // do some response here,
  // return Empty if you dont want
  // a response but a filter style
  // intercept.
  Empty
})
  ))

 Does that help?

Or, if you just need to run some code before a template is rendered:

Menu(Loc(test, List(landing), test, Template{() = 
 println(Hit the template URL);
 // Handle Empty case :-)
 
TemplateFinder.findAnyTemplate(List(mytemplat,index)).open_!
   }))

/Jeppe

--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread bob

I'll repeat: there are no operators in scala

s/operators/methods-with-operator-like-names/

anywhere, here's a typical case:

import some.library.package.foo._

val a = bar 42
val b = a ~!~ 3.14159

you can't easily tell that bar is being imported via foo._ .
what is bar's return type?
what does ~!~ do?

i'm not saying its not possible to track all this down, but you can't
just print out a listing of a class and take it on the subway. you
have to have access to the scaladocs and possibly even the sources.

--b



--~--~-~--~~~---~--~~
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: Testing for SQL Server drivers

2009-10-23 Thread Derek Chen-Becker
I have one virtual Win2K instance for some legacy software, but looking at
the requirements that doesn't seem to be supported.

On Fri, Oct 23, 2009 at 1:10 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:

 Don't you have a Windows machine that you can install SQL Server Express
 on?


 On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 Hi,
 I've made some changes to Mapper to better support SQL Server,
 particularly with Unicode text. Does anyone out there use SQL Server that
 would be willing to test the code on the wip-dcb-issue-16-sql-server branch
 to make sure nothing breaks?

 Thanks,

 Derek




 


--~--~-~--~~~---~--~~
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: Announcing the Lift Announce group/mailing list **IMPORTANT**

2009-10-23 Thread Naftoli Gugenheim
Will non-committers be able to reply on a thread?

On Fri, Oct 23, 2009 at 9:07 AM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 Folks,

 After yesterday's issues surrounding the breaking changes in Lift, I've
 decided to create a low volume group called Lift Announce.  You can see the
 group at http://groups.google.com/group/lift-announce?lnk=gcimh

 This group is an announce-only group which means that only the Lift
 committers will post to the group.

 Lift Announce will contain: announcements of Lift releases and milestone
 releases, invitations to comment about release planning (basically, if we're
 having a release planning discussion on the main list, we'll announce this
 so folks can participate in choosing features for the next release), and
 announcements about breaking changes.

 I expect than on average, there will be 1 post per week to this list.

 If you are using Lift actively, it is very important to subscribe to this
 list.  It will be your guide to changes in Lift.

 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: Testing for SQL Server drivers

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 12:10 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:

 Don't you have a Windows machine that you can install SQL Server Express
 on?


Even if Derek does have such a machine, he's been doing an awful lot of work
on Lift.  Recruiting people from the community to help is encouraged.




 On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 Hi,
 I've made some changes to Mapper to better support SQL Server,
 particularly with Unicode text. Does anyone out there use SQL Server that
 would be willing to test the code on the wip-dcb-issue-16-sql-server branch
 to make sure nothing breaks?

 Thanks,

 Derek




 



-- 
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: Announcing the Lift Announce group/mailing list **IMPORTANT**

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 1:04 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:

 Will non-committers be able to reply on a thread?


We'll cross-post to the Lift list.  People can discuss on that list.

The point of the announce list is so that people who don't have the
bandwidth to track the Lift list can still get heads up about important
stuff.




 On Fri, Oct 23, 2009 at 9:07 AM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 Folks,

 After yesterday's issues surrounding the breaking changes in Lift, I've
 decided to create a low volume group called Lift Announce.  You can see the
 group at http://groups.google.com/group/lift-announce?lnk=gcimh

 This group is an announce-only group which means that only the Lift
 committers will post to the group.

 Lift Announce will contain: announcements of Lift releases and milestone
 releases, invitations to comment about release planning (basically, if we're
 having a release planning discussion on the main list, we'll announce this
 so folks can participate in choosing features for the next release), and
 announcements about breaking changes.

 I expect than on average, there will be 1 post per week to this list.

 If you are using Lift actively, it is very important to subscribe to this
 list.  It will be your guide to changes in Lift.

 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: Testing for SQL Server drivers

2009-10-23 Thread Naftoli Gugenheim
100%. Just curious. :)

On Fri, Oct 23, 2009 at 4:05 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 On Fri, Oct 23, 2009 at 12:10 PM, Naftoli Gugenheim 
 naftoli...@gmail.comwrote:

 Don't you have a Windows machine that you can install SQL Server Express
 on?


 Even if Derek does have such a machine, he's been doing an awful lot of
 work on Lift.  Recruiting people from the community to help is encouraged.




 On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 Hi,
 I've made some changes to Mapper to better support SQL Server,
 particularly with Unicode text. Does anyone out there use SQL Server that
 would be willing to test the code on the wip-dcb-issue-16-sql-server branch
 to make sure nothing breaks?

 Thanks,

 Derek








 --
 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: Testing for SQL Server drivers

2009-10-23 Thread Derek Chen-Becker
I'm pretty much 100% linux at home. I can test any other database (Oracle,
MySQL, PostgreSQL, etc), but SQL Server is the exception :)

On Fri, Oct 23, 2009 at 2:14 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:

 100%. Just curious. :)


 On Fri, Oct 23, 2009 at 4:05 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 12:10 PM, Naftoli Gugenheim naftoli...@gmail.com
  wrote:

 Don't you have a Windows machine that you can install SQL Server Express
 on?


 Even if Derek does have such a machine, he's been doing an awful lot of
 work on Lift.  Recruiting people from the community to help is encouraged.




 On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 Hi,
 I've made some changes to Mapper to better support SQL Server,
 particularly with Unicode text. Does anyone out there use SQL Server that
 would be willing to test the code on the wip-dcb-issue-16-sql-server branch
 to make sure nothing breaks?

 Thanks,

 Derek








 --
 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: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread David Pollak
On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 It sounds like you're pretty set against making separate impl traits and
 would prefer just putting things directly on TimeHelper. I'm OK with that,
 but I would really like to add a lift-joda module that contains the
 JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to
 use them. I should be able to delegate a good chunk of the methods to
 TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
 reasonable compromise?


Yes, as long as import Helpers._ is not incompatible with importing whatever
trait you come up with.



 Derek


 On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 I agree that the goal isn't to remove java.util.Date. For trivial time
 handling it works just fine. What I'm trying to achieve here is a way to
 make Joda Time be the default impl while leaving the user a choice. By using
 separate traits instead of different names on the same trait, we achieve a
 few things:

1. A consistent API for both java.util and Joda Time in terms of
method names. As Naftoli pointed out, people expect naming of functions
consistent with what they do and having two different nows on the same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that utilizes
Joda Time directly into TimeHelpers then it's not an optional dependency.
Making a separate trait means that if someone doesn't use the Joda Time
trait then they don't need to have the Joda Time jar in their classpath 
 and
they never know that it's not there.
3. A relatively simple code change path to move from java.util to Joda
Time by simply changing imports.

 Your assertion that Date is a simple wrapper for a Long timestamp is
 pretty accurate, but really Joda Time's DateTime is a superset of
 *Calendar*, not Date. Just look at what we had to do with CalendarExtension
 to get some simple date manipulation functions, where those same methods are
 already defined on DateTime. The vast majority of Joda Time's classes are
 immutable, and the mutators return new instances instead of modifying the
 current instance. TimeSpan's current handling of duration addition doesn't
 cope with DST, which I'm sure will show up as a bug in someone's code if it
 hasn't already. Having done a fair amount of java.util.Date handling and
 then moving to Joda Time, I find it hard to call the difference between the
 two APIs marginal. In any case, I still feel that my proposal makes Joda
 Time available in a nicer way while leaving existing code completely
 untouched (by introducing a JodaHelpers trait that mirrors Helpers).

 Derek


 On Tue, Oct 20, 2009 at 9:25 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim naftoli...@gmail.com
  wrote:


 I agree with this.
 My understanding is that the goal is that Lift should use Joda for its
 time functions rather than java.util.


 This is not the goal.  The goal is to make JodeTime available.  There is
 no reason to remove support for java.util.Date.  None.

 JodaTime offers some advantages, but there's no reason, none, nada, to
 *remove* support for java.util.Date.

 I'm cool with different names (not jtNow, but choose something else).

 But I view removal of support for java.util.Date as gratuitous.  Sure, if
 we were to make the clean-slate decision today, I'd opt for primary support
 of JodaTime and secondary support for java.util.Date.  But we're making a
 decision based on legacy.  We're not going to cut off java.util.Date just
 because something marginally better (and I'm not being facetious here... at
 the bottom, these are just wrappers for number of milliseconds since Jan 1,
 1970).


 If the Joda methods have different and longer names, then it's existing
 side by side with the java.util implementation, not replacing it.
 To many people, it is important that methods etc. should be named
 properly and aesthetically. It's not pleasant to use names like jtNow in
 your code when that is the method that gets used normally. Sure, if 'now'
 was the usual method and a 'jtNow' method was called in special
 circumstances, it's an understandable name. But names that are used in
 ordinary circumstances should have straightforward names.
 (Names should be concise expressions of what they represent. This aids
 in memorization and code readability.)
 Also, it will be impossible to deprecate the java.util implementation
 and have a clean API instead. If we use separate traits with the same 
 method
 names, then we will be able to.


 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 On Tue, Oct 20, 2009 at 4:59 PM, David Pollak 
 feeder.of.the.be...@gmail.com
  wrote:

  What I checked in allows you to use JodaTime just as easily (well with
 2
  extra characters in a few method 

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread Derek Chen-Becker
Well, I had intended to write a JodaHelpers trait that is the same as
Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
TimeHelpers and TimeFormats, respectively. The main reason is that I would
like to have the time DSL be based on Periods instead of millisecond
durations, and with TimeHelpers already in scope there would be ambiguous
implicit conversions from Long/Int to TimeSpan or Period. Supposedly, 2.8
will have some support for masking or overriding implicits, but I don't want
to rely on that in the short term. If a JodaHelpers trait that would replace
a Helpers import isn't OK then I can just do this in my own repo.

Thanks,

Derek

On Fri, Oct 23, 2009 at 2:52 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 It sounds like you're pretty set against making separate impl traits and
 would prefer just putting things directly on TimeHelper. I'm OK with that,
 but I would really like to add a lift-joda module that contains the
 JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to
 use them. I should be able to delegate a good chunk of the methods to
 TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
 reasonable compromise?


 Yes, as long as import Helpers._ is not incompatible with importing
 whatever trait you come up with.



 Derek


 On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I agree that the goal isn't to remove java.util.Date. For trivial time
 handling it works just fine. What I'm trying to achieve here is a way to
 make Joda Time be the default impl while leaving the user a choice. By using
 separate traits instead of different names on the same trait, we achieve a
 few things:

1. A consistent API for both java.util and Joda Time in terms of
method names. As Naftoli pointed out, people expect naming of functions
consistent with what they do and having two different nows on the same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that
utilizes Joda Time directly into TimeHelpers then it's not an optional
dependency. Making a separate trait means that if someone doesn't use the
Joda Time trait then they don't need to have the Joda Time jar in their
classpath and they never know that it's not there.
3. A relatively simple code change path to move from java.util to
Joda Time by simply changing imports.

 Your assertion that Date is a simple wrapper for a Long timestamp is
 pretty accurate, but really Joda Time's DateTime is a superset of
 *Calendar*, not Date. Just look at what we had to do with CalendarExtension
 to get some simple date manipulation functions, where those same methods are
 already defined on DateTime. The vast majority of Joda Time's classes are
 immutable, and the mutators return new instances instead of modifying the
 current instance. TimeSpan's current handling of duration addition doesn't
 cope with DST, which I'm sure will show up as a bug in someone's code if it
 hasn't already. Having done a fair amount of java.util.Date handling and
 then moving to Joda Time, I find it hard to call the difference between the
 two APIs marginal. In any case, I still feel that my proposal makes Joda
 Time available in a nicer way while leaving existing code completely
 untouched (by introducing a JodaHelpers trait that mirrors Helpers).

 Derek


 On Tue, Oct 20, 2009 at 9:25 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim 
 naftoli...@gmail.com wrote:


 I agree with this.
 My understanding is that the goal is that Lift should use Joda for its
 time functions rather than java.util.


 This is not the goal.  The goal is to make JodeTime available.  There is
 no reason to remove support for java.util.Date.  None.

 JodaTime offers some advantages, but there's no reason, none, nada, to
 *remove* support for java.util.Date.

 I'm cool with different names (not jtNow, but choose something else).

 But I view removal of support for java.util.Date as gratuitous.  Sure,
 if we were to make the clean-slate decision today, I'd opt for primary
 support of JodaTime and secondary support for java.util.Date.  But we're
 making a decision based on legacy.  We're not going to cut off
 java.util.Date just because something marginally better (and I'm not
 being facetious here... at the bottom, these are just wrappers for number 
 of
 milliseconds since Jan 1, 1970).


 If the Joda methods have different and longer names, then it's existing
 side by side with the java.util implementation, not replacing it.
 To many people, it is important that methods etc. should be named
 properly and aesthetically. It's not pleasant to use names like jtNow in
 your code when that is the method that gets used normally. Sure, if 'now'
 was the usual method 

[Lift] unnecessary COMMITs?

2009-10-23 Thread harryh

Seeing a great many of these on my postgresql logs:

2009-10-23 21:35:02 UTC WARNING:  there is no transaction in progress
2009-10-23 21:35:02 UTC STATEMENT:  COMMIT

Any idea what might be causing this?  I can filter them out but

a) that would be a little annoying
b) vaguely worried that something non ideal is going on here

-harryh
--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 Well, I had intended to write a JodaHelpers trait that is the same as
 Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
 TimeHelpers and TimeFormats, respectively. The main reason is that I would
 like to have the time DSL be based on Periods instead of millisecond
 durations, and with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


What is the advantage of using Period internally instead of milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding implicits,
 but I don't want to rely on that in the short term. If a JodaHelpers trait
 that would replace a Helpers import isn't OK then I can just do this in my
 own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 It sounds like you're pretty set against making separate impl traits and
 would prefer just putting things directly on TimeHelper. I'm OK with that,
 but I would really like to add a lift-joda module that contains the
 JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to
 use them. I should be able to delegate a good chunk of the methods to
 TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
 reasonable compromise?


 Yes, as long as import Helpers._ is not incompatible with importing
 whatever trait you come up with.



 Derek


 On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I agree that the goal isn't to remove java.util.Date. For trivial time
 handling it works just fine. What I'm trying to achieve here is a way to
 make Joda Time be the default impl while leaving the user a choice. By 
 using
 separate traits instead of different names on the same trait, we achieve a
 few things:

1. A consistent API for both java.util and Joda Time in terms of
method names. As Naftoli pointed out, people expect naming of functions
consistent with what they do and having two different nows on the same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that
utilizes Joda Time directly into TimeHelpers then it's not an optional
dependency. Making a separate trait means that if someone doesn't use 
 the
Joda Time trait then they don't need to have the Joda Time jar in their
classpath and they never know that it's not there.
3. A relatively simple code change path to move from java.util to
Joda Time by simply changing imports.

 Your assertion that Date is a simple wrapper for a Long timestamp is
 pretty accurate, but really Joda Time's DateTime is a superset of
 *Calendar*, not Date. Just look at what we had to do with CalendarExtension
 to get some simple date manipulation functions, where those same methods 
 are
 already defined on DateTime. The vast majority of Joda Time's classes are
 immutable, and the mutators return new instances instead of modifying the
 current instance. TimeSpan's current handling of duration addition doesn't
 cope with DST, which I'm sure will show up as a bug in someone's code if it
 hasn't already. Having done a fair amount of java.util.Date handling and
 then moving to Joda Time, I find it hard to call the difference between the
 two APIs marginal. In any case, I still feel that my proposal makes Joda
 Time available in a nicer way while leaving existing code completely
 untouched (by introducing a JodaHelpers trait that mirrors Helpers).

 Derek


 On Tue, Oct 20, 2009 at 9:25 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim 
 naftoli...@gmail.com wrote:


 I agree with this.
 My understanding is that the goal is that Lift should use Joda for its
 time functions rather than java.util.


 This is not the goal.  The goal is to make JodeTime available.  There
 is no reason to remove support for java.util.Date.  None.

 JodaTime offers some advantages, but there's no reason, none, nada, to
 *remove* support for java.util.Date.

 I'm cool with different names (not jtNow, but choose something else).

 But I view removal of support for java.util.Date as gratuitous.  Sure,
 if we were to make the clean-slate decision today, I'd opt for primary
 support of JodaTime and secondary support for java.util.Date.  But we're
 making a decision based on legacy.  We're not going to cut off
 java.util.Date just because something marginally better (and I'm not
 being facetious here... at the bottom, these are just wrappers for number 
 of
 milliseconds since Jan 1, 1970).


 If the Joda methods have different and longer names, then it's
 existing side by side with the java.util implementation, not replacing 
 it.
 To many people, it is important that methods etc. should 

[Lift] Re: unnecessary COMMITs?

2009-10-23 Thread David Pollak
When an connection is finished on a thread, if no exception has happened,
the connection is committed

This will be fixed after I finish with defect 129 (I'm currently working on
it)

On Fri, Oct 23, 2009 at 2:36 PM, harryh har...@gmail.com wrote:


 Seeing a great many of these on my postgresql logs:

 2009-10-23 21:35:02 UTC WARNING:  there is no transaction in progress
 2009-10-23 21:35:02 UTC STATEMENT:  COMMIT

 Any idea what might be causing this?  I can filter them out but

 a) that would be a little annoying
 b) vaguely worried that something non ideal is going on here

 -harryh
 



-- 
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] NetBeans is barfing on the new pom.xml structure

2009-10-23 Thread David Pollak
Folks,

Any idea why NetBeans doesn't like the new Lift pom structure?

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: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread Derek Chen-Becker
Period is field-based, and therefore deals with non-linear time changes like
daylight savings time. Periods can be converted to millisecond durations
based on standard field durations (60 seconds == 1 minute, etc) if needed,
so it's a superset of the current functionality of TimeSpan.

On Fri, Oct 23, 2009 at 3:37 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 Well, I had intended to write a JodaHelpers trait that is the same as
 Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
 TimeHelpers and TimeFormats, respectively. The main reason is that I would
 like to have the time DSL be based on Periods instead of millisecond
 durations, and with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 It sounds like you're pretty set against making separate impl traits and
 would prefer just putting things directly on TimeHelper. I'm OK with that,
 but I would really like to add a lift-joda module that contains the
 JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to
 use them. I should be able to delegate a good chunk of the methods to
 TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
 reasonable compromise?


 Yes, as long as import Helpers._ is not incompatible with importing
 whatever trait you come up with.



 Derek


 On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I agree that the goal isn't to remove java.util.Date. For trivial time
 handling it works just fine. What I'm trying to achieve here is a way to
 make Joda Time be the default impl while leaving the user a choice. By 
 using
 separate traits instead of different names on the same trait, we achieve a
 few things:

1. A consistent API for both java.util and Joda Time in terms of
method names. As Naftoli pointed out, people expect naming of functions
consistent with what they do and having two different nows on the 
 same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that
utilizes Joda Time directly into TimeHelpers then it's not an optional
dependency. Making a separate trait means that if someone doesn't use 
 the
Joda Time trait then they don't need to have the Joda Time jar in their
classpath and they never know that it's not there.
3. A relatively simple code change path to move from java.util to
Joda Time by simply changing imports.

 Your assertion that Date is a simple wrapper for a Long timestamp is
 pretty accurate, but really Joda Time's DateTime is a superset of
 *Calendar*, not Date. Just look at what we had to do with 
 CalendarExtension
 to get some simple date manipulation functions, where those same methods 
 are
 already defined on DateTime. The vast majority of Joda Time's classes are
 immutable, and the mutators return new instances instead of modifying the
 current instance. TimeSpan's current handling of duration addition doesn't
 cope with DST, which I'm sure will show up as a bug in someone's code if 
 it
 hasn't already. Having done a fair amount of java.util.Date handling and
 then moving to Joda Time, I find it hard to call the difference between 
 the
 two APIs marginal. In any case, I still feel that my proposal makes Joda
 Time available in a nicer way while leaving existing code completely
 untouched (by introducing a JodaHelpers trait that mirrors Helpers).

 Derek


 On Tue, Oct 20, 2009 at 9:25 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim 
 naftoli...@gmail.com wrote:


 I agree with this.
 My understanding is that the goal is that Lift should use Joda for
 its time functions rather than java.util.


 This is not the goal.  The goal is to make JodeTime available.  There
 is no reason to remove support for java.util.Date.  None.

 JodaTime offers some advantages, but there's no reason, none, nada, to
 *remove* support for java.util.Date.

 I'm cool with different names (not jtNow, but choose something else).

 But I view removal of support for java.util.Date as gratuitous.  Sure,
 if we were to make the clean-slate decision today, I'd opt for primary
 support of JodaTime and secondary support for java.util.Date.  But we're
 making a decision based on legacy.  We're not going to cut off
 

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 Period is field-based, and therefore deals with non-linear time changes
 like daylight savings time. Periods can be converted to millisecond
 durations based on standard field durations (60 seconds == 1 minute, etc)
 if needed, so it's a superset of the current functionality of TimeSpan.


So, why not make TimeSpan use Period, but preserve the interface so you can
build one with millis and get it to spit out millis or Period as the case
may be?



 On Fri, Oct 23, 2009 at 3:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 Well, I had intended to write a JodaHelpers trait that is the same as
 Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
 TimeHelpers and TimeFormats, respectively. The main reason is that I would
 like to have the time DSL be based on Periods instead of millisecond
 durations, and with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 It sounds like you're pretty set against making separate impl traits
 and would prefer just putting things directly on TimeHelper. I'm OK with
 that, but I would really like to add a lift-joda module that contains the
 JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to
 use them. I should be able to delegate a good chunk of the methods to
 TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
 reasonable compromise?


 Yes, as long as import Helpers._ is not incompatible with importing
 whatever trait you come up with.



 Derek


 On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I agree that the goal isn't to remove java.util.Date. For trivial time
 handling it works just fine. What I'm trying to achieve here is a way to
 make Joda Time be the default impl while leaving the user a choice. By 
 using
 separate traits instead of different names on the same trait, we achieve 
 a
 few things:

1. A consistent API for both java.util and Joda Time in terms of
method names. As Naftoli pointed out, people expect naming of 
 functions
consistent with what they do and having two different nows on the 
 same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that
utilizes Joda Time directly into TimeHelpers then it's not an optional
dependency. Making a separate trait means that if someone doesn't use 
 the
Joda Time trait then they don't need to have the Joda Time jar in 
 their
classpath and they never know that it's not there.
3. A relatively simple code change path to move from java.util to
Joda Time by simply changing imports.

 Your assertion that Date is a simple wrapper for a Long timestamp is
 pretty accurate, but really Joda Time's DateTime is a superset of
 *Calendar*, not Date. Just look at what we had to do with 
 CalendarExtension
 to get some simple date manipulation functions, where those same methods 
 are
 already defined on DateTime. The vast majority of Joda Time's classes are
 immutable, and the mutators return new instances instead of modifying the
 current instance. TimeSpan's current handling of duration addition 
 doesn't
 cope with DST, which I'm sure will show up as a bug in someone's code if 
 it
 hasn't already. Having done a fair amount of java.util.Date handling and
 then moving to Joda Time, I find it hard to call the difference between 
 the
 two APIs marginal. In any case, I still feel that my proposal makes 
 Joda
 Time available in a nicer way while leaving existing code completely
 untouched (by introducing a JodaHelpers trait that mirrors Helpers).

 Derek


 On Tue, Oct 20, 2009 at 9:25 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim 
 naftoli...@gmail.com wrote:


 I agree with this.
 My understanding is that the goal is that Lift should use Joda for
 its time functions rather than java.util.


 This is not the goal.  The goal is to make JodeTime available.  There
 is no reason to remove support for java.util.Date.  None.

 JodaTime offers some advantages, but there's no reason, none, nada,
 to *remove* support for java.util.Date.

 I'm cool with different names (not jtNow, but choose something else).

 But I view removal of 

[Lift] Re: Testing for SQL Server drivers

2009-10-23 Thread Timothy Perrett
Ahhh sorry I didn't see this before - I'm using lift mapper with SQL  
server at work.

I can test this no worries. Just let me know what I should try ;-)

Cheers, Tim

Sent from my iPhone

On 23 Oct 2009, at 21:18, Derek Chen-Becker dchenbec...@gmail.com  
wrote:

 I'm pretty much 100% linux at home. I can test any other database  
 (Oracle, MySQL, PostgreSQL, etc), but SQL Server is the exception :)

 On Fri, Oct 23, 2009 at 2:14 PM, Naftoli Gugenheim naftoli...@gmail.com 
  wrote:
 100%. Just curious. :)


 On Fri, Oct 23, 2009 at 4:05 PM, David Pollak feeder.of.the.be...@gmail.com 
  wrote:


 On Fri, Oct 23, 2009 at 12:10 PM, Naftoli Gugenheim naftoli...@gmail.com 
  wrote:
 Don't you have a Windows machine that you can install SQL Server  
 Express on?

 Even if Derek does have such a machine, he's been doing an awful lot  
 of work on Lift.  Recruiting people from the community to help is  
 encouraged.



 On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker dchenbec...@gmail.com 
  wrote:
 Hi,
 I've made some changes to Mapper to better support SQL Server,  
 particularly with Unicode text. Does anyone out there use SQL Server  
 that would be willing to test the code on the wip-dcb-issue-16-sql- 
 server branch to make sure nothing breaks?

 Thanks,

 Derek








 -- 
 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: A Critique On Lift

2009-10-23 Thread Viktor Klang
But if you name your method: ashiuahsdyasdasd what does it do?

On Fri, Oct 23, 2009 at 9:47 PM, bob rbpas...@gmail.com wrote:


 I'll repeat: there are no operators in scala

 s/operators/methods-with-operator-like-names/

 anywhere, here's a typical case:

 import some.library.package.foo._

 val a = bar 42
 val b = a ~!~ 3.14159

 you can't easily tell that bar is being imported via foo._ .
 what is bar's return type?
 what does ~!~ do?

 i'm not saying its not possible to track all this down, but you can't
 just print out a listing of a class and take it on the subway. you
 have to have access to the scaladocs and possibly even the sources.

 --b



 



-- 
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: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread aw

 That's pretty much my take. The whole Java Calendar/Date/Timezone impl is
 poorly designed, hence Joda Time.


I like Joda Time too, and used to be apprehensive about integrating it
as a dependency into my projects -- at least for simple things that I
could probably do with Date/Calendar, just more hassle...  But I am
less apprehensive now that I know that Stephen Colebourne from Joda-
Time is developing JSR-310 (https://jsr-310.dev.java.net/) -- a new
Date and Time API for Java 7.  If you look at the API, the new
javax.time is basically stealing (I mean integrating) all of the best
parts of Joda-Time.

Now, I am happily using org.joda.time.LocalDate because I know that
eventually, I will just need to change my imports to upgrade to
javax.time.calendar.LocalDate.


I haven't had a close look at Scala-Time, but I am not sure if I
understand the value when using straight Joda Time with Scala was so
painless.  But I am sure there is room to leverage Scala features for
things like implicit conversions.

--~--~-~--~~~---~--~~
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: Security Explained

2009-10-23 Thread aw

Thank you for this, and so quickly!  I was able to leverage this for
what I needed.

--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Jim Barrows
On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang viktor.kl...@gmail.comwrote:

 But if you name your method: ashiuahsdyasdasd what does it do?


Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read
it



 On Fri, Oct 23, 2009 at 9:47 PM, bob rbpas...@gmail.com wrote:


 I'll repeat: there are no operators in scala

 s/operators/methods-with-operator-like-names/

 anywhere, here's a typical case:

 import some.library.package.foo._

 val a = bar 42
 val b = a ~!~ 3.14159

 you can't easily tell that bar is being imported via foo._ .
 what is bar's return type?
 what does ~!~ do?

 i'm not saying its not possible to track all this down, but you can't
 just print out a listing of a class and take it on the subway. you
 have to have access to the scaladocs and possibly even the sources.

 --b







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

 



-- 
James A Barrows

--~--~-~--~~~---~--~~
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: SLF4J Logging for my classes

2009-10-23 Thread aw

Sure, I could create a trait as you suggested...  But, this sounds
like a common problem -- does this not already exist?  I see
discussions about adding it to Scala, but I don't think it exists.
And Lift already has a logging infrastructure (i.e. LogBoot as you
suggest).  Does it not make sense to add this trait to lift-util or
lift-common?  (I just want to avoid recreating the wheel.)

--~--~-~--~~~---~--~~
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: A Critique On Lift

2009-10-23 Thread Viktor Klang
On Sat, Oct 24, 2009 at 12:23 AM, Jim Barrows jim.barr...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang viktor.kl...@gmail.comwrote:

 But if you name your method: ashiuahsdyasdasd what does it do?


 Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read
 it


Chtuluh ftagn! ;D





 On Fri, Oct 23, 2009 at 9:47 PM, bob rbpas...@gmail.com wrote:


 I'll repeat: there are no operators in scala

 s/operators/methods-with-operator-like-names/

 anywhere, here's a typical case:

 import some.library.package.foo._

 val a = bar 42
 val b = a ~!~ 3.14159

 you can't easily tell that bar is being imported via foo._ .
 what is bar's return type?
 what does ~!~ do?

 i'm not saying its not possible to track all this down, but you can't
 just print out a listing of a class and take it on the subway. you
 have to have access to the scaladocs and possibly even the sources.

 --b







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





 --
 James A Barrows



 



-- 
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: A Critique On Lift

2009-10-23 Thread Jim Barrows
On Fri, Oct 23, 2009 at 3:28 PM, Viktor Klang viktor.kl...@gmail.comwrote:

 On Sat, Oct 24, 2009 at 12:23 AM, Jim Barrows jim.barr...@gmail.comwrote:

 On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang viktor.kl...@gmail.comwrote:

 But if you name your method: ashiuahsdyasdasd what does it do?


 Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read
 it


 Chtuluh ftagn! ;D


Huh.  Now he's 6 inches tall and has a red nose interesting.

Also I think we've made our point about cryptic method names whether there
alphanumeric or not, whether you call them operators or not... are
problematic.

Now excuse me... cthulu appears to be mucking with my code

James A Barrows

--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread Derek Chen-Becker
I could do that, but I would still have an ambiguous definition of now,
today, epoch, etc if I want to use Joda Time and the requirement is that
an import Helpers._ cannot conflict. The whole reason that I want to write a
separate trait is that Lift currently has some nice convenience methods and
a DSL in TimeHelpers, but they all return java.util.{Calendar,Date}. I'm
just trying to mirror the API usage, except have everything return Joda Time
classes instead. That way, I can upgrade all of my current Lift apps to use
Joda Time simply by changing the import. It's entirely subjective, but I
just strongly dislike the idea of using method names like jtNow, etc.
Anthony brings up a good point about Joda Time in large part becoming the
new Java Date/Time API, but we can always deal with that when it comes
along.

Derek

On Fri, Oct 23, 2009 at 4:00 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 Period is field-based, and therefore deals with non-linear time changes
 like daylight savings time. Periods can be converted to millisecond
 durations based on standard field durations (60 seconds == 1 minute, etc)
 if needed, so it's a superset of the current functionality of TimeSpan.


 So, why not make TimeSpan use Period, but preserve the interface so you can
 build one with millis and get it to spit out millis or Period as the case
 may be?



 On Fri, Oct 23, 2009 at 3:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 Well, I had intended to write a JodaHelpers trait that is the same as
 Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
 TimeHelpers and TimeFormats, respectively. The main reason is that I would
 like to have the time DSL be based on Periods instead of millisecond
 durations, and with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 It sounds like you're pretty set against making separate impl traits
 and would prefer just putting things directly on TimeHelper. I'm OK with
 that, but I would really like to add a lift-joda module that contains the
 JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like 
 to
 use them. I should be able to delegate a good chunk of the methods to
 TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
 reasonable compromise?


 Yes, as long as import Helpers._ is not incompatible with importing
 whatever trait you come up with.



 Derek


 On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I agree that the goal isn't to remove java.util.Date. For trivial
 time handling it works just fine. What I'm trying to achieve here is a 
 way
 to make Joda Time be the default impl while leaving the user a choice. 
 By
 using separate traits instead of different names on the same trait, we
 achieve a few things:

1. A consistent API for both java.util and Joda Time in terms of
method names. As Naftoli pointed out, people expect naming of 
 functions
consistent with what they do and having two different nows on the 
 same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that
utilizes Joda Time directly into TimeHelpers then it's not an 
 optional
dependency. Making a separate trait means that if someone doesn't 
 use the
Joda Time trait then they don't need to have the Joda Time jar in 
 their
classpath and they never know that it's not there.
3. A relatively simple code change path to move from java.util to
Joda Time by simply changing imports.

 Your assertion that Date is a simple wrapper for a Long timestamp is
 pretty accurate, but really Joda Time's DateTime is a superset of
 *Calendar*, not Date. Just look at what we had to do with 
 CalendarExtension
 to get some simple date manipulation functions, where those same 
 methods are
 already defined on DateTime. The vast majority of Joda Time's classes 
 are
 immutable, and the mutators return new instances instead of modifying 
 the
 current instance. TimeSpan's current handling of duration addition 
 doesn't
 cope with DST, which I'm sure will show up as a bug in someone's code 
 if it
 hasn't already. Having done a fair amount of java.util.Date handling and
 then moving to Joda 

[Lift] In the spirit of Friday, anyone want to see this ruby rack ported to lift?

2009-10-23 Thread Jim Barrows
http://coderack.org/users/MetaSkills/entries/15-zombie-shotgun

and yes, I'm volunteering. :)

-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 3:53 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 I could do that, but I would still have an ambiguous definition of now,
 today, epoch, etc if I want to use Joda Time and the requirement is that
 an import Helpers._ cannot conflict.


now, today and epoch are not part of TimeSpan.

Update TimeSpan to *internally* use Periods.  Don't break the interface to
TimeSpan.  If you add methods to TimeSpan, that's fine.

Please add additional methods to TimeHelpers that support returning the
JodaTime equivalents of what now, today, and epoch return.


 The whole reason that I want to write a separate trait is that Lift
 currently has some nice convenience methods and a DSL in TimeHelpers, but
 they all return java.util.{Calendar,Date}. I'm just trying to mirror the API
 usage, except have everything return Joda Time classes instead. That way, I
 can upgrade all of my current Lift apps to use Joda Time simply by changing
 the import. It's entirely subjective, but I just strongly dislike the idea
 of using method names like jtNow, etc. Anthony brings up a good point about
 Joda Time in large part becoming the new Java Date/Time API, but we can
 always deal with that when it comes along.

 Derek


 On Fri, Oct 23, 2009 at 4:00 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 Period is field-based, and therefore deals with non-linear time changes
 like daylight savings time. Periods can be converted to millisecond
 durations based on standard field durations (60 seconds == 1 minute, etc)
 if needed, so it's a superset of the current functionality of TimeSpan.


 So, why not make TimeSpan use Period, but preserve the interface so you
 can build one with millis and get it to spit out millis or Period as the
 case may be?



 On Fri, Oct 23, 2009 at 3:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 Well, I had intended to write a JodaHelpers trait that is the same as
 Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
 TimeHelpers and TimeFormats, respectively. The main reason is that I would
 like to have the time DSL be based on Periods instead of millisecond
 durations, and with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of
 milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 It sounds like you're pretty set against making separate impl traits
 and would prefer just putting things directly on TimeHelper. I'm OK with
 that, but I would really like to add a lift-joda module that contains 
 the
 JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like 
 to
 use them. I should be able to delegate a good chunk of the methods to
 TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
 reasonable compromise?


 Yes, as long as import Helpers._ is not incompatible with importing
 whatever trait you come up with.



 Derek


 On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I agree that the goal isn't to remove java.util.Date. For trivial
 time handling it works just fine. What I'm trying to achieve here is a 
 way
 to make Joda Time be the default impl while leaving the user a choice. 
 By
 using separate traits instead of different names on the same trait, we
 achieve a few things:

1. A consistent API for both java.util and Joda Time in terms of
method names. As Naftoli pointed out, people expect naming of 
 functions
consistent with what they do and having two different nows on the 
 same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that
utilizes Joda Time directly into TimeHelpers then it's not an 
 optional
dependency. Making a separate trait means that if someone doesn't 
 use the
Joda Time trait then they don't need to have the Joda Time jar in 
 their
classpath and they never know that it's not there.
3. A relatively simple code change path to move from java.util
to Joda Time by simply changing imports.

 Your assertion that Date is a simple wrapper for a Long timestamp is
 pretty accurate, but really Joda Time's DateTime is a superset of
 *Calendar*, not Date. Just look at what we had to do with 
 CalendarExtension
 to get some simple date manipulation functions, where those same 
 

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread Derek Chen-Becker
I'll make these changes and work on improving the internal implementation of
TimeSpan and TimeHelpers to work better within the existing method
signatures, but I want to be clear that I'm extremely unhappy that I can't
be accommodated otherwise.

Thanks,

Derek

On Fri, Oct 23, 2009 at 5:05 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 On Fri, Oct 23, 2009 at 3:53 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 I could do that, but I would still have an ambiguous definition of now,
 today, epoch, etc if I want to use Joda Time and the requirement is that
 an import Helpers._ cannot conflict.


 now, today and epoch are not part of TimeSpan.

 Update TimeSpan to *internally* use Periods.  Don't break the interface to
 TimeSpan.  If you add methods to TimeSpan, that's fine.

 Please add additional methods to TimeHelpers that support returning the
 JodaTime equivalents of what now, today, and epoch return.


 The whole reason that I want to write a separate trait is that Lift
 currently has some nice convenience methods and a DSL in TimeHelpers, but
 they all return java.util.{Calendar,Date}. I'm just trying to mirror the API
 usage, except have everything return Joda Time classes instead. That way, I
 can upgrade all of my current Lift apps to use Joda Time simply by changing
 the import. It's entirely subjective, but I just strongly dislike the idea
 of using method names like jtNow, etc. Anthony brings up a good point about
 Joda Time in large part becoming the new Java Date/Time API, but we can
 always deal with that when it comes along.

 Derek


 On Fri, Oct 23, 2009 at 4:00 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 Period is field-based, and therefore deals with non-linear time changes
 like daylight savings time. Periods can be converted to millisecond
 durations based on standard field durations (60 seconds == 1 minute, etc)
 if needed, so it's a superset of the current functionality of TimeSpan.


 So, why not make TimeSpan use Period, but preserve the interface so you
 can build one with millis and get it to spit out millis or Period as the
 case may be?



 On Fri, Oct 23, 2009 at 3:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 Well, I had intended to write a JodaHelpers trait that is the same as
 Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
 TimeHelpers and TimeFormats, respectively. The main reason is that I 
 would
 like to have the time DSL be based on Periods instead of millisecond
 durations, and with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of
 milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 It sounds like you're pretty set against making separate impl traits
 and would prefer just putting things directly on TimeHelper. I'm OK 
 with
 that, but I would really like to add a lift-joda module that contains 
 the
 JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would 
 like to
 use them. I should be able to delegate a good chunk of the methods to
 TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
 reasonable compromise?


 Yes, as long as import Helpers._ is not incompatible with importing
 whatever trait you come up with.



 Derek


 On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I agree that the goal isn't to remove java.util.Date. For trivial
 time handling it works just fine. What I'm trying to achieve here is 
 a way
 to make Joda Time be the default impl while leaving the user a 
 choice. By
 using separate traits instead of different names on the same trait, we
 achieve a few things:

1. A consistent API for both java.util and Joda Time in terms
of method names. As Naftoli pointed out, people expect naming of 
 functions
consistent with what they do and having two different nows on 
 the same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that
utilizes Joda Time directly into TimeHelpers then it's not an 
 optional
dependency. Making a separate trait means that if someone doesn't 
 use the
Joda Time trait then they don't need to have the Joda Time jar in 
 their
classpath and they never know that it's not there.
3. A relatively simple code 

[Lift] Playing around with Loc

2009-10-23 Thread Kris Nuttycombe

Hi, all,

I've been messing around with Loc a bit to try to tighten up the type
safety of the parameterized type and add authentication LocParams that
can be aware of the current value encapsulated by the Loc. I've put up
some changes on the kjn-loc-wip branch and would really like some
feedback.

Some of the major changes:

* gave LocParam a covariant type parameter to go with Loc's type
parameter and made it a sealed trait, with UserLocParam[T] as the main
extension point for user-defined traits. Added AnyLocParam as base
trait of LocParam instances that are not dependent upon T
* Added IfValue  UnlessValue LocParams
* Made default Loc parameterized by Unit instead of NullLocParams
* Some minor renaming to distinguish between uses of the Param name-
- now all Param usages refer to LocParams
* Removed need for a bunch of asInstanceOf casts

What do you all think? Is this something that you'd like to see
cleaned up  committed to master?

Thanks,

--~--~-~--~~~---~--~~
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: catch a URL

2009-10-23 Thread Chris Lewis

Great suggestions - thanks guys!

Jeppe Nejsum Madsen wrote:
 Timothy Perrett timo...@getintheloop.eu writes:
 
 Ah. In that case, does this help:

  Menu(Loc(Some, List(some,page), Some,
EarlyResponse(() = {
  // do some response here,
  // return Empty if you dont want
  // a response but a filter style
  // intercept.
  Empty
})
  ))

 Does that help?
 
 Or, if you just need to run some code before a template is rendered:
 
 Menu(Loc(test, List(landing), test, Template{() = 
  println(Hit the template URL);
  // Handle Empty case :-)
  
 TemplateFinder.findAnyTemplate(List(mytemplat,index)).open_!
}))
 
 /Jeppe
 
  
 

--~--~-~--~~~---~--~~
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: NetBeans is barfing on the new pom.xml structure

2009-10-23 Thread Kris Nuttycombe

I ran into that -it's a missing version number in the root pom. Fixed
in my kjn-loc-wip branch if you just want to grab it from there.

On Fri, Oct 23, 2009 at 3:41 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 Folks,

 Any idea why NetBeans doesn't like the new Lift pom structure?

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