[Lift] Re: Problem with default Connection pool/CP for use with lift?

[Jeppe Nejsum Madsen]

David Pollak feeder.of.the.be...@gmail.com writes:

 At least the most recent version of Boot.scala has reasonable testing of
 connection validity:

 case x :: xs = try {
   x.setAutoCommit(false)
   Full(x)
 } catch {
   case e = try {
 pool = xs
 poolSize = poolSize - 1
 x.close
 newConnection(name)
   } catch {
 case e = newConnection(name)
   }
 }

 If the setAutoCommit(false) line fails, the connection is returned to the
 pool.  You can put other logic here.

Yes, I can always put a SELECT 1 in there, but was curious what others
are doing in this regard (if anything)

/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: How to disable a textfield

[Timothy Perrett]

Change - to -%

Doing this preserves any element attributes, for example:
disabled=disabled

Cheers, Tim

On Oct 20, 6:30 am, sunanda sunanda.pa...@gmail.com wrote:
 Hi,
 I need to disable all the textfield and then want to enable the fields
 for editing on click of a button.
 How can i do this with the following sample  code.
 Thanks
 Regards,
 Sunanda.

 bind(add,html,
                      displayname-coldef.displayname.toForm,
                      columntype-coldef.coltype.toForm,
                      sourceview-coldef.sourceview.toForm)
--~--~-~--~~~---~--~~
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 with default Connection pool/CP for use with lift?

[Jeppe Nejsum Madsen]

David Pollak feeder.of.the.be...@gmail.com writes:

 At least the most recent version of Boot.scala has reasonable testing of
 connection validity:

 case x :: xs = try {
   x.setAutoCommit(false)
   Full(x)
 } catch {
   case e = try {
 pool = xs
 poolSize = poolSize - 1
 x.close
 newConnection(name)
   } catch {
 case e = newConnection(name)
   }
 }

 If the setAutoCommit(false) line fails, the connection is returned to the
 pool.  You can put other logic here.

Ok, I just made this change and added some logging around new/Release. I
was a little surprised to see that newConnection is called three times
for each request. Is this intentional? 

I have S.addAround(DB.buildLoanWrapper) in boot, which I assumed would
wrap each request with a transaction and thus use the same connection
for the duration of the request? I've verified that the same connection
is used on two requests executing at the same time which sounds a bit
scary

Did I miss something?

/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: Problem with default Connection pool/CP for use with lift?

[Jeppe Nejsum Madsen]

On Tue, Oct 20, 2009 at 10:34 AM, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 David Pollak feeder.of.the.be...@gmail.com writes:

 At least the most recent version of Boot.scala has reasonable testing of
 connection validity:

     case x :: xs = try {
           x.setAutoCommit(false)
           Full(x)
         } catch {
           case e = try {
             pool = xs
             poolSize = poolSize - 1
             x.close
             newConnection(name)
           } catch {
             case e = newConnection(name)
           }
         }

 If the setAutoCommit(false) line fails, the connection is returned to the
 pool.  You can put other logic here.

 Ok, I just made this change and added some logging around new/Release. I
 was a little surprised to see that newConnection is called three times
 for each request. Is this intentional?

Sorry, to keep adding to this thread, but I looked a little more in
the archetype implementation of ConnectionManager, and to me, it seems
like it is broken in several ways and will eventually lead to an OOME:

I think the logic is that pool should contain the list of connections
available for use by a request and not all the connections created?
But it seems like the implementation mix those two views:

First time through, pool is Nil so we match the first case statement,
create a new connection _AND ADD IT TO POOL_. First error: we return
the connection (ie it is in use) but still add it to the list of free
connections. Another request coming in while we process this request,
will get the same connection.

When releasing the connection, we add the released connection to the pool. Fine.

Next time, pool is not Nil so we match the x::xs case and return x.
Second error: we don't update pool to xs, x is still available for any
request coming in while we're using this connection.

And since connections are never removed from pool under normal
circumstances but always added on release, the pool list just keeps
growing.

I'll post an updated version soon

 /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] lift:bind-at get warnings for every request

[night_stalker]

Hi all.
When using lift:bind-at, the result page is fine as I wished,
yet these warnings run into the log for every request:

WARN - Unused binding values for lift:bind: content, main
WARN - Unused binding values for lift:bind: sidebar, main
WARN - Unused binding values for lift:bind: sidebar

Am I missing something, or, can I disable these warnings?
The lift version is 1.1-M6, template code are like below:


templates-hidden/someLayout.html

...begin stuff
lift:bind name=sidebar/
...between stuff
lift:bind name=content/
...end stuff


somePage.html

lift:surround with=someLayout
  lift:bind-at name=sidebar
...sidebar stuff
  /lift:bind-at
  lift:bind-at name=content
...content stuff
  /lift:bind-at
/lift:surround

--~--~-~--~~~---~--~~
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] net.liftweb.widgets.autocomplete in version 1.1-M6

[Tweek]

Hi,
Previously i was working on version 1.1-M3 of lift framework and i
used autocomplete widget by override _toForm method in my Test.scala
file. It was something like that:

object Test extends Test with KeyedMetaMapper[Long, Test] with CRUDify
[Long,Test] {
(...)
}

class Test extends KeyedMapper[Long, Test] {

(...)

object TestTable extends MappedLongForeignKey(this, TestTable) {
def handleSubmit( string : String) = {

}

override def _toForm = Full( AutoComplete(, (current, limit)
= {
TestTable.findAll.toList.map(d = (d.name.is)) },
handleSubmit ))

}

(...)

}

