[Lift] Re: suggestion: strip comments when serving templates

2009-09-23 Thread Jeppe Nejsum Madsen

harryh har...@gmail.com writes:

 I would love to add comments to my templates:

 !-- Put the shiny new feature here as soon as we have time to build
 it --

 that got stripped out before being served to end users.

A few thoughts:

- Would also be nice if all excessive white space were stripped from
  the output (not sure how much this matters if it's gzip'ed)

- In dev mode, I think it's important to maintain a 1-1 mapping between
  what's output in the browser and the source template(s)

/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: Concurrent Web Service Requests?

2009-09-23 Thread Jeppe Nejsum Madsen

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

 I've added code (it's in review board right now) that will automatically
 farm any snippet with the do:lazy='true' attribute set.

 So, lift:foo/ will execute the foo snippet inline.

 lift:foo do:lazy=true/ will execute the foo snippet in parallel and join
 the result back to page before its rendered.

Very nice! In what context is the snippet executed? I assume that
all timeout handling, errors etc should be handled by the snippet just
as in the non-lazy fashion?

/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: suggestion: strip comments when serving templates

2009-09-23 Thread Timothy Perrett

Totally agree Jeppe.

@dpp - what changes did you make? Are they in review board yet?

Cheers, Tim

On 23 Sep 2009, at 07:48, Jeppe Nejsum Madsen wrote:


 harryh har...@gmail.com writes:

 I would love to add comments to my templates:

 !-- Put the shiny new feature here as soon as we have time to build
 it --

 that got stripped out before being served to end users.

 A few thoughts:

 - Would also be nice if all excessive white space were stripped from
  the output (not sure how much this matters if it's gzip'ed)

 - In dev mode, I think it's important to maintain a 1-1 mapping  
 between
  what's output in the browser and the source template(s)

 /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: Concurrent Web Service Requests?

2009-09-23 Thread Naftoli Gugenheim

Could that be changed to lift:concurrent or lift:par etc. (see email on 
scala-user from Marting Odersky mentioned the future use of 'seq' and 'par' in 
concurrent collections)?
Why use a different prefix than everything else built in to lift? And 'lazy' is 
arguably not what's happening.
Thanks.


-
Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


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

 I've added code (it's in review board right now) that will automatically
 farm any snippet with the do:lazy='true' attribute set.

 So, lift:foo/ will execute the foo snippet inline.

 lift:foo do:lazy=true/ will execute the foo snippet in parallel and join
 the result back to page before its rendered.

Very nice! In what context is the snippet executed? I assume that
all timeout handling, errors etc should be handled by the snippet just
as in the non-lazy fashion?

/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: SHtml.a not active when used via innerHtml

2009-09-23 Thread KP

Hello,

Doing that appears not to help the issue. The thing I called
customJSStr above now looks like

document.getElementById('foo').innerHTML = 'lift:a
key=F859002372055OWMbar/lift:a';

(with 's properly handled by encJs), and the behavior appears to be
unchanged. Is there some sort of setup of the lift:a that doesn't
get to take place when I update the page like this, perhaps?

Thanks much,
KP

On Sep 22, 9:55 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Tue, Sep 22, 2009 at 7:49 PM, KP horse.headed.fish@gmail.com wrote:

  Hi all.

  I have essentially the following setup in a website:

  class AjaxTest {
    def render =
       div
          div id=foofoo/div
          {getAjaxForm}
       /div

    def getAjaxForm = SHtml.ajaxForm(
          SHtml.submit(submit, () = ()),
          Run(customJSStr))

    def customJSStr = document.getElementById('foo').innerHTML = ' +
  aStr + ';

 If aStr contains a single or double quote or a non-printable or non-ascii
 character, your expression will fail (it will be invalid JavaScript).

 I would suggest:

 def customJSStr = document.getElementById('foo').innerHTML =  +aStr.encJs
 + ;

 That will properly escape the string as a JavaScript string.







    val aStr = SHtml.a(() = SetHtml(foo, Text(baz)), Text
  (bar)).toString
  }

  when aStr is displayed (with text 'bar'), the link is inactive.

  I'm using Run(customJSStr) instead of SetHtml as, in the actual app,
  the situation is slightly more complicated (and the RHS of the
  assignment operator in the javascript expression has some more stuff
  fetched from the document).

  Note also that if the ajaxForm uses SetHtml() instead of Run() it
  works as expected.

  So the question is -- is there a straightforward explanation for
  what's going on here (I'm still kinda cargo-culting lift).

  And, unconditional upon the answer to the last question, is there a
  way to make aStr a valid, active link (or, I guess, string
  representing one) while retaining the ability to have an arbitrarily
  complex javascript expression in customJSStr (this would actually be
  defined in a separate js file, of course).

  Thanks much,
  KP

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

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



[Lift] The LiftView trait can't work ?

2009-09-23 Thread Neil.Lv

Hi all,

Just I define a class that extends the LiftView trait, but there
is something wrong with this class when i using it.

I wrote some test code like this:

###  code  ###
package com.test.view

import net.liftweb._
import http._

import scala.xml.{NodeSeq}


class Test extends LiftView {
override def dispatch = {
case hello = doTest _
}

def doTest():NodeSeq = {
lift:surround with=default at=content
Time is: {new _root_.java.util.Date}
/lift:surround
}
}
###  code  ###

   Use these links and always get this message The Requested URL /
Test/hello was not found on this server
   http://localhost:8080/Test/hello
   http://localhost:8080/test/hello

   Note: I don't change my Boot class in the  /src/main/scala/
bootstrap/liftweb folder.


   Is there anyone can help ?
   Thanks very much!

--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: suggestion: strip comments when serving templates

2009-09-23 Thread harryh

 - Would also be nice if all excessive white space were stripped from
   the output (not sure how much this matters if it's gzip'ed)

This would be nice as well, but can be a lot more complicated.  GXP (a
templating language I worked on at Google) had pretty awesome
whitespace control that I'm happy to describe in detail if dpp (or
another committer) is interested.  Personally though, I wouldn't
consider this super high priority.

-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: Concurrent Web Service Requests?

2009-09-23 Thread Timothy Perrett

+1

I think naftoli's suggestion is a good one and we should go with
something that carries a better semantic.

Cheers, Tim

On Sep 23, 11:59 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
 Could that be changed to lift:concurrent or lift:par etc. (see email on 
 scala-user from Marting Odersky mentioned the future use of 'seq' and 'par' 
 in concurrent collections)?
 Why use a different prefix than everything else built in to lift? And 'lazy' 
 is arguably not what's happening.
 Thanks.

 -

 Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
 David Pollak feeder.of.the.be...@gmail.com writes:
  I've added code (it's in review board right now) that will automatically
  farm any snippet with the do:lazy='true' attribute set.

  So, lift:foo/ will execute the foo snippet inline.

  lift:foo do:lazy=true/ will execute the foo snippet in parallel and join
  the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet just
 as in the non-lazy fashion?

 /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: The LiftView trait can't work ?

