[Lift] Re: suggestion: strip comments when serving templates
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?
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
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?
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
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 ?
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
- 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?
+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 ?
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 ?
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
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?
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?
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
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
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
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
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
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?
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?
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
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?
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
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
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
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
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
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
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
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!!
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 ?
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
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!!
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 ?
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!!
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
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