But now, after upgrade lift to version 1.1-M6, i'm getting this error:

   error: type mismatch;
   found   : scala.xml.NodeSeq
   required: scala.xml.Elem
   override def _toForm = Full( AutoComplete(, (current,
limit) = {
^
   one error found.


I can't find way to fix this problem. Could Anyone help me?

Thanks and regards

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

[Derek Chen-Becker]

Here is my argument for breaking it out:

I think that we're in agreement that the *default* impl for Lift should
eventually be Joda Time, after some period of deprecation on the old stuff.
I also agree with your earlier comment that it should be something that the
developer can choose. I'm sure there will be cases where people want to use
java.util instead of Joda Time because of preference or constraint (say, no
external jars). The problem is that import Helpers._ is a very common
import, and by having TimeHelpers be part of Helpers it makes it very
difficult to do a clean separation of impls. My main example is the time
manipulation DSL. We can't mask the implicit defs that are already part of
TimeHelpers, so it's very difficult (maybe impossible) to define a Joda Time
based DSL (which would properly handle things like daylight savings time,
etc). By removing TimeHelpers from Helpers, it means that the user can have
absolute control over which time handling impl they're using without having
to give up all of the nice things in Helpers. It would be a breaking change
to code, but it would be pretty minor, since the fix is just to add an
import to the code that breaks. Here is my proposal for how we change
things:


   - *version 1.1-final*:


   1. Rename the current TimeHelpers trait to JavaTimeHelpers and add a new
  TimeHelpers trait that extends JavaTimeHelpers, providing an alias. This
  means no breaking code in this release.
  2. Create a new JodaTimeHelpers that mirrors the non-deprecated
  functionality of JavaTimeHelpers (there were already some
deprecated methods
  on TimeHelpers that could go away).
  3. We can also copy back some of the new methods on JodaTimeHelpers
  and refactor them for java.util (I'm thinking epoch and some other minor
  ones).
  4. Add a JavaTimeFormatting and JodaTimeFormatting trait (currently
  TimeRules in my code) that allows for custom formats and format
functions of
  dates and times. The reason I want to split out the impls here, just like
  Java/JodaTimeHelpers, is so that Joda can be an optional dependency for
  people who can't use it.


   - *version 1.2-final*:


   1. Remove the TimeHelpers trait and remove TimeHelpers from Helpers. At
   this point, people would have to explicitly choose JavaTimeHelpers or
   JodaTimeHelpers in their import statement to determine which impl they're
   using.

The main thing is that having TimeHelpers tied to Helpers makes it very
difficult to give the user a choice of impls, something that I feel strongly
goes against how Lift does things otherwise.

Derek

On Mon, Oct 19, 2009 at 10:36 PM, David Pollak 
feeder.of.the.be...@gmail.com wrote:

 I have a strong preference not to break the TimeHelpers out of Helpers.
 I'm not seeing the problem with additional methods on TimeHelpers that do
 the JodaTime thing.  Can you guys help me understand your point of view.


 On Mon, Oct 19, 2009 at 8:16 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 Oh, that was a sidetrack. I was thinking that it could help enforce the
 common contract, but return types are different for the same method names so
 that really wouldn't work. I really just want to try and separate them out,
 or provide a different Helpers that provides JodaTime stuff under the same
 method names. My goal is really to minimize code changes, so one or two
 imports instead of a lot of find/replace (as simple as that may be) would be
 preferable in my book.

 Derek


 On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim 
 naftoli...@gmail.comwrote:


 What would be the purpose of having a common trait though?

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

 That was pretty much what I was trying to communicate with my last email,
 just not very effectively.

 Derek

 On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim naftoli...@gmail.com
 wrote:

 
  Since there are anyway minor breaking changes in 1.1, maybe it's worth
 it
  to take TimeHelpers out of Helpers. This way, it will simply require an
  extra import, of either TimeHelpers or JodaHelpers, which can be chosen
 by
  the individual developer.
  Whenever someone is ready to migrate, they will be able to do so on a
  file-by-file (or import-scope-by-import-scope) basis.
  Eventually JodaHelpers could be included in Helpers.
 
 
  -
  Derek Chen-Beckerdchenbec...@gmail.com wrote:
 
  Along those same lines, maybe there should be a common trait that
 doesn't
  define an impl, and then have separate Joda and java.util impl traits
 that
  don't mix directly into Helpers.
 
  On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
  wrote:
 
   What I was thinking earlier is that we can simply make a JodaHelpers
  object
   that mixes in JodaTimeHelpers instead of TimeHelpers. That way, code
  changes
   to move to Joda Time would mostly just be an import change instead of

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

[Derek Chen-Becker]

s/version 1.2-final/some future version/


On Tue, Oct 20, 2009 at 8:01 AM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 Here is my argument for breaking it out:

 I think that we're in agreement that the *default* impl for Lift should
 eventually be Joda Time, after some period of deprecation on the old stuff.
 I also agree with your earlier comment that it should be something that the
 developer can choose. I'm sure there will be cases where people want to use
 java.util instead of Joda Time because of preference or constraint (say, no
 external jars). The problem is that import Helpers._ is a very common
 import, and by having TimeHelpers be part of Helpers it makes it very
 difficult to do a clean separation of impls. My main example is the time
 manipulation DSL. We can't mask the implicit defs that are already part of
 TimeHelpers, so it's very difficult (maybe impossible) to define a Joda Time
 based DSL (which would properly handle things like daylight savings time,
 etc). By removing TimeHelpers from Helpers, it means that the user can have
 absolute control over which time handling impl they're using without having
 to give up all of the nice things in Helpers. It would be a breaking change
 to code, but it would be pretty minor, since the fix is just to add an
 import to the code that breaks. Here is my proposal for how we change
 things:


- *version 1.1-final*:


1. Rename the current TimeHelpers trait to JavaTimeHelpers and add a
   new TimeHelpers trait that extends JavaTimeHelpers, providing an alias. 
 This
   means no breaking code in this release.
   2. Create a new JodaTimeHelpers that mirrors the non-deprecated
   functionality of JavaTimeHelpers (there were already some deprecated 
 methods
   on TimeHelpers that could go away).
   3. We can also copy back some of the new methods on JodaTimeHelpers
   and refactor them for java.util (I'm thinking epoch and some other minor
   ones).
   4. Add a JavaTimeFormatting and JodaTimeFormatting trait (currently
   TimeRules in my code) that allows for custom formats and format 
 functions of
   dates and times. The reason I want to split out the impls here, just 
 like
   Java/JodaTimeHelpers, is so that Joda can be an optional dependency for
   people who can't use it.


- *version 1.2-final*:


1. Remove the TimeHelpers trait and remove TimeHelpers from Helpers. At
this point, people would have to explicitly choose JavaTimeHelpers or
JodaTimeHelpers in their import statement to determine which impl they're
using.

 The main thing is that having TimeHelpers tied to Helpers makes it very
 difficult to give the user a choice of impls, something that I feel strongly
 goes against how Lift does things otherwise.

 Derek


 On Mon, Oct 19, 2009 at 10:36 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I have a strong preference not to break the TimeHelpers out of Helpers.
 I'm not seeing the problem with additional methods on TimeHelpers that do
 the JodaTime thing.  Can you guys help me understand your point of view.


 On Mon, Oct 19, 2009 at 8:16 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 Oh, that was a sidetrack. I was thinking that it could help enforce the
 common contract, but return types are different for the same method names so
 that really wouldn't work. I really just want to try and separate them out,
 or provide a different Helpers that provides JodaTime stuff under the same
 method names. My goal is really to minimize code changes, so one or two
 imports instead of a lot of find/replace (as simple as that may be) would be
 preferable in my book.

 Derek


 On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim naftoli...@gmail.com
  wrote:


 What would be the purpose of having a common trait though?

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

 That was pretty much what I was trying to communicate with my last
 email,
 just not very effectively.

 Derek

 On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim 
 naftoli...@gmail.comwrote:

 
  Since there are anyway minor breaking changes in 1.1, maybe it's worth
 it
  to take TimeHelpers out of Helpers. This way, it will simply require
 an
  extra import, of either TimeHelpers or JodaHelpers, which can be
 chosen by
  the individual developer.
  Whenever someone is ready to migrate, they will be able to do so on a
  file-by-file (or import-scope-by-import-scope) basis.
  Eventually JodaHelpers could be included in Helpers.
 
 
  -
  Derek Chen-Beckerdchenbec...@gmail.com wrote:
 
  Along those same lines, maybe there should be a common trait that
 doesn't
  define an impl, and then have separate Joda and java.util impl traits
 that
  don't mix directly into Helpers.
 
  On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
  wrote:
 
   What I was thinking earlier is that we can simply 

[Lift] Re: lift:bind-at get warnings for every request

[Ross Mellgren]

I encountered these and sent a message to the list last week or so. I  
didn't hear anything back, maybe the best route is to file an issue?

http://github.com/dpp/liftweb/issues

-Ross

On Oct 20, 2009, at 5:30 AM, night_stalker wrote:


 Hi all.
 When using lift:bind-at, the result page is fine as I wished,
 yet these warnings run into the log for every request:

 WARN - Unused binding values for lift:bind: content, main
 WARN - Unused binding values for lift:bind: sidebar, main
 WARN - Unused binding values for lift:bind: sidebar

 Am I missing something, or, can I disable these warnings?
 The lift version is 1.1-M6, template code are like below:

 
 templates-hidden/someLayout.html

 ...begin stuff
 lift:bind name=sidebar/
 ...between stuff
 lift:bind name=content/
 ...end stuff

 
 somePage.html

 lift:surround with=someLayout
  lift:bind-at name=sidebar
...sidebar stuff
  /lift:bind-at
  lift:bind-at name=content
...content stuff
  /lift:bind-at
 /lift:surround

 


--~--~-~--~~~---~--~~
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: scalajpa - wrong database?

[Derek Chen-Becker]

Another note is that ScalaJPA provides a pretty thin wrapper on a JPA
persistence unit. Each persistence unit represents *one* database, so you
actually need more than one persistence unit to have connections to two
databases. I recently added support in 1.2-SNAPSHOT so that you can provide
a property map to LocalEMF to allow you to use the same unit with different
database connections, but if you're using JNDI that won't work. If you're
still having the issue, could you post some code that shows where it's
failing?

Thanks,

Derek

On Tue, Oct 20, 2009 at 6:37 AM, Jean-Luc jlcane...@gmail.com wrote:

 Which liftweb version are you using ?
 I've signaled a bug a few month ago, it was very very quickly fixed (thank
 you again Derek for your reactivity !). My jpa apps are in production and I
 have no such issue remaining, scalajpa looks like to be very stable.

 Once, I wrongly specified a wrong persistence-unit/@name value in test
 mode, and it caused the same symptoms. Have you verified that your LocalEMF
 configuration suits your META-INF/persistence.xml file ?

 Maybe you want to copy / paste your source code for a quick review ?


 Jean-Luc

 2009/10/19 TSP tim.pig...@optrak.co.uk


 I'm using scalajpa and have just downloaded source from github
 My application has 2 databases and my unit tests are creating tables
 for the second database in the first.
 This was a reported issue back around June I think, but the posts seem
 to imply it was fixed.
 Was it not?
 Thanks
 Tim




 --
 Jean-Luc Canela
 jlcane...@gmail.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: Including the class name in the JSON field

[Derek Chen-Becker]

Are you putting these changes in Review Board, or is this still experimental
work?

Derek

On Mon, Oct 19, 2009 at 9:02 AM, Joni Freeman freeman.j...@gmail.comwrote:


 Added a way to change how 'type hints' are processed. The default is
 NoTypeHints which will never output 'jsonClass' field. Then there's
 ShortTypeHints and FullTypeHints.

 implicit val formats = Serialization.formats(ShortTypeHints(classOf
 [Fish] :: classOf[Dog] :: Nil))

 - { jsonClass:Fish, ... }

 implicit val formats = Serialization.formats(FullTypeHints(classOf
 [Animal] :: Nil))

 - { jsonClass:com.example.Fish, ... }

 TypeHints trait can be used to reduce couplings (as suggested by
 Steve).

 Cheers Joni

 On 18 loka, 23:46, Joni Freeman freeman.j...@gmail.com wrote:
  There's now some support to deserialize parameterized types in that
  experimental branch. For instance, these all work:
 
implicit val formats = Serialization.formats(TypeHints(classOf
  [Animal] :: Nil))
 
case class Animals(animals: List[Animal])
trait Animal
case class Dog(name: String) extends Animal
case class Fish(weight: Double) extends Animal
 
case class Objs(objects: List[Obj[_]])
case class Obj[A](a: A)
 
val animals = Animals(Dog(pluto) :: Fish(1.2) :: Dog(devil) ::
  Nil)
val ser = swrite(animals)
read[Animals](ser) mustEqual animals
 
val objs = Objs(Obj(Fish(1.2)) :: Obj(Dog(pluto)) :: Nil)
val ser = swrite(objs)
read[Objs](ser) mustEqual objs
 
val t: (Animal, Animal) = (Fish(1.5), Dog(pluto))
val ser = swrite(t)
read[(Animal, Animal)](ser) mustEqual t
 
  The first line (implicit val formats ...) configures the serialization
  to output type hint (jsonClass field) for all instances of class
  Animal. This is required since above examples use Animal's in
  polymorphic way. Comments?
 
  Cheers Joni
 
  On 18 loka, 01:27, David Pollak feeder.of.the.be...@gmail.com wrote:
 
   On Sat, Oct 17, 2009 at 7:54 AM, Joni Freeman freeman.j...@gmail.com
 wrote:
 
I've been thinking this feature today a bit too. Marius raises an
important point. Adding type information and more complex
serialization scheme will introduce couplings, making it for instance
more difficult to deserializeJSONusing a different language or
toolkit. On a positive side, we might get support for other
parameterized types too (tuples for instance).
 
I pushed an experimental branch (joni_issue_108) which contains
serialization part of this feature (the easy part really). It adds
'jsonClass' field to objects.
 
 case class Animals(animals: List[Animal])
 trait Animal
 case class Dog(name: String) extends Animal
 case class Fish(weight: Double) extends Animal
 
 scala write(Animals(Dog(pluto) :: Fish(1.2) :: Dog(devil) ::
Nil))
 res0: String = {jsonClass:Animals,animals:
   
 [{jsonClass:Dog,name:pluto},{jsonClass:Fish,weight:1.2},
{jsonClass:Dog,name:devil}]}
 
Possible actions:
 
* Do not support parameterized types (status quo)
 
 + Simple scheme, easy to serialize in language agnostic way
 - Limited
 
   I like this option.  I'm not looking for a full Java serialization
 style
   solution.  But having hints as to the type of the particularJSONobject
   would be helpful.  Being able to register a jsonClass - Scala class
   deserializer makes sense.  Being able to specify a Scala class - class
 name
   is a good thing (with the default being the actual class name without
 the
   package).
 
* Add full type information when serializing/deserializing
 
 + Opens possibility to deserialize polymorphic types
 + Deserialization can be done without any explicit type information
(read(...) vs. read[ExpectedType](...))
 - Introduces couplings
 - This is still not a generic serialization solution, there's still
a lot of Scala classes which can't be deserialized
 
* Support both schemes
 
 + Moar choice
 - Choice it not necessarily a good thing (adds complexity etc.)
 
Cheers Joni
 
On 17 loka, 11:40, Marius marius.dan...@gmail.com wrote:
 Hmmm ... I wonder if heterogeneous lists should be supported. I
 also
 wonder if type knowledge inJSONis a good thing to do as it seems to
 me that we're bringing knowledge from another domain creating
 couplings. I'm not sure if there is a different way to solve this
 ...
 it just doesn't feel completely right to me ... but this doesn't
 necessarily mean it is not right :)
 
 Br's,
 Marius
 
 On Oct 15, 1:47 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
 
  Folks,
  What are thoughts on including (perhaps optionally) the name of
 the
case
  class in an additionalJSONfield so that one can reconstruct a
 list
that
  contains many different types?
 
  Thanks,
 
  David
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning 

[Lift] Re: how to use JqKeypress?

[Derek Chen-Becker]

I think that the ajaxText already handles an enter key as field
submission. Here's the code that defines an ajaxText field:


   1.   private def
ajaxText_*(value: String, jsFunc: Box[Call], func: AFuncHolder,
attrs: (String, String)*): Elem = {
   2. val raw = (funcName: String, value:String) = JsRaw('
+funcName + =' + encodeURIComponent( + value + .value))
   3. val key = formFuncName
   4.
   5. fmapFunc(func){
   6.   funcName =
   7.   (attrs.foldLeft(input type=text value={value}/)(_ % _)) %
   8.   (onkeypress - liftUtils.lift_blurIfReturn(event)) %
   9.   (onblur - (jsFunc match {
   10. case Full(f) = JsCrVar(key, JsRaw(this
   ))  deferCall(raw(funcName, key), f)
   11. case _ = makeAjaxCall(raw(funcName, this))
   12.   })
   13.   )
   14. }
   15.   }


Note the onkeypress and onblur event handlers. If you need to do some
extra handling on the client side, you can provide the jsFunc parameter
which will be used to submit the ajax call.

Derek


On Mon, Oct 19, 2009 at 6:13 PM, harryh har...@gmail.com wrote:


 It seems like I ought to be able to use JqKeypress so that if a user
 presses enter when a text input has focus an associated ajaxButton is
 submitted.  I can't get it to work though.  Help?

 Basically I have a bunch of little form like so

 [  text input   ] [go!]

 that I want to submit (ajax style) when the user presses enter.

 -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: Setting Table Border

[Derek Chen-Becker]

Get firebug and look at the CSS hierarchy for the element. That should
locate where it's being overridden pretty quickly.

Derek

On Mon, Oct 19, 2009 at 9:53 PM, sunanda sunanda.pa...@gmail.com wrote:


 Thats what I wonder. It should work. When I refer to a css file with
 the border setting it works,
 but not with the setting from the snippet. I need to figure it out.
 Thanks for your reply.
 Sunanda.

 On Oct 20, 2:35 pm, Ross Mellgren dri...@gmail.com wrote:
  That looks right to me -- it should show a border with a default
  stylesheet. When I throw that table.../table into a HTML file by
  itself, I get a border.
 
  -Ross
 
  On Oct 19, 2009, at 8:47 PM, sunanda wrote:
 
 
 
 
 
   Hi,
   I need to display the table with border.
   Following is the sample code.
   But it is not displaying the border.Is this the correct way of setting
   the border.
 
   Sunanda
 
   def displayColDef(selectedname:String):NodeSeq={
 
  val coldef = getColDef(selectedname)
 table border=2
 tr
 td bDisplay Name/b/td
 td{coldef.displayname}/td
 /tr
 tr
 tdbColumn Type/b /td
 td {coldef.coltype}/td
 /tr
   /table
   }- Hide quoted text -
 
  - Show quoted text -
 


--~--~-~--~~~---~--~~
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] reCaptcha integration

[CodeSlave9000]

Hi - I think I'm following the rules in integrating reCaptcha into a
page, but I'm not seeing anything in the hidden fields when the form
is submitted.  Am I making some kind of assumption I shouldn't be? I'm
rather new to Lift (and web development), so something on the simple
example side would probably be best understood.

Here's some stuff I have:
(in html form)
script type='text/javascript' src='https://api-secure.recaptcha.net/
challenge?k=code here'
/script

noscript
iframe 
src=https://api-secure.recaptcha.net/noscript?k=code
here height=300 width=500 frameborder=0/iframebr/
textarea name=recaptcha_challenge_field rows=3 
cols=40
/textarea
u:captcha/
!-- input type=hidden 
name=recaptcha_response_field
value=manual_challenge/ --
/noscript

And in my snippet, the captcha is bound to:
captcha - SHtml.text(model.captcha.value, model.captcha.value = _,
type - hidden, name - recaptcha_response_field),

model.captcha.value is always empty after form submission.  Nothing
fancy here - just a regular form.
Thanks,
Chris



--~--~-~--~~~---~--~~
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: reCaptcha integration

[CodeSlave9000]

replying to myself a bit here - starting to figure some of this out:

  Turns out it doesn't submit the values in the form, but rather as
parameters to the submission.  I see I can get at those through
  S.param(recaptcha_challenge_field), etc.   This returns a Box
(Full), which I now need to figure out...  I suspect I need to do some
kind of matching on it...

On Oct 20, 12:09 pm, CodeSlave9000 ccebelen...@gmail.com wrote:
 Hi - I think I'm following the rules in integrating reCaptcha into a
 page, but I'm not seeing anything in the hidden fields when the form
 is submitted.  Am I making some kind of assumption I shouldn't be? I'm
 rather new to Lift (and web development), so something on the simple
 example side would probably be best understood.

 Here's some stuff I have:
 (in html form)
 script type='text/javascript' src='https://api-secure.recaptcha.net/
 challenge?k=code here'
                 /script

                 noscript
                         iframe 
 src=https://api-secure.recaptcha.net/noscript?k=code
 here height=300 width=500 frameborder=0/iframebr/
                         textarea name=recaptcha_challenge_field rows=3 
 cols=40
                         /textarea
                         u:captcha/
                         !-- input type=hidden 
 name=recaptcha_response_field
 value=manual_challenge/ --
                 /noscript

 And in my snippet, the captcha is bound to:
 captcha - SHtml.text(model.captcha.value, model.captcha.value = _,
 type - hidden, name - recaptcha_response_field),

 model.captcha.value is always empty after form submission.  Nothing
 fancy here - just a regular form.
 Thanks,
 Chris

--~--~-~--~~~---~--~~
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: lift:bind-at get warnings for every request

[Marius]

Yup please file a ticket. I think Derek worked on this a while ago.
Derek, please correct me if I'm wrong

Br's,
Marius

On Oct 20, 5:16 pm, Ross Mellgren dri...@gmail.com wrote:
 I encountered these and sent a message to the list last week or so. I  
 didn't hear anything back, maybe the best route is to file an issue?

 http://github.com/dpp/liftweb/issues

 -Ross

 On Oct 20, 2009, at 5:30 AM, night_stalker wrote:



  Hi all.
  When using lift:bind-at, the result page is fine as I wished,
  yet these warnings run into the log for every request:

  WARN - Unused binding values for lift:bind: content, main
  WARN - Unused binding values for lift:bind: sidebar, main
  WARN - Unused binding values for lift:bind: sidebar

  Am I missing something, or, can I disable these warnings?
  The lift version is 1.1-M6, template code are like below:

  
  templates-hidden/someLayout.html

  ...begin stuff
  lift:bind name=sidebar/
  ...between stuff
  lift:bind name=content/
  ...end stuff

  
  somePage.html

  lift:surround with=someLayout
   lift:bind-at name=sidebar
     ...sidebar stuff
   /lift:bind-at
   lift:bind-at name=content
     ...content stuff
   /lift:bind-at
  /lift:surround
--~--~-~--~~~---~--~~
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: lift:bind-at get warnings for every request

[Ross Mellgren]

Here's the link to my previous report -- I did some code review when  
looking at it last time, in case it's helpful for anyone.

http://groups.google.com/group/liftweb/browse_thread/thread/c40316267412460b/16c405be378566a0

-Ross

On Oct 20, 2009, at 1:13 PM, Marius wrote:


 Yup please file a ticket. I think Derek worked on this a while ago.
 Derek, please correct me if I'm wrong

 Br's,
 Marius

 On Oct 20, 5:16 pm, Ross Mellgren dri...@gmail.com wrote:
 I encountered these and sent a message to the list last week or so. I
 didn't hear anything back, maybe the best route is to file an issue?

 http://github.com/dpp/liftweb/issues

 -Ross

 On Oct 20, 2009, at 5:30 AM, night_stalker wrote:



 Hi all.
 When using lift:bind-at, the result page is fine as I wished,
 yet these warnings run into the log for every request:

 WARN - Unused binding values for lift:bind: content, main
 WARN - Unused binding values for lift:bind: sidebar, main
 WARN - Unused binding values for lift:bind: sidebar

 Am I missing something, or, can I disable these warnings?
 The lift version is 1.1-M6, template code are like below:

 
 templates-hidden/someLayout.html

 ...begin stuff
 lift:bind name=sidebar/
 ...between stuff
 lift:bind name=content/
 ...end stuff

 
 somePage.html

 lift:surround with=someLayout
  lift:bind-at name=sidebar
...sidebar stuff
  /lift:bind-at
  lift:bind-at name=content
...content stuff
  /lift:bind-at
 /lift:surround
 


--~--~-~--~~~---~--~~
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: Including the class name in the JSON field

[Joni Freeman]

Hi,

Yes I'll put these to Review Board soon. I just add some
documentation, rerun serialization benchmark and do a little bit
testing.
Unless someone wants to discuss details/alternatives/etc more...

Cheers Joni

On 20 loka, 18:22, Derek Chen-Becker dchenbec...@gmail.com wrote:
 Are you putting these changes in Review Board, or is this still experimental
 work?

 Derek

 On Mon, Oct 19, 2009 at 9:02 AM, Joni Freeman freeman.j...@gmail.comwrote:



  Added a way to change how 'type hints' are processed. The default is
  NoTypeHints which will never output 'jsonClass' field. Then there's
  ShortTypeHints and FullTypeHints.

  implicit val formats = Serialization.formats(ShortTypeHints(classOf
  [Fish] :: classOf[Dog] :: Nil))

  - { jsonClass:Fish, ... }

  implicit val formats = Serialization.formats(FullTypeHints(classOf
  [Animal] :: Nil))

  - { jsonClass:com.example.Fish, ... }

  TypeHints trait can be used to reduce couplings (as suggested by
  Steve).

  Cheers Joni

  On 18 loka, 23:46, Joni Freeman freeman.j...@gmail.com wrote:
   There's now some support to deserialize parameterized types in that
   experimental branch. For instance, these all work:

     implicit val formats = Serialization.formats(TypeHints(classOf
   [Animal] :: Nil))

     case class Animals(animals: List[Animal])
     trait Animal
     case class Dog(name: String) extends Animal
     case class Fish(weight: Double) extends Animal

     case class Objs(objects: List[Obj[_]])
     case class Obj[A](a: A)

     val animals = Animals(Dog(pluto) :: Fish(1.2) :: Dog(devil) ::
   Nil)
     val ser = swrite(animals)
     read[Animals](ser) mustEqual animals

     val objs = Objs(Obj(Fish(1.2)) :: Obj(Dog(pluto)) :: Nil)
     val ser = swrite(objs)
     read[Objs](ser) mustEqual objs

     val t: (Animal, Animal) = (Fish(1.5), Dog(pluto))
     val ser = swrite(t)
     read[(Animal, Animal)](ser) mustEqual t

   The first line (implicit val formats ...) configures the serialization
   to output type hint (jsonClass field) for all instances of class
   Animal. This is required since above examples use Animal's in
   polymorphic way. Comments?

   Cheers Joni

   On 18 loka, 01:27, David Pollak feeder.of.the.be...@gmail.com wrote:

On Sat, Oct 17, 2009 at 7:54 AM, Joni Freeman freeman.j...@gmail.com
  wrote:

 I've been thinking this feature today a bit too. Marius raises an
 important point. Adding type information and more complex
 serialization scheme will introduce couplings, making it for instance
 more difficult to deserializeJSONusing a different language or
 toolkit. On a positive side, we might get support for other
 parameterized types too (tuples for instance).

 I pushed an experimental branch (joni_issue_108) which contains
 serialization part of this feature (the easy part really). It adds
 'jsonClass' field to objects.

  case class Animals(animals: List[Animal])
  trait Animal
  case class Dog(name: String) extends Animal
  case class Fish(weight: Double) extends Animal

  scala write(Animals(Dog(pluto) :: Fish(1.2) :: Dog(devil) ::
 Nil))
  res0: String = {jsonClass:Animals,animals:

  [{jsonClass:Dog,name:pluto},{jsonClass:Fish,weight:1.2},
 {jsonClass:Dog,name:devil}]}

 Possible actions:

 * Do not support parameterized types (status quo)

  + Simple scheme, easy to serialize in language agnostic way
  - Limited

I like this option.  I'm not looking for a full Java serialization
  style
solution.  But having hints as to the type of the particularJSONobject
would be helpful.  Being able to register a jsonClass - Scala class
deserializer makes sense.  Being able to specify a Scala class - class
  name
is a good thing (with the default being the actual class name without
  the
package).

 * Add full type information when serializing/deserializing

  + Opens possibility to deserialize polymorphic types
  + Deserialization can be done without any explicit type information
 (read(...) vs. read[ExpectedType](...))
  - Introduces couplings
  - This is still not a generic serialization solution, there's still
 a lot of Scala classes which can't be deserialized

 * Support both schemes

  + Moar choice
  - Choice it not necessarily a good thing (adds complexity etc.)

 Cheers Joni

 On 17 loka, 11:40, Marius marius.dan...@gmail.com wrote:
  Hmmm ... I wonder if heterogeneous lists should be supported. I
  also
  wonder if type knowledge inJSONis a good thing to do as it seems to
  me that we're bringing knowledge from another domain creating
  couplings. I'm not sure if there is a different way to solve this
  ...
  it just doesn't feel completely right to me ... but this doesn't
  necessarily mean it is not right :)

  Br's,
  Marius

  On Oct 15, 1:47 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:

   Folks,
 