2009-09-23 Thread Timothy Perrett

If you haven't changed boot, then you'll find that they are not wired
up if memory serves...
What are you trying to achieve exactly?

Cheers, Tim



On Sep 23, 9:02 am, Neil.Lv anim...@gmail.com wrote:
 Hi all,

     Just I define a class that extends the LiftView trait, but there
 is something wrong with this class when i using it.

     I wrote some test code like this:

 ###  code  ###
 package com.test.view

 import net.liftweb._
 import http._

 import scala.xml.{NodeSeq}

 class Test extends LiftView {
         override def dispatch = {
                 case hello = doTest _
         }

         def doTest():NodeSeq = {
                 lift:surround with=default at=content
                         Time is: {new _root_.java.util.Date}
                 /lift:surround
         }}

 ###  code  ###

    Use these links and always get this message The Requested URL /
 Test/hello was not found on this server
    http://localhost:8080/Test/hello
    http://localhost:8080/test/hello

    Note: I don't change my Boot class in the  /src/main/scala/
 bootstrap/liftweb folder.

    Is there anyone can help ?
    Thanks very much!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: The LiftView trait can't work ?

2009-09-23 Thread David Pollak
If you're using Lift 1.0.x, the request will silently fail.

If you're using Lift 1.1-x, you will get a helpful error message reminding
you to add the /Test/hello link to your SiteMap in Boot.scala

On Wed, Sep 23, 2009 at 1:02 AM, Neil.Lv anim...@gmail.com wrote:


 Hi all,

Just I define a class that extends the LiftView trait, but there
 is something wrong with this class when i using it.

I wrote some test code like this:

 ###  code  ###
 package com.test.view

 import net.liftweb._
 import http._

 import scala.xml.{NodeSeq}


 class Test extends LiftView {
override def dispatch = {
case hello = doTest _
}

def doTest():NodeSeq = {
lift:surround with=default at=content
Time is: {new _root_.java.util.Date}
/lift:surround
}
 }
 ###  code  ###

   Use these links and always get this message The Requested URL /
 Test/hello was not found on this server
   http://localhost:8080/Test/hello
   http://localhost:8080/test/hello

   Note: I don't change my Boot class in the  /src/main/scala/
 bootstrap/liftweb folder.


   Is there anyone can help ?
   Thanks very much!

 



-- 
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: Autogenerated PKs and MetaMapper

2009-09-23 Thread Thomas Rampelberg

You'd think I could read the only sticky post without getting linked to it!

Let's see if I can clearly explain my use cases. The simplest to
explain is that I'd like to use UUIDs as the primary key of a table.
To do this, I've done something like this:

class MappedStringPrimaryKey[T:Mapper[T]] (
override val fieldOwner: T, override val maxLen: Int)
  extends MappedStringIndex[T](fieldOwner, maxLen)
with LifecycleCallbacks {
  override def writePermission_? = true
  override def dbDisplay_? = true
  override def dbAutogenerated_? = false

  override def fieldCreatorString(
  dbType: DriverType, colName: String): String =
colName+ CHAR(+maxLen+) NOT NULL 
}

class UUIDPrimaryKey[T:Mapper[T]] (
  override val fieldOwner: T) extends MappedStringPrimaryKey[T](
fieldOwner, 16) {
  override def dbDisplay_? = false
  override def dbIndexFieldIndicatesSaved_? = (i_is_! != defaultValue)
  override lazy val defaultValue = {
val uuid = UUID.randomUUID.toString.replaceAll(-, ).elements
(new URLCodec).decode(uuid.zip(uuid).map(x=%+x._1+x._2).mkString)
  }
}

The first problem is that while MappedStringIndex is setup as a
primary key, the field is required to be NOT NULL. Secondly, the
dbIndexFieldIndicatesSaved_? ends up being a little non-intuitive (I
would have expected it to be part of MappedStringIndex as well).

Also, with this use case, I had to make a couple modifications to
MetaMapper itself. The first one:

@@ -884,7 +891,7 @@ trait MetaMapper[A:Mapper[A]] extends
BaseMetaMapper with Mapper[A] {
 mappedColumnInfo(colName) = mf
 mappedColumns(colName) = v
   }
-  if (mf.dbPrimaryKey_?  mf.dbAutogenerated_?) {
+  if (mf.dbPrimaryKey_?) {
 indexMap =
Full(MapperRules.quoteColumnName(mf.dbColumnName)) //
Full(v.getName.toLowerCase)
   }

Without indexMap being defined, if I do something along these lines:

Field.save
Field.save

(save twice in succession) I get a duplicate key value error because
the save call is trying to insert the object again.

The second modification that I made to MetaMapper:

@@ -600,10 +603,13 @@ trait MetaMapper[A:Mapper[A]] extends
BaseMetaMapper with Mapper[A] {
   try {
 if (rs.next) {
   val meta = rs.getMetaData
-  toSave.runSafe {
-findApplier(indexMap.open_!, rs.getObject(1)) match {
-  case Full(ap) = ap.apply(toSave, rs.getObject(1))
-  case _ =
+  if (indexedField(toSave).map(_.dbAutogenerated_?)
+  getOrElse false) {
+toSave.runSafe {
+  findApplier(indexMap.open_!, rs.getObject(1)) match {
+case Full(ap) = ap.apply(toSave, rs.getObject(1))
+case _ =
+  }
 }
   }
   !rs.next

If I don't do this patch, when the object is saved, the value gets
reset from foobar to 1. The database stores it correctly, it's
simply the object that has its attributes wrong.

My other use case is documented below. I'm trying to set the value of
the primary key before submitting. At this point, i_is_! is always
different than the defaultValue and without using the afterSave hook,
the object tries to update instead of insert itself. While this isn't
a big issue, it just seems like there must be a better solution to the
problem.

Overall, if some general kind of solution for both of these problems
(updates to MappedStringIndex perhaps) made it in, I'd be ecstatic.

On Tue, Sep 22, 2009 at 8:36 AM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 Thomas,

 We, as a rule, do not accept patches.  For a complete discussion, please
 see:
 http://groups.google.com/group/liftweb/browse_frm/thread/0c7a97cbf60780f0?hl=en#

 The current state of mapper's primary key support is sub-optimal.  There
 have been a couple of discussions of the issues on-list.  I am hoping to
 spend some time on this issue on Thursday.  If you've got specific
 requirements or specific tests, please post them.

 Thanks,

 David

 On Mon, Sep 21, 2009 at 9:33 PM, Thomas Rampelberg pyronic...@gmail.com
 wrote:

 I've been working at getting MetaMapper to work with primary keys that
 aren't auto-generated (or longs). Towards this end, I've got a patch
 for MetaMapper.scala that I'd like to get in. Who could I talk about
 the process for that?

 In addition, as part of implementing the functionality, I ran into
 some interesting problems. The most interesting one has to do with
 dbIndexFieldIndicatesSaved_?. The default (i_is_! != defaultValue)
 works great for cases where you're using the default value for the
 actual primary key. Unfortunately, if you use something like this when
 you're actively setting the primary key yourself there are some
 unfortunate side effects (nothing gets saved to the database).

 To get around this, I'm doing something along these lines:

 class 

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread David Pollak
On Tue, Sep 22, 2009 at 11:52 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:


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

  I've added code (it's in review board right now) that will automatically
  farm any snippet with the do:lazy='true' attribute set.
 
  So, lift:foo/ will execute the foo snippet inline.
 
  lift:foo do:lazy=true/ will execute the foo snippet in parallel and
 join
  the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet just
 as in the non-lazy fashion?


The NodeSeq that the snippet returns is rolled into the rendered page.

The SessionVars are available and bi-directional (set anywhere is visible
anywhere.)  The RequestVars are snapshotted at the time the snippet is
forked so you can see all RequestVars that were set before the snippet
forking, but any subsequent changes by either the main thread or the forked
thread are only visible on that thread.

You may nest forked snippets.

S is valid for parallel snippets (including the request, etc.)



 /Jeppe


 



-- 
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: Concurrent Web Service Requests?

2009-09-23 Thread David Pollak
On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:


 Could that be changed to lift:concurrent or lift:par etc. (see email on
 scala-user from Marting Odersky mentioned the future use of 'seq' and 'par'
 in concurrent collections)?
 Why use a different prefix than everything else built in to lift? And
 'lazy' is arguably not what's happening.



We're using a different prefix because if we use a lift:xxx prefix, the
snippet execution machinery will be invoked on the attribute and we don't
want that.

I'm cool with do:par unless anyone has a better suggestion.

Thanks,

David


 Thanks.


 -
 Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


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

  I've added code (it's in review board right now) that will automatically
  farm any snippet with the do:lazy='true' attribute set.
 
  So, lift:foo/ will execute the foo snippet inline.
 
  lift:foo do:lazy=true/ will execute the foo snippet in parallel and
 join
  the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet just
 as in the non-lazy fashion?

 /Jeppe




 



-- 
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: suggestion: strip comments when serving templates

2009-09-23 Thread David Pollak
On Tue, Sep 22, 2009 at 11:48 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:


 harryh har...@gmail.com writes:

  I would love to add comments to my templates:
 
  !-- Put the shiny new feature here as soon as we have time to build
  it --
 
  that got stripped out before being served to end users.

 A few thoughts:

 - Would also be nice if all excessive white space were stripped from
  the output (not sure how much this matters if it's gzip'ed)


That's a pretty expensive operation.  Pattern matching on the comment nodes
and not including them in the output is pretty fast.



 - In dev mode, I think it's important to maintain a 1-1 mapping between
  what's output in the browser and the source template(s)


By default, the comments are not stripped in dev mode.  In all other modes,
the comments are stripped.  There's a LiftRules to define the function that
determines stripping (LiftRules.stripComments)



 /Jeppe


 



-- 
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: suggestion: strip comments when serving templates

2009-09-23 Thread David Pollak
On Wed, Sep 23, 2009 at 1:29 AM, Timothy Perrett timo...@getintheloop.euwrote:


 Totally agree Jeppe.

 @dpp - what changes did you make? Are they in review board yet?


Yes.  They are part of the parallel snippet checkin.  Marius might be best
suited to review that checkin as it's very, very complex and is in the heart
of LiftSession.



 Cheers, Tim

 On 23 Sep 2009, at 07:48, Jeppe Nejsum Madsen wrote:

 
  harryh har...@gmail.com writes:
 
  I would love to add comments to my templates:
 
  !-- Put the shiny new feature here as soon as we have time to build
  it --
 
  that got stripped out before being served to end users.
 
  A few thoughts:
 
  - Would also be nice if all excessive white space were stripped from
   the output (not sure how much this matters if it's gzip'ed)
 
  - In dev mode, I think it's important to maintain a 1-1 mapping
  between
   what's output in the browser and the source template(s)
 
  /Jeppe
 
 
  
 


 



-- 
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: suggestion: strip comments when serving templates

2009-09-23 Thread David Pollak
On Wed, Sep 23, 2009 at 6:59 AM, harryh har...@gmail.com wrote:


  - Would also be nice if all excessive white space were stripped from
the output (not sure how much this matters if it's gzip'ed)

 This would be nice as well, but can be a lot more complicated.  GXP (a
 templating language I worked on at Google) had pretty awesome
 whitespace control that I'm happy to describe in detail if dpp (or
 another committer) is interested.  Personally though, I wouldn't
 consider this super high priority.


I might consider making handling of text nodes a pluggable function so
people can insert whatever they want.



 -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] Re: access to raw HttpServletRequest/Response

2009-09-23 Thread harryh

 You can do it today like this:

 S.containerRequest.map(r = (r.asInstanceOf[HTTPRequestServlet]).req)

eh?  I'm getting this error:

[error] value req is not a member of
net.liftweb.http.provider.servlet.HTTPRequestServlet
[error] val request: HttpServletRequest = S.containerRequest.map(r =
(r.asInstanceOf[HTTPRequestServlet]).req).open_!

-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: SessionVar.remove() not clearing out the variable

2009-09-23 Thread Dano

I have done some experimenting to set the session variable to Empty in
various places the following result:  Code called by the framework
(i.e. Actor.shutdown()) will properly have  the right context for a
Session variable.  Code called by the application does not have the
right context for the session variable (i.e. it is Empty when I expect
it to have a value).

Although I am still interested in a way to reset all values for a
SessionVar (especially from application code), I have something that
works for me in the short term.


Dan

On Sep 22, 8:50 pm, Dano olearydani...@gmail.com wrote:
 Marius,

 Thanks for your reply.  If I look in my pom.xml, I see that I am using
 1.1-SNAPSHOT.  However, I see your point about the remove() function
 not being in Vars.scala.  Not sure why I am able to compile a call to
 remove() on a SessionVar - but it does!

 My goal is to clear out the SessionVar for all sessions tied to the
 variable so that I can return the Session to the state it was at the
 beginning of time (at least with respect to the SessionVars).

 I have an object contained within a LiftView class called
 PartyLobbyUser:

 class GameView extends LiftView {
    object PartyLobbyUser extends SessionVar[Box[UserInfo]](Empty)
 ...

 }

 This object is set in code called by the GameView.dispatch() function
 and then referenced later by some comet actors.  I think the problem I
 am having is that since a SessionVar is essentially a thread local
 variable, I need to clear it (i.e. do something like PartyLobbyUser
 (Empty) ) in the right place.

 Perhaps the right context is to do this in the shutdown function of
 the comet actors since they are able to reference the variable and get
 the correct data (ie. via PartyLobbyUser.is).   I will try that and
 report back.

 Thanks again for your help.

 Dan

 On Sep 22, 7:03 pm, marius d. marius.dan...@gmail.com wrote:



  On Sep 22, 8:13 pm, Dano olearydani...@gmail.com wrote:

   Hello Lifters,

   I am struggling with trying to clear out a SessionVar which holds user
   information which I need to clear out after the user has left a
   'lobby' page.

   When I call the remove() function, I verify that the SessionVar is
   Empty.  However, when I click on the URL for the lobby page with new
   parameters, the SessionVar retains the old values for each session.
   It is as if they were repopulated.

   Perhaps I am not understanding out the function works.  When I look at
   the source code (Vars.scala), it seems like it is clearing out the
   state for each session.  The remove() function calls clearFunc().

     override protected def clearFunc(name: String): Unit =
   S.session.foreach(_.unset(name))

  No not for each session. S.session returns a Box which has a foreach
  function, it does not iterate through all sessions.

  Which Lift version are you using? .. there is no remove function in
  Vars in 1.1-SNAPSHOT version.

  Can you post some code to show where you are setting values on your
  SessionVar and where are you deleting them?

   Is there something I am missing?

   Thanks in advance.

   Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: Concurrent Web Service Requests?

2009-09-23 Thread Naftoli Gugenheim

A snippet attribute can be invoked with something other than 
lift:snippet=Class.method? There's a short syntax? What is it?
What was used for the feature that inserts a snippet asynchronously via Ajax?
My concern is that as more features are thought up and added they shouldn't all 
end up with different prefixes.
Also, if the prefix is nothing special I would go with the more verbose 
parallel because otherwise it's not obvious what it does. If it's prefixed 
with lift: at least you know it's a lift tag and you can look it up somewhere 
or ask on the list etc. But if you come back to some old template that says 
do:par you may be left clueless.


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

On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:


 Could that be changed to lift:concurrent or lift:par etc. (see email on
 scala-user from Marting Odersky mentioned the future use of 'seq' and 'par'
 in concurrent collections)?
 Why use a different prefix than everything else built in to lift? And
 'lazy' is arguably not what's happening.



We're using a different prefix because if we use a lift:xxx prefix, the
snippet execution machinery will be invoked on the attribute and we don't
want that.

I'm cool with do:par unless anyone has a better suggestion.

Thanks,

David


 Thanks.


 -
 Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


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

  I've added code (it's in review board right now) that will automatically
  farm any snippet with the do:lazy='true' attribute set.
 
  So, lift:foo/ will execute the foo snippet inline.
 
  lift:foo do:lazy=true/ will execute the foo snippet in parallel and
 join
  the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet just
 as in the non-lazy fashion?

 /Jeppe




 



-- 
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: Concurrent Web Service Requests?

2009-09-23 Thread Timothy Perrett

That's yet more sensible talking... +1

Btw, are there any issues with using undefined attribute namespaces?  
Or is that just for elements?

Cheers, Tim

Sent from my iPhone

On 23 Sep 2009, at 18:40, Naftoli Gugenheim naftoli...@gmail.com  
wrote:


 A snippet attribute can be invoked with something other than  
 lift:snippet=Class.method? There's a short syntax? What is it?
 What was used for the feature that inserts a snippet asynchronously  
 via Ajax?
 My concern is that as more features are thought up and added they  
 shouldn't all end up with different prefixes.
 Also, if the prefix is nothing special I would go with the more  
 verbose parallel because otherwise it's not obvious what it does.  
 If it's prefixed with lift: at least you know it's a lift tag and  
 you can look it up somewhere or ask on the list etc. But if you come  
 back to some old template that says do:par you may be left clueless.


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

 On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim naftoli...@gmail.com 
 wrote:


 Could that be changed to lift:concurrent or lift:par etc. (see  
 email on
 scala-user from Marting Odersky mentioned the future use of 'seq'  
 and 'par'
 in concurrent collections)?
 Why use a different prefix than everything else built in to lift? And
 'lazy' is arguably not what's happening.



 We're using a different prefix because if we use a lift:xxx prefix,  
 the
 snippet execution machinery will be invoked on the attribute and we  
 don't
 want that.

 I'm cool with do:par unless anyone has a better suggestion.

 Thanks,

 David


 Thanks.


 -
 Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


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

 I've added code (it's in review board right now) that will  
 automatically
 farm any snippet with the do:lazy='true' attribute set.

 So, lift:foo/ will execute the foo snippet inline.

 lift:foo do:lazy=true/ will execute the foo snippet in  
 parallel and
 join
 the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet  
 just
 as in the non-lazy fashion?

 /Jeppe








 -- 
 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] Fwd: [cufp] Video from CUFP 2009 Now Available