[Lift] Re: javascript with an ajaxbutton

[Marius]

I was hoping to see something minimalistic and isolated so I can
quickly try it out.

I'm not sure what you do with redirect(/workflow/claims)  but from
Ajax function you should probably use JsCmd.RedirectTo ..

Hopefully I'll have some time this weekend to play with tinyMCE

Br's,
Marius

On Oct 19, 10:57 pm, caw1461 caw1...@gmail.com wrote:
 edit.html:

     script type=text/javascript

     tinyMCE.init({
         // General options
         mode : textareas,
         theme : advanced,
         plugins :
 spellchecker,pagebreak,save,advhr,advimage,advlink,iespell,inlinepopups,insertdatetime,preview,media,searchreplace,print,contextmenu,paste,directionality,noneditable,visualchars,nonbreaking,xhtmlxtras,template,
         theme_advanced_buttons1 :
 styleselect,formatselect,fontselect,fontsizeselect,|,bold,italic,underline,strikethrough,|,justifyleft,justifycenter,justifyright,justifyfull,|,
 hr, bullist,numlist, preview, code,
         theme_advanced_buttons2 : ,
         theme_advanced_buttons3 : ,
         theme_advanced_buttons4 : ,

         submit_patch : false,

         theme_advanced_resizing : true
     });

     // The save function that actually works.

     $.saveFunc = function() { tinyMCE.activeEditor.save() };

     function saveT () {
         console.log(javascript console 1)
         tinyMCE.activeEditor.save()
         console.log(javascript console 2)
     };

     $('#fixed').click(function(e){
         tinyMCE.activeEditor.save()
     });
     /script

     editor:text/
     br/

     !--  NOW WORKS CORRECTLY --
     button id=Save onclick=saveT() class=ui-state-default
 title=Save, only save the html, doesn't mark the claim ready for
 publishging.Save/button

     editor:save1/
     editor:cancel/
     editor:save2/

 //*//

 Workflow.scala:

   SHtml.ajaxForm(
         bind(editor, xhtml,

             text - SHtml.textarea(originalOrEditedFileAsString
 (selectedClaimWorkQueue.open_!.fileName),
                 s = {
                     println(s)
                     saveClaimHtmlToDB(s)
                     saveClaimHtml(s,
 selectedClaimWorkQueue.open_!.fileName)
                     S.notice(Submitted.)
                     redirect(/workflow/claims)
                 } , (style, height: 500px; width:97%), (id,
 mceForm)),

            save - SHtml.ajaxButton(
              Save,
              {() =
                Log.info(Got a 'save' AJAX call)
               saveClaimStatus(EDITED)
               S.notice(Saved.)
               redirect(/workflow/claims)
             }, (type, submit),(class, ui-state-default ),
 (title, Save, only save the html, does not mark the claim ready for
 publishging.), (id, fixed)),
            save1 - SHtml.ajaxButton(

              Fixed,
               { () = {
                 println(Fixed scala/lift.);
                 saveClaimStatus(FIXED);
                 JsRaw($.saveFunc();).cmd);
                 }
               }, (class, ui-state-default ), (title, Save and
 marks the claim ready for publishing.), (id, fixed)),
             save2 - SHtml.ajaxButton(
                 yes, () = {JsRaw($.saveFunc();).cmd })))

     }

 I'm already importing both of those so that isn't the problem.  If I
 put a % (onclick - saveT()) on the button, it saves the way I
 want it to, but it does not do any of the println or saveClaimStatus
 calls.  I just want it to do both.

 On Oct 19, 3:43 pm, Marius marius.dan...@gmail.com wrote:

  I think with an

  import net.liftweb.http.js._
  import JsCmds._

  the compile problem should go away as there is an implicit defined
  there. But this is not important.

  Can you send a minimalistic code example that reflects the
  problem? ... including the template and Scala code.

  Br's,
  Marius

  On Oct 19, 9:48 pm, caw1461 caw1...@gmail.com wrote:

   My saveClaimSatus() function saves the passed value to the
   database.
   Firebug is not giving me any errors and prints the line to the
   console.

   The order in which the two updates happen is important because I need
   the status updated before the form is saved.

   I am using two different versions of saving to keep a temporary save
   and then a finalized For Publish version.

   so I need both of them to save the form, which i was trying to use the
   saveFunc to do.

   and removing the .cmd seems to give a syntax errors:

   E:\patentTracker3\prospective_claims_ver_br\patentTrackerUi\src\main
   \scala\com\trlr\binpr\snippet\Workflow.scala:473: error: overloaded
   method value ajaxButton with alternatives (String,() =
   net.liftweb.http.js.JsCmd,(String, String)*)scala.xml.Elem and
   (scala.xml.NodeSeq,() = net.liftweb.http.js.JsCmd,(String, String)*)
   scala.xml.Elem cannot be applied to (java.lang.String,() =
   net.liftweb.http.js.JE.JsRaw,(java.lang.String, java.lang.String),
   (java.lang.String, java.lang.String),(java.lang.String,
   java.lang.String))
              save1 - 