2009-09-23 Thread David Pollak
-- Forwarded message --
From: Jim Grundy jim.gru...@acm.org
Date: Wed, Sep 23, 2009 at 10:29 AM
Subject: [cufp] Video from CUFP 2009 Now Available
To: CUFP c...@googlegroups.com



http://www.vimeo.com/album/128851




-- 
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: Concurrent Web Service Requests?

2009-09-23 Thread David Pollak
On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:


 A snippet attribute can be invoked with something other than
 lift:snippet=Class.method? There's a short syntax? What is it?


There may be a short syntax (e.g., lift:Class.method) in the future.


 What was used for the feature that inserts a snippet asynchronously via
 Ajax?


That feature isn't done yet, but that feature is likely to be done as a
normal snippet.


 My concern is that as more features are thought up and added they shouldn't
 all end up with different prefixes.
 Also, if the prefix is nothing special I would go with the more verbose
 parallel because otherwise it's not obvious what it does. If it's prefixed
 with lift: at least you know it's a lift tag and you can look it up
 somewhere or ask on the list etc. But if you come back to some old template
 that says do:par you may be left clueless.


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

 On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim naftoli...@gmail.com
 wrote:

 
  Could that be changed to lift:concurrent or lift:par etc. (see email on
  scala-user from Marting Odersky mentioned the future use of 'seq' and
 'par'
  in concurrent collections)?
  Why use a different prefix than everything else built in to lift? And
  'lazy' is arguably not what's happening.
 


 We're using a different prefix because if we use a lift:xxx prefix, the
 snippet execution machinery will be invoked on the attribute and we don't
 want that.

 I'm cool with do:par unless anyone has a better suggestion.

 Thanks,

 David


  Thanks.
 
 
  -
  Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
 
 
  David Pollak feeder.of.the.be...@gmail.com writes:
 
   I've added code (it's in review board right now) that will
 automatically
   farm any snippet with the do:lazy='true' attribute set.
  
   So, lift:foo/ will execute the foo snippet inline.
  
   lift:foo do:lazy=true/ will execute the foo snippet in parallel and
  join
   the result back to page before its rendered.
 
  Very nice! In what context is the snippet executed? I assume that
  all timeout handling, errors etc should be handled by the snippet just
  as in the non-lazy fashion?
 
  /Jeppe
 
 
 
 
  
 


 --
 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] How can I replace SHtml.a with a Loc

2009-09-23 Thread glenn

I have a snippet that creates a Ajax link.

bind(item, xhtml,
addNew - {SHtml.a({ ()=
  SetHtml(item-save, edit(item))},
  Text(MenuTitle_Add)
  )}
 )

How would I, instead, create the same or similar link using a Loc?

Glenn
--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: Concurrent Web Service Requests?

2009-09-23 Thread Naftoli Gugenheim

What do you mean by as a normal snippet? That you will nest your snippet 
inside a special snippet?
To me it seems worthwhile to have a consistency between the two syntax-wise, 
since they have some common denominator semantics-wise.
Actually, maybe throw in eager_eval to the mix. Maybe we could have one eval or 
lift:eval or liftx:eval or whatever attribute, which can contain a space 
separated list of specifiers--eager, ajax, parellel.


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

On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:


 A snippet attribute can be invoked with something other than
 lift:snippet=Class.method? There's a short syntax? What is it?


There may be a short syntax (e.g., lift:Class.method) in the future.


 What was used for the feature that inserts a snippet asynchronously via
 Ajax?


That feature isn't done yet, but that feature is likely to be done as a
normal snippet.


 My concern is that as more features are thought up and added they shouldn't
 all end up with different prefixes.
 Also, if the prefix is nothing special I would go with the more verbose
 parallel because otherwise it's not obvious what it does. If it's prefixed
 with lift: at least you know it's a lift tag and you can look it up
 somewhere or ask on the list etc. But if you come back to some old template
 that says do:par you may be left clueless.


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

 On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim naftoli...@gmail.com
 wrote:

 
  Could that be changed to lift:concurrent or lift:par etc. (see email on
  scala-user from Marting Odersky mentioned the future use of 'seq' and
 'par'
  in concurrent collections)?
  Why use a different prefix than everything else built in to lift? And
  'lazy' is arguably not what's happening.
 


 We're using a different prefix because if we use a lift:xxx prefix, the
 snippet execution machinery will be invoked on the attribute and we don't
 want that.

 I'm cool with do:par unless anyone has a better suggestion.

 Thanks,

 David


  Thanks.
 
 
  -
  Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
 
 
  David Pollak feeder.of.the.be...@gmail.com writes:
 
   I've added code (it's in review board right now) that will
 automatically
   farm any snippet with the do:lazy='true' attribute set.
  
   So, lift:foo/ will execute the foo snippet inline.
  
   lift:foo do:lazy=true/ will execute the foo snippet in parallel and
  join
   the result back to page before its rendered.
 
  Very nice! In what context is the snippet executed? I assume that
  all timeout handling, errors etc should be handled by the snippet just
  as in the non-lazy fashion?
 
  /Jeppe
 
 
 
 
  
 


 --
 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: SessionVar.remove() not clearing out the variable

2009-09-23 Thread marius d.



On Sep 22, 10:50 pm, Dano olearydani...@gmail.com wrote:
 Marius,

 Thanks for your reply.  If I look in my pom.xml, I see that I am using
 1.1-SNAPSHOT.  However, I see your point about the remove() function
 not being in Vars.scala.  Not sure why I am able to compile a call to
 remove() on a SessionVar - but it does!

I'm not aware of any Lift implicits to expose remove function ...


 My goal is to clear out the SessionVar for all sessions tied to the
 variable so that I can return the Session to the state it was at the
 beginning of time (at least with respect to the SessionVars).

 I have an object contained within a LiftView class called
 PartyLobbyUser:

 class GameView extends LiftView {
    object PartyLobbyUser extends SessionVar[Box[UserInfo]](Empty)
 ...

 }

 This object is set in code called by the GameView.dispatch() function
 and then referenced later by some comet actors.  I think the problem I
 am having is that since a SessionVar is essentially a thread local
 variable, I need to clear it (i.e. do something like PartyLobbyUser
 (Empty) ) in the right place.

SessionVar is not a ThreadLocal, RequestVar is. SessionVar just sits
on top of LiftSession, and no you don't need to clear it except when
you want to remove things from the session. You also don't need to
clear RequestVar-s as it is done automatically by lift.

If you can put a minimalistic Lift project where you replicate the
problem I'll look on it this weekend.


 Perhaps the right context is to do this in the shutdown function of
 the comet actors since they are able to reference the variable and get
 the correct data (ie. via PartyLobbyUser.is).   I will try that and
 report back.

 Thanks again for your help.

 Dan

 On Sep 22, 7:03 pm, marius d. marius.dan...@gmail.com wrote:

  On Sep 22, 8:13 pm, Dano olearydani...@gmail.com wrote:

   Hello Lifters,

   I am struggling with trying to clear out a SessionVar which holds user
   information which I need to clear out after the user has left a
   'lobby' page.

   When I call the remove() function, I verify that the SessionVar is
   Empty.  However, when I click on the URL for the lobby page with new
   parameters, the SessionVar retains the old values for each session.
   It is as if they were repopulated.

   Perhaps I am not understanding out the function works.  When I look at
   the source code (Vars.scala), it seems like it is clearing out the
   state for each session.  The remove() function calls clearFunc().

     override protected def clearFunc(name: String): Unit =
   S.session.foreach(_.unset(name))

  No not for each session. S.session returns a Box which has a foreach
  function, it does not iterate through all sessions.

  Which Lift version are you using? .. there is no remove function in
  Vars in 1.1-SNAPSHOT version.

  Can you post some code to show where you are setting values on your
  SessionVar and where are you deleting them?

   Is there something I am missing?

   Thanks in advance.

   Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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] Canceling a ActorPing.scheduleAtFixedRate task

2009-09-23 Thread Xavi Ramirez

Hello,

Is there any way to cancel a task created with a ActorPing.scheduleAtFixedRate?

From looking at the source
(http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/ActorPing.scala.html)
it seem that scheduleAtFixedRate creates an actor which accepts an
UnSchedule message.  Unfortunately this actor is not returned to the
caller.

Thanks in advance,
Xavi

--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: Canceling a ActorPing.scheduleAtFixedRate task

2009-09-23 Thread Timothy Perrett

Xavi,

Can you show some code? There might be a way of doing it depending  
what you have...

Cheers, Tim

Sent from my iPhone

On 23 Sep 2009, at 20:50, Xavi Ramirez xavi@gmail.com wrote:


 Hello,

 Is there any way to cancel a task created with a  
 ActorPing.scheduleAtFixedRate?

 From looking at the source
 (http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/ActorPing.scala.html
  
 )
 it seem that scheduleAtFixedRate creates an actor which accepts an
 UnSchedule message.  Unfortunately this actor is not returned to the
 caller.

 Thanks in advance,
 Xavi

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: Canceling a ActorPing.scheduleAtFixedRate task

2009-09-23 Thread Xavi Ramirez

There isn't much to show... but maybe an example clarify things.