[Lift] Re: net.liftweb.widgets.autocomplete in version 1.1-M6

[Naftoli Gugenheim]

Does it help to change map to flatMap?

On Tue, Oct 20, 2009 at 7:15 AM, Tweek d.sztwio...@gmail.com wrote:


 Hi,
 Previously i was working on version 1.1-M3 of lift framework and i
 used autocomplete widget by override _toForm method in my Test.scala
 file. It was something like that:

 object Test extends Test with KeyedMetaMapper[Long, Test] with CRUDify
 [Long,Test] {
 (...)
 }

 class Test extends KeyedMapper[Long, Test] {

 (...)

object TestTable extends MappedLongForeignKey(this, TestTable) {
def handleSubmit( string : String) = {

}

override def _toForm = Full( AutoComplete(, (current, limit)
 = {
TestTable.findAll.toList.map(d = (d.name.is)) },
 handleSubmit ))

}

 (...)

 }

 But now, after upgrade lift to version 1.1-M6, i'm getting this error:

   error: type mismatch;
   found   : scala.xml.NodeSeq
   required: scala.xml.Elem
   override def _toForm = Full( AutoComplete(, (current,
 limit) = {
^
   one error found.


 I can't find way to fix this problem. Could Anyone help me?

 Thanks and regards

 


--~--~-~--~~~---~--~~
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 use JqKeypress?

[harryh]

Yes, but then how can I distinguish back on the server whether func is
being executed because of a blur (in which case I don't really want to
do anything) or because of a keypress of enter (in which case I want
to perform an action as if the go button had been pressed).

-harryh

On Oct 20, 11:27 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
 I think that the ajaxText already handles an enter key as field
 submission. Here's the code that defines an ajaxText field:

    1.   private def
     ajaxText_*(value: String, jsFunc: Box[Call], func: AFuncHolder,
 attrs: (String, String)*): Elem = {
    2.     val raw = (funcName: String, value:String) = JsRaw('
     +funcName + =' + encodeURIComponent( + value + .value))
    3.     val key = formFuncName
    4.
    5.     fmapFunc(func){
    6.       funcName =
    7.       (attrs.foldLeft(input type=text value={value}/)(_ % _)) %
    8.       (onkeypress - liftUtils.lift_blurIfReturn(event)) %
    9.       (onblur - (jsFunc match {
    10.             case Full(f) = JsCrVar(key, JsRaw(this
    ))  deferCall(raw(funcName, key), f)
    11.             case _ = makeAjaxCall(raw(funcName, this))
    12.           })
    13.       )
    14.     }
    15.   }

 Note the onkeypress and onblur event handlers. If you need to do some
 extra handling on the client side, you can provide the jsFunc parameter
 which will be used to submit the ajax call.

 Derek

 On Mon, Oct 19, 2009 at 6:13 PM, harryh har...@gmail.com wrote:

  It seems like I ought to be able to use JqKeypress so that if a user
  presses enter when a text input has focus an associated ajaxButton is
  submitted.  I can't get it to work though.  Help?

  Basically I have a bunch of little form like so

  [      text input       ] [go!]

  that I want to submit (ajax style) when the user presses enter.

  -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: reCaptcha integration

[Naftoli Gugenheim]

S.param(recaptcha_challenge_field) match {  case Full(value) = // work
with the value of 'value'
  case _ = // deal with the fact that there's no result.
}

On Tue, Oct 20, 2009 at 12:49 PM, CodeSlave9000 ccebelen...@gmail.comwrote:


 replying to myself a bit here - starting to figure some of this out:

  Turns out it doesn't submit the values in the form, but rather as
 parameters to the submission.  I see I can get at those through
  S.param(recaptcha_challenge_field), etc.   This returns a Box
 (Full), which I now need to figure out...  I suspect I need to do some
 kind of matching on it...

 On Oct 20, 12:09 pm, CodeSlave9000 ccebelen...@gmail.com wrote:
  Hi - I think I'm following the rules in integrating reCaptcha into a
  page, but I'm not seeing anything in the hidden fields when the form
  is submitted.  Am I making some kind of assumption I shouldn't be? I'm
  rather new to Lift (and web development), so something on the simple
  example side would probably be best understood.
 
  Here's some stuff I have:
  (in html form)
  script type='text/javascript' src='https://api-secure.recaptcha.net/
  challenge?k=code here'
  /script
 
  noscript
  iframe src=
 https://api-secure.recaptcha.net/noscript?k=code
  here height=300 width=500 frameborder=0/iframebr/
  textarea name=recaptcha_challenge_field
 rows=3 cols=40
  /textarea
  u:captcha/
  !-- input type=hidden
 name=recaptcha_response_field
  value=manual_challenge/ --
  /noscript
 
  And in my snippet, the captcha is bound to:
  captcha - SHtml.text(model.captcha.value, model.captcha.value = _,
  type - hidden, name - recaptcha_response_field),
 
  model.captcha.value is always empty after form submission.  Nothing
  fancy here - just a regular form.
  Thanks,
  Chris

 


--~--~-~--~~~---~--~~
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: reCaptcha integration

[David Pollak]

For a little more on Box (and Option), see
http://blog.lostlake.org/index.php?/archives/50-The-Scala-Option-class-and-how-lift-uses-it.html

On Tue, Oct 20, 2009 at 9:49 AM, CodeSlave9000 ccebelen...@gmail.comwrote:


 replying to myself a bit here - starting to figure some of this out:

  Turns out it doesn't submit the values in the form, but rather as
 parameters to the submission.  I see I can get at those through
  S.param(recaptcha_challenge_field), etc.   This returns a Box
 (Full), which I now need to figure out...  I suspect I need to do some
 kind of matching on it...

 On Oct 20, 12:09 pm, CodeSlave9000 ccebelen...@gmail.com wrote:
  Hi - I think I'm following the rules in integrating reCaptcha into a
  page, but I'm not seeing anything in the hidden fields when the form
  is submitted.  Am I making some kind of assumption I shouldn't be? I'm
  rather new to Lift (and web development), so something on the simple
  example side would probably be best understood.
 
  Here's some stuff I have:
  (in html form)
  script type='text/javascript' src='https://api-secure.recaptcha.net/
  challenge?k=code here'
  /script
 
  noscript
  iframe src=
 https://api-secure.recaptcha.net/noscript?k=code
  here height=300 width=500 frameborder=0/iframebr/
  textarea name=recaptcha_challenge_field
 rows=3 cols=40
  /textarea
  u:captcha/
  !-- input type=hidden
 name=recaptcha_response_field
  value=manual_challenge/ --
  /noscript
 
  And in my snippet, the captcha is bound to:
  captcha - SHtml.text(model.captcha.value, model.captcha.value = _,
  type - hidden, name - recaptcha_response_field),
 
  model.captcha.value is always empty after form submission.  Nothing
  fancy here - just a regular form.
  Thanks,
  Chris

 



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

[Derek Chen-Becker]

With the current function you can't. I can see a need for having the ajax
fired on key press and not on blur, so please open an issue and reference
this conversation.

Derek

On Tue, Oct 20, 2009 at 1:05 PM, harryh har...@gmail.com wrote:


 Yes, but then how can I distinguish back on the server whether func is
 being executed because of a blur (in which case I don't really want to
 do anything) or because of a keypress of enter (in which case I want
 to perform an action as if the go button had been pressed).

 -harryh

 On Oct 20, 11:27 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
  I think that the ajaxText already handles an enter key as field
  submission. Here's the code that defines an ajaxText field:
 
 1.   private def
  ajaxText_*(value: String, jsFunc: Box[Call], func: AFuncHolder,
  attrs: (String, String)*): Elem = {
 2. val raw = (funcName: String, value:String) = JsRaw('
  +funcName + =' + encodeURIComponent( + value + .value))
 3. val key = formFuncName
 4.
 5. fmapFunc(func){
 6.   funcName =
 7.   (attrs.foldLeft(input type=text value={value}/)(_ % _)) %
 8.   (onkeypress - liftUtils.lift_blurIfReturn(event)) %
 9.   (onblur - (jsFunc match {
 10. case Full(f) = JsCrVar(key, JsRaw(this
 ))  deferCall(raw(funcName, key), f)
 11. case _ = makeAjaxCall(raw(funcName, this))
 12.   })
 13.   )
 14. }
 15.   }
 
  Note the onkeypress and onblur event handlers. If you need to do some
  extra handling on the client side, you can provide the jsFunc parameter
  which will be used to submit the ajax call.
 
  Derek
 
  On Mon, Oct 19, 2009 at 6:13 PM, harryh har...@gmail.com wrote:
 
   It seems like I ought to be able to use JqKeypress so that if a user
   presses enter when a text input has focus an associated ajaxButton is
   submitted.  I can't get it to work though.  Help?
 
   Basically I have a bunch of little form like so
 
   [  text input   ] [go!]
 
   that I want to submit (ajax style) when the user presses enter.
 
   -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] Menu entry to perform action then redirect

[Naftoli Gugenheim]

Could someone give an example of a Sitemap menu entry that performs an
action and then redirects?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] S.uri not including query params

[Naftoli Gugenheim]

Is S.uri supposed to return the part of the URL after '?'?

--~--~-~--~~~---~--~~
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: Menu entry to perform action then redirect

[David Pollak]

Loc(Feedback, List(feedback), Feedback, Loc.EarlyResponse(() =
{println(I like to redirect); S.redirectTo(S.referer openOr /)})

On Tue, Oct 20, 2009 at 2:50 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:

 Could someone give an example of a Sitemap menu entry that performs an
 action and then redirects?Thanks.


 



-- 
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: S.uri not including query params

[David Pollak]

On Tue, Oct 20, 2009 at 2:48 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:

 Is S.uri supposed to return the part of the URL after '?'?


No


 



-- 
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: Menu entry to perform action then redirect

[harryh]

Menu(Loc(logout, List(logout), logout, Template(() =
{ User.logout }), ifLoggedIn)) ::

object User {
  def logout = {
logUserOut
S.redirectTo(/)
  }
}

On Oct 20, 5:50 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 Could someone give an example of a Sitemap menu entry that performs an
 action and then redirects?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] Rolling out the new Lift Actors code

[David Pollak]

Folks,

I've just pushed the completed Lift Actor code to the dpp_wip_actorize
branch.  Jonas and I coordinated on the Actor API and Akka Actors will use
the same basic trait so Akka Actors could be used to power Lift's Comet.

I am ready to push this code to SNAPSHOT.  When I do this, there will be
breaking changes to all Lift apps (basically, you'll have to import
net.liftweb.base._)

Does anyone have a timetable for this push?  I'd like to have at least a
week of solid testing before we do Milestone 7 (currently scheduled for
November 4th).

Please let me know your thoughts.

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: net.liftweb.widgets.autocomplete in version 1.1-M6

[David Pollak]

On Tue, Oct 20, 2009 at 4:15 AM, Tweek d.sztwio...@gmail.com wrote:


 Hi,
 Previously i was working on version 1.1-M3 of lift framework and i
 used autocomplete widget by override _toForm method in my Test.scala
 file. It was something like that:

 object Test extends Test with KeyedMetaMapper[Long, Test] with CRUDify
 [Long,Test] {
 (...)
 }

 class Test extends KeyedMapper[Long, Test] {

 (...)

object TestTable extends MappedLongForeignKey(this, TestTable) {
def handleSubmit( string : String) = {

}

override def _toForm = Full( AutoComplete(, (current, limit)
 = {
TestTable.findAll.toList.map(d = (d.name.is)) },
 handleSubmit ))

}

 (...)

 }

 But now, after upgrade lift to version 1.1-M6, i'm getting this error:

   error: type mismatch;
   found   : scala.xml.NodeSeq
   required: scala.xml.Elem
   override def _toForm = Full( AutoComplete(, (current,
 limit) = {
^
   one error found.


 I can't find way to fix this problem. Could Anyone help me?


It looks like a defect.  Please open a ticket at
http://github.com/dpp/liftweb/issues



 Thanks and regards

 



-- 
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] Trouble With JPA Book Example

[AndyM]

I'm having trouble doing an mvn install on the JPA example from the
book...

 mvn archetype:generate \
-DarchetypeRepository=http://scala-tools.org/repo-snapshots \
-DarchetypeGroupId=net.liftweb \
-DarchetypeArtifactId=lift-archetype-jpa-basic \
-DarchetypeVersion=1.1-SNAPSHOT \
-DgroupId=com.foo.jpaweb \
-DartifactId=JPADemo \
-Dversion=1.0-SNAPSHOT

cd JPADemo
mvn install

org.apache.maven.reactor.MavenExecutionException: The POM expression: $
{scala.version} could not be evaluated. Reason: Expression value '$
{scala.version}' references itself in 'com.foo.jpaweb:JPADemo:pom:1.0-
SNAPSHOT'. for project com.foo.jpaweb:JPADemo at /home/amast/lift/
bookexample/JPADemo/pom.xml
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
 [deleted for brevity]
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: The
POM expression: ${scala.version} could not be evaluated. Reason:
Expression value '${scala.version}' references itself in
'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'. for project
com.foo.jpaweb:JPADemo at /home/amast/lift/bookexample/JPADemo/pom.xml
at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal
(DefaultMavenProjectBuilder.java:882)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal
(DefaultMavenProjectBuilder.java:506)
... [deleted for brevity]
Caused by:
org.apache.maven.project.interpolation.ModelInterpolationException:
The POM expression: ${scala.version} could not be evaluated. Reason:
Expression value '${scala.version}' references itself in
'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'.
at
org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolateInternal
(RegexBasedModelInterpolator.java:172)
...[deleted for brevity]


Any help would be greatly appreciated.

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

[Derek Chen-Becker]

Or, if you're OK with it, I could just make a lift-joda module that has the
traits. That would also keep the Joda Time dependency out of the main lift
modules.

On Tue, Oct 20, 2009 at 5:48 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 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 names) as java.util.Date.  How is anything
 more default than that?


 My primary concern with this approach is that it makes changing between the
 two implementations something that requires a global search and replace on
 one or more method names, whereas having two different implementation traits
 means that generally I should be able to just change the import and the code
 will work. A secondary (minor) concern is that having method names reflect
 the underlying implementation details goes against my aesthetics.


 It's an interesting difference between an OO vs. non-OO.  In the
 implementation I created, there choice of one or the other is made based on
 singleton methods invoked.  This allows mixing both in the same code simply
 by invoking now or jtNow.


 I would argue that it's not a common case where you would want to use both
 libraries, particularly when Joda's DateTime has an explicit toDate on it
 that returns a java.util.Date. There are similar methods to return Calendar
 and TimeZone instances as needed. These are simple methods to use directly,
 or it's easy to create a view that handles this automatically.

 I'm unclear why this is not possible.  We can add a DSL for manipulating
 JodaTime without breaking anything we have.  The TimeSpan class simply gets
 enhanced to deal with additional stuff and maybe uses JodaTime under the
 covers.


 The underpinning of the current DSL is the TimeSpan class. Joda Time
 already has a time interval class corresponding to TimeSpan called Duration,
 but the more proper class to use is actually Period. Period is premised not
 on ms duration but rather on field deltas, which allows it to properly
 handle DST. Modifying the current DSL to work for Duration and Period via
 TimeSpan is just going to end up with a lot of redundant code, when a
 Joda-only DSL would be cleaner and more in line with how you would want to
 use Joda Time.


 They have that now with the implementation I did on your branch.


 Like I said before, I have a strong preference for the OO approach and
 being able to change impls by changing the import rather than having to
 change methods all over the place. If you really feel strongly that we can't
 have a separate trait in Lift, I can just create a different artifact in my
 own repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and
 JodaTimeHelpers traits there.

 Cheers,

 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: Trouble With JPA Book Example

[AndyM]

Still getting the same issue, with

mvn -U archetype:generate  \
-DarchetypeRepository=http://scala-tools.org/repo-snapshots \
-DarchetypeGroupId=net.liftweb \
-DarchetypeArtifactId=lift-archetype-jpa-basic \
-DarchetypeVersion=1.1-SNAPSHOT \
-DgroupId=com.foo.jpaweb \
-DartifactId=JPADemo \
-Dversion=1.0-SNAPSHOT




On Oct 20, 7:58 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 For some reason the pom.xml files in the JPA archetypes referred to lift M4
 rather than SNAPSHOT.  I've pushed a change.  Once the build 
 (http://hudson.scala-tools.org/job/Lift/1298/) is done, try re-executing
 your mvn command (make sure you do a mvn -U to pull the latest).

 To the committers - sorry for not going through review board on this one,
 but it was a clear problem with a clear fix (kind of like pushing a fix to a
 type-o in documentation)



 On Tue, Oct 20, 2009 at 4:28 PM, AndyM andrewdm...@gmail.com wrote:

  I'm having trouble doing an mvn install on the JPA example from the
  book...

   mvn archetype:generate \
  -DarchetypeRepository=http://scala-tools.org/repo-snapshots\
  -DarchetypeGroupId=net.liftweb \
  -DarchetypeArtifactId=lift-archetype-jpa-basic \
  -DarchetypeVersion=1.1-SNAPSHOT \
  -DgroupId=com.foo.jpaweb \
  -DartifactId=JPADemo \
  -Dversion=1.0-SNAPSHOT

  cd JPADemo
  mvn install

  org.apache.maven.reactor.MavenExecutionException: The POM expression: $
  {scala.version} could not be evaluated. Reason: Expression value '$
  {scala.version}' references itself in 'com.foo.jpaweb:JPADemo:pom:1.0-
  SNAPSHOT'. for project com.foo.jpaweb:JPADemo at /home/amast/lift/
  bookexample/JPADemo/pom.xml
         at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
          [deleted for brevity]
         at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
  Caused by: org.apache.maven.project.InvalidProjectModelException: The
  POM expression: ${scala.version} could not be evaluated. Reason:
  Expression value '${scala.version}' references itself in
  'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'. for project
  com.foo.jpaweb:JPADemo at /home/amast/lift/bookexample/JPADemo/pom.xml
         at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal
  (DefaultMavenProjectBuilder.java:882)
         at

  org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal
  (DefaultMavenProjectBuilder.java:506)
         ... [deleted for brevity]
  Caused by:
  org.apache.maven.project.interpolation.ModelInterpolationException:
  The POM expression: ${scala.version} could not be evaluated. Reason:
  Expression value '${scala.version}' references itself in
  'com.foo.jpaweb:JPADemo:pom:1.0-SNAPSHOT'.
         at

  org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolateInternal
  (RegexBasedModelInterpolator.java:172)
  ...[deleted for brevity]

  Any help would be greatly appreciated.

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning Scalahttp://www.apress.com/book/view/1430219890
 Follow me:http://twitter.com/dpp
 Surf the harmonics

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

[Lift] Re: How to disable a textfield

[sunanda]

Thanks Tim

On Oct 20, 6:02 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 Change - to -%

 Doing this preserves any element attributes, for example:
 disabled=disabled

 Cheers, Tim

 On Oct 20, 6:30 am, sunanda sunanda.pa...@gmail.com wrote:



  Hi,
  I need to disable all the textfield and then want to enable the fields
  for editing on click of a button.
  How can i do this with the following sample  code.
  Thanks
  Regards,
  Sunanda.

  bind(add,html,
                       displayname-coldef.displayname.toForm,
                       columntype-coldef.coltype.toForm,
                       sourceview-coldef.sourceview.toForm)- Hide quoted 
  text -

 - Show quoted text -
--~--~-~--~~~---~--~~
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?

[Naftoli Gugenheim]

I agree with this.
My understanding is that the goal is that Lift should use Joda for its time 
functions rather than java.util. 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 names) as java.util.Date.  How is anything
 more default than that?


My primary concern with this approach is that it makes changing between the
two implementations something that requires a global search and replace on
one or more method names, whereas having two different implementation traits
means that generally I should be able to just change the import and the code
will work. A secondary (minor) concern is that having method names reflect
the underlying implementation details goes against my aesthetics.


 It's an interesting difference between an OO vs. non-OO.  In the
 implementation I created, there choice of one or the other is made based on
 singleton methods invoked.  This allows mixing both in the same code simply
 by invoking now or jtNow.


I would argue that it's not a common case where you would want to use both
libraries, particularly when Joda's DateTime has an explicit toDate on it
that returns a java.util.Date. There are similar methods to return Calendar
and TimeZone instances as needed. These are simple methods to use directly,
or it's easy to create a view that handles this automatically.

I'm unclear why this is not possible.  We can add a DSL for manipulating
 JodaTime without breaking anything we have.  The TimeSpan class simply gets
 enhanced to deal with additional stuff and maybe uses JodaTime under the
 covers.


The underpinning of the current DSL is the TimeSpan class. Joda Time already
has a time interval class corresponding to TimeSpan called Duration, but the
more proper class to use is actually Period. Period is premised not on ms
duration but rather on field deltas, which allows it to properly handle DST.
Modifying the current DSL to work for Duration and Period via TimeSpan is
just going to end up with a lot of redundant code, when a Joda-only DSL
would be cleaner and more in line with how you would want to use Joda Time.


 They have that now with the implementation I did on your branch.


Like I said before, I have a strong preference for the OO approach and being
able to change impls by changing the import rather than having to change
methods all over the place. If you really feel strongly that we can't have a
separate trait in Lift, I can just create a different artifact in my own
repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and
JodaTimeHelpers traits there.

Cheers,

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: S.uri not including query params

[Naftoli Gugenheim]

Then my addition to MetaMegaProtoUser of loginRedirect has a bug, because 
loginFirst sets it based on S.uri.
Since I'm not usually around an internet connection, I won't be able to go 
through filing a ticket, putting a diff on Review Board, and pushing it, in any 
small amount of time.


-
David Pollakfeeder.of.the.be...@gmail.com wrote:

On Tue, Oct 20, 2009 at 2:48 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:

 Is S.uri supposed to return the part of the URL after '?'?


No


 



-- 
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: css, javascript, images are all in the WEB-INF ?

[David Pollak]

On Tue, Oct 20, 2009 at 6:20 PM, Neil.Lv anim...@gmail.com wrote:


 Hi all,

   I have a newbie issue about the path .

   The css, javascript, images folder are all in the WEB-INF or you
 can specify the path ?


WEB-INF is where the stuff that's not going to be served by the container
lives.  Put images in /images, CSS in /css, etc. or whatever layout you
want.



   Thanks for any suggestion!

 Cheers,
  Neil

 



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

[David Pollak]

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


 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 names) as java.util.Date.  How is
 anything
  more default than that?
 

 My primary concern with this approach is that it makes changing between the
 two implementations something that requires a global search and replace on
 one or more method names, whereas having two different implementation
 traits
 means that generally I should be able to just change the import and the
 code
 will work. A secondary (minor) concern is that having method names reflect
 the underlying implementation details goes against my aesthetics.


  It's an interesting difference between an OO vs. non-OO.  In the
  implementation I created, there choice of one or the other is made based
 on
  singleton methods invoked.  This allows mixing both in the same code
 simply
  by invoking now or jtNow.
 

 I would argue that it's not a common case where you would want to use both
 libraries, particularly when Joda's DateTime has an explicit toDate on it
 that returns a java.util.Date. There are similar methods to return Calendar
 and TimeZone instances as needed. These are simple methods to use directly,
 or it's easy to create a view that handles this automatically.

 I'm unclear why this is not possible.  We can add a DSL for manipulating
  JodaTime without breaking anything we have.  The TimeSpan class simply
 gets
  enhanced to deal with additional stuff and maybe uses JodaTime under the
  covers.
 

 The underpinning of the current DSL is the TimeSpan class. Joda Time
 already
 has a time interval class corresponding to TimeSpan called Duration, but
 the
 more proper class to use is actually Period. Period is premised not on ms
 duration but rather on field deltas, which allows it to properly handle
 DST.
 Modifying the current DSL to work for Duration and Period via TimeSpan is
 just going to end up with a lot of redundant code, when a Joda-only DSL
 would be cleaner and more in line with how you would want to use Joda Time.


  They have that now with the implementation I did on your branch.
 

 Like I said before, I have a strong preference for the OO approach and
 being
 able to change impls by changing the import rather than having to change
 methods all over the place. If you really feel strongly that we can't have
 a
 separate trait in Lift, I can just create a different artifact in my own
 repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and
 JodaTimeHelpers traits there.

 Cheers,

 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 

[Lift] html not being evalutated

[jack]

I have the following method display. source.body has html tags in it
but the actual tags are showing instead of being evaluated. e.g. I'm
seeing things like 'bHey There/b' instead of 'Hey There' in bold.
This method is in a CometActor and is running when the page is
rendered. Am I missing something obvious?

 def display(sources:List[Source]):NodeSeq = {

span id=jooptable
{
   for {source - sources} yield trtd{source.body}/td/tr
}

/table
/span
  }
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---