class SomeCometActor extends CometActor {
  override def localSetup() {
ActorPing.scheduleAtFixedRate(this, TaskMessage, 15 seconds, 15 seconds)
  }

  override def lowPriority = {
case TaskMessage =
  DoSomething()
  if(someCondition) { /* stop the scheduled task... What do I put here?*/ }
  }
}

If scheduleAtFixedRate returned either the Future or the Actor it
creates, then stopping the scheduled task would be fairly straight
forward.  Then again, I might be missing something.

Thanks,
Xavi


On Wed, Sep 23, 2009 at 3:54 PM, Timothy Perrett
timo...@getintheloop.eu wrote:

 Xavi,

 Can you show some code? There might be a way of doing it depending
 what you have...

 Cheers, Tim

 Sent from my iPhone

 On 23 Sep 2009, at 20:50, Xavi Ramirez xavi@gmail.com wrote:


 Hello,

 Is there any way to cancel a task created with a
 ActorPing.scheduleAtFixedRate?

 From looking at the source
 (http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/ActorPing.scala.html
 )
 it seem that scheduleAtFixedRate creates an actor which accepts an
 UnSchedule message.  Unfortunately this actor is not returned to the
 caller.

 Thanks in advance,
 Xavi

 


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: Db.addLogFunc

2009-09-23 Thread David

Hello, I'm trying to use the new logging information as described
here.  In my Boot I have:

import net.liftweb.mapper.{DB, DBLogEntry}
snip...

DB.addLogFunc {
  case (query, time) = {
 Log.info(All queries took  + time + ms: )
 query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
Log.info(stmt +  took  + duration + ms)})
Log.info(End queries)
  }
}

I'm using slf4j and logback, my root level is set to trace.  I see
trace output from lift, like:
16:32:02.208 [5991...@qtp-10429832-0] TRACE lift.trace:76 - Released
connection ConnectionIdentifier(lift) on thread Thread
[5991...@qtp-10429832-0,5,main]

But I don't see any output from the DB log functions.   Is there
anything else I need to do in order to enable logging?  I'm using
scala 2.7.5 and lift 1.1-SNAPSHOT.

Thanks, Dave


On Aug 28, 1:20 pm, marius d. marius.dan...@gmail.com wrote:
 EXCELLENT WORK DEREK !

 On Aug 28, 7:28 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:

  Hi all,
      I've made a change to the Mapper logging functionality in
  wip-dcb-sql-log-wrappers. The DB.addLogFuncmethod has changed to:

 addLogFunc( f: (DBLog,Long) = Any)

  where DBLog is a new trait (below) and the Long corresponds to the *total*
  duration of a given DB execution method. DBLog is defined as:

  trait DBLog {
    ... private stuff up here ...
    /** Return a list of all of the DBStatementEntry instances in the log
  buffer */
    def statementEntries : List[DBStatementEntry] = ...

    /** Return a list of all of the DBMetaEntry instances in the log buffer */
    def metaEntries : List[DBMetaEntry] = ...

    /** Return all log buffer entries */
    def allEntries : List[DBLogEntry] = ...

  }

  and we have some new event class/traits:

  trait DBLogEntry {
    def statement : String
    def duration : Long}

  object DBLogEntry {
    def unapply(obj : Any) = obj match {
      case entry : DBLogEntry = Some(entry.statement,entry.duration)
      case _ = None
    }}

  case class DBStatementEntry(statement : String, duration : Long) extends
  DBLogEntry
  case class DBMetaEntry(statement : String, duration : Long) extends
  DBLogEntry

  Statements are SQL statements, prepared or immediate, and meta entries
  correspond to things like getMaxRows, getGeneratedKeys, etc. As you can see,
  each individual statement records its own duration as well, so you can get
  fine-grained detail on all activity. An example log function in Boot could
  look like:

      DB.addLogFunc{
        case (query, time) = {
          Log.info(All queries took  + time + ms: )
          query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
  Log.info(stmt +  took  + duration + ms)})
          Log.info(End queries)
        }
      }

  And we get output like:

  INFO - All queries took 17ms:
  INFO - Exec update INSERT INTO users
  (lastname,locale,password_pw,password_slt,validated,uniqueid,timezone,firstname,email,superuser,textarea)
  VALUES
  (C,en_US,GzwLqDpmJ6TrECg06bGKvOAQxyc=,1JTAWGSSYLJHXASO,1,DU0G0RT3IFOA0NHSY5QQQTX42BOIHDGI,US/Mountain,D,
  d...@c.com,0,) : updated 1 rows took 9ms
  INFO - Get generated keys : rs =
  oracle.jdbc.driver.oraclereturnresult...@23f9e6e5 took 2ms
  INFO - Closed Statement took 0ms
  INFO - End queries

  Note that this code does introduce a breaking change if you're already using
  log functions, since theaddLogFuncsignature has changed. If I can get a
  review on the code before I merge to master I would appreciate it.

  Derek

  On Sat, Aug 15, 2009 at 8:02 AM, Derek Chen-Becker 
  dchenbec...@gmail.comwrote:

   OK, a preliminary version of log wrappers is checked in on
   wip-dcb-sql-log-wrappers. I'll merge it on Tuesday if no one sees any
   problems with it.

   Derek

   On Tue, Aug 11, 2009 at 11:08 AM, Derek Chen-Becker dchenbec...@gmail.com
wrote:

   Will do.

   On Tue, Aug 11, 2009 at 2:33 AM, marius d. 
   marius.dan...@gmail.comwrote:

   Please do so. If you need any help for some reason (time availability
   etc.) please let me know. As a note probably the wrappers should be
   only only when there is at least one log function registered.

   Br's,
   Marius

   On Aug 6, 11:48 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
If there's a consensus that we want our own JDBC wrappers I'll go 
ahead
   and
write them.

Derek

On Thu, Aug 6, 2009 at 1:19 PM, marius d. marius.dan...@gmail.com
   wrote:

 Probably building our own wrappers would be more lightweight then
   3-rd
 party. Jus' guessing

 Br's,
 Marius

 On Aug 6, 9:58 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
  Well, I started looking at it and determined that the only way for
   us to
  truly log the queries would be to essentially make our own 
  wrappers
   over
  Statement and PreparedStatement. There are projects (log4jdbc,
   notably)
 that
  already do this, and in a transparent manner. I'm not sure that
  

[Lift] Re: Canceling a ActorPing.scheduleAtFixedRate task

2009-09-23 Thread Xavi Ramirez

I think I figured out a way to get around this:

class SomeCometActor extends CometActor {
  private var tempActor: Actor = null

  override def localSetup() {
val cometActor = this
var tempActor = actor{ loop { react {
   case TaskMessage = cometActor ! TaskMessage
   case UnSchedule = exit
} } }
ActorPing.scheduleAtFixedRate(tempActor, TaskMessage, 15 seconds,
15 seconds)
  }

  override def lowPriority = {
case TaskMessage =
  DoSomething()
  if(someCondition) { tempActor ! UnSchedule }
  }
}

Instead of registering the comet actors for the scheduled task, I
register a temporary actor.  During its execution, scheduleAtFixedRate
creates an actor. Let's call this the Scheduled Task Actor.  The
scheduled task actor is then linked(see
http://www.scala-lang.org/docu/files/api/scala/actors/Actor.html#link%28scala.actors.AbstractActor%29)
to the temporary actor i passed in.  So now, when I need to stop the
scheduled task actor, I can shutdown the temporary actor.  This works
because when an actor is shutdown, all actors it's linked to are shut
down as well.

This is kinda nuts, but I guess it works.

I'm just sharing in case someone else runs into this problem.

Thanks,
Xavi

On Wed, Sep 23, 2009 at 4:13 PM, Xavi Ramirez xavi@gmail.com wrote:
 There isn't much to show... but maybe an example clarify things.

 class SomeCometActor extends CometActor {
  override def localSetup() {
    ActorPing.scheduleAtFixedRate(this, TaskMessage, 15 seconds, 15 seconds)
  }

  override def lowPriority = {
    case TaskMessage =
      DoSomething()
      if(someCondition) { /* stop the scheduled task... What do I put here?*/ }
  }
 }

 If scheduleAtFixedRate returned either the Future or the Actor it
 creates, then stopping the scheduled task would be fairly straight
 forward.  Then again, I might be missing something.

 Thanks,
 Xavi


 On Wed, Sep 23, 2009 at 3:54 PM, Timothy Perrett
 timo...@getintheloop.eu wrote:

 Xavi,

 Can you show some code? There might be a way of doing it depending
 what you have...

 Cheers, Tim

 Sent from my iPhone

 On 23 Sep 2009, at 20:50, Xavi Ramirez xavi@gmail.com wrote:


 Hello,

 Is there any way to cancel a task created with a
 ActorPing.scheduleAtFixedRate?

 From looking at the source
 (http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/ActorPing.scala.html
 )
 it seem that scheduleAtFixedRate creates an actor which accepts an
 UnSchedule message.  Unfortunately this actor is not returned to the
 caller.

 Thanks in advance,
 Xavi

 


 



--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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] TreeView widget doesn't work with IE 8

2009-09-23 Thread glenn

The TreeView widget doesn't work in IE 8. I haven't tested in earlier
versions. It does work in the latest FireFox.

Glenn
--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: You are not banned from this group!!

2009-09-23 Thread Oliver Lambert
On Tue, Sep 22, 2009 at 7:21 AM, David Pollak feeder.of.the.be...@gmail.com
 wrote:


 I will gladly buy beer/coffee/food for anyone who gets such a notice.  I
 sincerely apologize for any problems this is causing.


Can you send me such a notice, I'd like a beer!
Oh, and I've been away for a while, its nice to see the lift mailing list is
going so strong.

Oliver

--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: The LiftView trait can't work ?

2009-09-23 Thread Neil.Lv

Yeah, i use the Lift 1.0.

I just want to test the LiftView trait, when i don't configure the
viewDispatch in Boot Class and don't define the corresponding template
(such as /Test/hello.html in webapp directory),
then i type the http://localhost:8080/Test/hello; link that the View
Class can to do it.

Thank you for your reply that it's very helpful.

I'll try to add /Test/hello in the SiteMap and test it again.

Cheers,
Neil

On Sep 23, 11:19 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 If you're using Lift 1.0.x, the request will silently fail.

 If you're using Lift 1.1-x, you will get a helpful error message reminding
 you to add the /Test/hello link to your SiteMap in Boot.scala



 On Wed, Sep 23, 2009 at 1:02 AM, Neil.Lv anim...@gmail.com wrote:

  Hi all,

 Just I define a class that extends the LiftView trait, but there
  is something wrong with this class when i using it.

 I wrote some test code like this:

  ###  code  ###
  package com.test.view

  import net.liftweb._
  import http._

  import scala.xml.{NodeSeq}

  class Test extends LiftView {
 override def dispatch = {
 case hello = doTest _
 }

 def doTest():NodeSeq = {
 lift:surround with=default at=content
 Time is: {new _root_.java.util.Date}
 /lift:surround
 }
  }
  ###  code  ###

Use these links and always get this message The Requested URL /
  Test/hello was not found on this server
   http://localhost:8080/Test/hello
   http://localhost:8080/test/hello

Note: I don't change my Boot class in the  /src/main/scala/
  bootstrap/liftweb folder.

Is there anyone can help ?
Thanks very much!

 --
 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] More flexible CRUDify

2009-09-23 Thread Marcin Mielżyński

I'm playing around with CRUDify and to some extent it is flexible. 
However, requirements for more flexibility made me extend the CRUDify, 
but finally I ended up having all the impl on my own.

So I have a couple of questions about Mapper design strategies. For 
example, I want some MappedFields to not to show on lists - do I have to 
extend all fields now and supply showOnList_? and more control methods 
or it's better to have a marker trait and filter them ? Or maybe 
introduce listFieldOrder for MetaMapper ? How about finer grained 
validations - for now I have a ValRequired and similar traits that use 
abstract override to alter MapperString behavior...
I also use a trait and abstract override to localize field descriptions 
based on singleton names. But growing number of traits for this usage 
kind of smells... I guess that I'm accidentally leaning towards 
something like rails http://activescaffold.com/.

Any opinions on that ?

Marcin



--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: You are not banned from this group!!

2009-09-23 Thread Charles F. Munat

Funny, I was just wondering what happened to you maybe two days ago. Are 
you back, or just checking in?

Chas.

Oliver Lambert wrote:
 
 
 On Tue, Sep 22, 2009 at 7:21 AM, David Pollak 
 feeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com 
 wrote:
 
 
 I will gladly buy beer/coffee/food for anyone who gets such a
 notice.  I sincerely apologize for any problems this is causing.
 
  
 Can you send me such a notice, I'd like a beer!
 Oh, and I've been away for a while, its nice to see the lift mailing 
 list is going so strong.
 
 Oliver
 
  

--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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: The LiftView trait can't work ?

2009-09-23 Thread Neil.Lv

It works now that i add /test/hello into the SiteMap.

Menu(Loc(Test, List(test, hello), Test))


But i have something questions about the SiteMap.
If i have more and more these links in my application whether i must
add these links one by one into the SiteMap ?
Such as:

   Menu(Loc(Test, List(test, hello), Test)) :: Menu(...) ::
Menu(...) :: Menu(...) ...


Maybe this code will be very long whether there is another way to
achieve this goal.

Cheers,
  Neil

On Sep 24, 9:39 am, Neil.Lv anim...@gmail.com wrote:
 Yeah, i use the Lift 1.0.

 I just want to test the LiftView trait, when i don't configure the
 viewDispatch in Boot Class and don't define the corresponding template
 (such as /Test/hello.html in webapp directory),
 then i type the http://localhost:8080/Test/hello; link that the View
 Class can to do it.

 Thank you for your reply that it's very helpful.

 I'll try to add /Test/hello in the SiteMap and test it again.

 Cheers,
 Neil

 On Sep 23, 11:19 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:

  If you're using Lift 1.0.x, the request will silently fail.

  If you're using Lift 1.1-x, you will get a helpful error message reminding
  you to add the /Test/hello link to your SiteMap in Boot.scala

  On Wed, Sep 23, 2009 at 1:02 AM, Neil.Lv anim...@gmail.com wrote:

   Hi all,

  Just I define a class that extends the LiftView trait, but there
   is something wrong with this class when i using it.

  I wrote some test code like this:

   ###  code  ###
   package com.test.view

   import net.liftweb._
   import http._

   import scala.xml.{NodeSeq}

   class Test extends LiftView {
  override def dispatch = {
  case hello = doTest _
  }

  def doTest():NodeSeq = {
  lift:surround with=default at=content
  Time is: {new _root_.java.util.Date}
  /lift:surround
  }
   }
   ###  code  ###

 Use these links and always get this message The Requested URL /
   Test/hello was not found on this server
http://localhost:8080/Test/hello
http://localhost:8080/test/hello

 Note: I don't change my Boot class in the  /src/main/scala/
   bootstrap/liftweb folder.

 Is there anyone can help ?
 Thanks very much!

  --
  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: You are not banned from this group!!

2009-09-23 Thread Meredith Gregory
Dear David,

My coffee addiction says i'm feeling very banned.

Best wishes,

--greg

On Wed, Sep 23, 2009 at 7:08 PM, Charles F. Munat c...@munat.com wrote:


 Funny, I was just wondering what happened to you maybe two days ago. Are
 you back, or just checking in?

 Chas.

 Oliver Lambert wrote:
 
 
  On Tue, Sep 22, 2009 at 7:21 AM, David Pollak
  feeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com
  wrote:
 
 
  I will gladly buy beer/coffee/food for anyone who gets such a
  notice.  I sincerely apologize for any problems this is causing.
 
 
  Can you send me such a notice, I'd like a beer!
  Oh, and I've been away for a while, its nice to see the lift mailing
  list is going so strong.
 
  Oliver
 
  

 



-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.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: [Lift committers] Re: Welcome Indrajit Raychaudhuri to the Lift Committers

2009-09-23 Thread Indrajit Raychaudhuri


Moved over to main Lift list. Folks, for better handle on the context, 
please have a quick run through of the original message before coming to 
David's comments and my responses.

Thanks, Indrajit

On 22/09/09 4:56 AM, David Pollak wrote:
 Moved to the main Lift list.
 
 All in all, I like the ideas.

 A couple of things:

 * I am concerned about the target Maven complexity.  If the
   JavaScript stuff gets broken out, I am concerned that it will
   create a maven overload problem for end users when they want to
   switch from jquery to yui.

Concern acknowledged. There are two phases to this:

1. Have separate artifacts (jar) for the Lift JS helpers (those that 
implement JSArtifacts) and have the *.js dependencies tucked within the 
respective jars of the Lift JS helpers. The *.js files can be fetched 
from the respective source (JQuery site, YUI site, Google API mirror 
etc.) at build time or kept in git.

At the end, we always have a Lift JS helper jar (one each for JQ, YUI 
etc.) that has everything bundled inside.

2. For Lift based applications, there would be explicit dependency/ 
for either of JQuery or YUI in the pom.xml (archetype:generate should do 
the right thing here). If one wishes to switch from JQuery to YUI, it 
should ideally be one small manual modification in the pom. This 
overload is similar to the switch to slf4j, even less.

For the users not willing to take the burden of switching at Maven level 
there can be a jar that bundles both JQuery and YUI. Just use 
_-all-1.1.js, do LiftRules.jsArtifacts = YUIArtifacts and off you go.

So the choice (for the user to tweak) is between smaller payload (will 
grow with more js lib support) or minor Maven overload (will stay 
constant). Lift can provide both!

 * I am concerned about how you dismiss the version related issues
   for Scala.  Scala is hyper-brittle in terms of version numbers and
   we have to tightly tie Lift versions to Scala versions.  Perhaps I
   misunderstood what you suggest about this.

Scala version dependence is highly important. And therefore take the 
control away from the end user! The intent is actually to have Lift very 
tightly coupled with a Scala version, not the contrary.

A way of doing that is to remove scala version reference from 
applications based on Lift (not Lift itself). Thus, the projects 
generated by archetype:generate doesn't need to have anything like 
2.7.5, 2.7.6 etc. in the pom.xml. But since this Lift based project 
would depend on, say lift-core, and since lift-core has explicit 
dependence on, say Scala 2.7.5, Scala 2.7.5 would be pulled up 
transitively. This is similar to commons-collections dependency. A Lift 
application is aware (via pom) that it depends on commons-collections 
transitively.

Having said that, explicit dependency on MainGenericRunner holds us back 
from doing that at the moment. Moving LiftConsole into Lift code base 
can be an option (lift-testkit maybe?).

 * I added the maven stuff into Lift in order to (try) to make
   RunCodeRun do continuous integration.

Yes, figured that. Curiosity: Anything that Hudson cannot handle that 
RCR can?



 On Sat, Sep 19, 2009 at 9:59 AM, Indrajit Raychaudhuri
 indraj...@gmail.com mailto:indraj...@gmail.com wrote:



 Folks,

 Thank you very much for the warm welcome. I feel humble and at home.

 Now coming to the action right away ...

 Lift already looks and feels cool at the moment and it has a lot going
 for it. All the existing committers (and the BDFL) take a bow.
 But we can possibly make Lift even better and more convenient
 (particularly for newbies and the fence-sitters) and make Lift rock
 (even harder)!.

 Eventually, the goal is to get pretty close to where Rails stands from
 developers convenience standpoint. But we can thrash out the easier
 ones before getting to code generation and stuff.

  From here on, there could be some points that might read like
 'criticism' and might rub some committers the wrong way. My apologies
 upfront if that happens. But the main intent is to open ourselves up
 for debate and see if some good things come out of it. I am just
 taking up the ones that are at the top of my mind, there is more. But
 this mail is BIG and could potentially spoil your weekend, be
 warned :)



 Point 1: Keep lift-core neat and small

 We can add a little bit of hierarchy to the Lift structure. lift-
 paypal, lift-util, lift-record are too different to be peers :-) Take
 a pause, for a moment, do a git pull of dpp/lift and take a look (ls -
 l) at the lift directory structure through the eyes of a Lift fence-
 sitter:

 A subset of what you see now:
 - examples
 - lift-* [some of which are too different from each other]
 - lift
 - maven
 - presentations
 - src

 What one has is little confusing IMHO. Agreed, that you'd expect them