[Lift] Re: how to do basic joins
Please post a reproducible example. I use this call pretty regularly and have not seen any problems. Sure thing. I will put something together tomorrow. If feel like I must be making a silly newbie mistake of some kind because I'm sure that you (and others) must be doing this sort of things without problems. Haven't been able to figure out what it is though. Also, what version of Lift are you using? 1.0 -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] how to use BySql query
Hi, I am new to lift . I am using mapper framework. i have table emp with name ,salary, location columns now i want to put query to find employee whose salary is less than 1 and greater that 1000 and location is California. For this i am using BySql query...as foolows - val emp_List = emp_details.findAll(BySql(salary between ? and ?, 1000,1,IHaveValidatedThisSQL(pravin,2009-08-03))); but when i compileing this i get following error - java.io.IOException: MALFORMED[1] at scala.tools.nsc.io.SourceReader$.decode(SourceReader.scala: 134) at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:95) at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:46) at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:65) at scala.tools.nsc.Global.getSourceFile(Global.scala:211) at scala.tools.nsc.Global.getSourceFile(Global.scala:217) at scala.tools.nsc.Global$Run$$anonfun$compile$1.apply (Global.scala:667) at scala.tools.nsc.Global$Run$$anonfun$compile$1.apply (Global.scala:667) at scala.List.map(List.scala:805) at scala.tools.nsc.Global$Run.compile(Global.scala:667) at scala.tools.nsc.Main$.process(Main.scala:73) at scala.tools.nsc.Main$.main(Main.scala:87) at scala.tools.nsc.Main.main(Main.scala) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.scala_tools.maven.executions.MainHelper.runMain (MainHelper.java:105) at org.scala_tools.maven.executions.MainWithArgsInFile.main (MainWithArgsInFile.java:26) error: IO error while decoding C:\Documents and Settings\pravin_karne \Scala_workspace\mobworx\src\main\scala\com\mobworx\snip pet\DisplayResults.scala with UTF-8 Please try specifying another one using the -encoding option one error found So what is cause of this error and is there other way to find it out Thanks in advance -Pravin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Welcome Joni Freeman to the Lift committers
David Pollak feeder.of.the.be...@gmail.com writes: * DSL to produce valid JSON Examples: http://github.com/jonifreeman/liftweb/tree/e2e59b63a427258e7dde9b0877691322c29c8552/lift-json Sweet! Will this be integrated with Lift's Js constructs so we can use this to e.g construct a JsObj? /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: how to use BySql query
pravin pravinka...@gmail.com writes: Hi, I am new to lift . I am using mapper framework. i have table emp with name ,salary, location columns now i want to put query to find employee whose salary is less than 1 and greater that 1000 and location is California. For this i am using BySql query...as foolows - val emp_List = emp_details.findAll(BySql(salary between ? and ?, 1000,1,IHaveValidatedThisSQL(pravin,2009-08-03))); but when i compileing this i get following error - I don't think this is problem with your sql (though I think you need to provide the params as a list as the last parameter:-) but with the encoding of your source file. Please verify that it is UTF8 encoded if it contains non-ascii characters or specify the correct encoding when compiling /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: [Lift committers] Welcome Joni Freeman to the Lift committers
Bienvenue On Thu, Aug 13, 2009 at 18:06, David Pollakfeeder.of.the.be...@gmail.com wrote: Folks, I'm pleased to announce that Joni Freeman has joined the Lift committers. Joni will be adding his high performance JSON library as a module in Lift... and I certainly hope that Lift's JSON support will improve. Please join me in welcoming Joni! Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] is that a lift's bug?
i am a newer to lift, and now i am reading the book the definitive guide to lift. In chapter 5.1, book told me this: val helpMenu = Menu(Loc(helpHome,(help :: :: Nil) - true,Help)) make all the files under help folder accessible, but i found the loc object in the Menu item should write like this: (help :: Nil) - true. Is that book wrong? and sometimes i wrote Menu(Loc(Home, /, Home)) and got a compile wrong, and i have to write Menu(Loc(Home, / :: Nil, Home)). i have imported Loc._, why / string can not convert to a list? is that a lift bug? besides, does all pages accessible in lift project must be import to Sitemap? if so, when the website is large, the work may be tiring? --~--~-~--~~~---~--~~ 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: is that a lift's bug?
On Aug 14, 11:10 am, xiaomingzhen...@gmail.com xiaomingzhen...@gmail.com wrote: i am a newer to lift, and now i am reading the book the definitive guide to lift. In chapter 5.1, book told me this: val helpMenu = Menu(Loc(helpHome,(help :: :: Nil) - true,Help)) make all the files under help folder accessible, but i found the loc object in the Menu item should write like this: (help :: Nil) - true. Is that book wrong? and sometimes i wrote Menu(Loc(Home, /, Home)) and got a compile wrong, and i have to write Menu(Loc(Home, / :: Nil, Home)). i have imported Loc._, why / string can not convert to a list? is that a lift bug? String and List are unrelated types. You can write if you want in implicit conversion function but IMHO is not worth it. Menu(Loc(Home, List(/), Home)) For this construct Lift already has an implicit conversion strLstToLink from a Seq[String] to a Link which is what Loc apply expects. So List[String] is expected because a path is not expressed as a plain string but rather as a List of path parts. besides, does all pages accessible in lift project must be import to Sitemap? To access a page you should put it in the SiteMap. You can choose to not use SiteMap at all but rather work only with DispatchPF and so on, but for a web application this is impractical. if so, when the website is large, the work may be tiring? You only define the sitemap once. You can break it to modules etc. that return specific lists of Menus but that's about application design. If you're doing RIA style application you'll probably won't need a tremendous amount of pages anyways. --~--~-~--~~~---~--~~ 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: is that a lift's bug?
marius d. marius.dan...@gmail.com writes: [...] besides, does all pages accessible in lift project must be import to Sitemap? To access a page you should put it in the SiteMap. You can choose to not use SiteMap at all but rather work only with DispatchPF and so on, but for a web application this is impractical. You could also add LiftRules.passNotFoundToChain = true in order to serve static content from your webapp /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: Attributes question
What listing from the book are you referring to ? 7.13 ?
lift:Ledger.balance
ledger:time ledger:id=myId class=bold/
/lift:Ledger.balance
and the code:
class Ledger {
def balance (content : NodeSeq ) : NodeSeq = {
bind (ledger, content,
time - span{(new java.util.Date).toString}/span)
}
}
would output
span id=”myId”Sat Mar 28 16:43:48 EET 2009/span.
so ledger:id was preserved in the output node. So class attribute is
not preserved. Is that you are referring to ?
Well ledger:time node is just an xml node meaningless without the
snippet's magic. You can access the unprefixed attributes passed to
this node with BindHelpers.attrs such as
bind (ledger, content,
time - {node:NodeSeq = span class={BindHelpers.attr(class)}
{(new java.util.Date).toString}/span)}
}
to your questions ... why we preserve the attributes having the same
prefix with the node and not the default ones is simply a design
choice (the way I see it) that by the common prefix there is a hint
that this attribute should stay in the output node. It is not a rock
solid argumentation but kinda makes sense. Unprefixed attributes here
may be attributes that have nothing to do with output node, but rather
with processing logic.
To change this behavior a consensus should be made. Personally I'm not
truly convinced it should be but who knows ...
Br's,
Marius
On Aug 14, 7:06 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
What I would like to do:
label for=nameName/labelnbsp;person:name I'd=name size=10
class=special style=vertical-align: top maxlength=5 tabindex=1 /
Okay, just a little contrived...
My understanding is you can do this by prefixing the attribute with lift:;
otherwise it will not be output but is available to the snippet code, i.e.,
without the prefix you are making an attribute available to the snippet but
that's it.
I'm getting this from Exploring Lift page 115.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
Why was the decision made, if I understand correctly, that normal
attributes are not preserved in a bound node, and are are only available for
the snippet's usage, and if you want the attribute to be sticky you have
to prefix it with lift:? Wouldn't it be better the other way?
I don't understand your question. Are you talking about Helpers.bind() or
are you talking about snippet dispatching?
Can you please provide an example of what happens now and what you would
expect to happen?
One of lift's design goals is to help keep the static html in the view and
the logic in the code, and to provide a templating system that doesn't
interfere with visual web designers. It seems to me that it would further
this goal if html attributes could be properly specified in the view html.
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Symlinks and Javascript Files
Is the path to that file defined in your SiteMap? In the case of using
ResourceServer, the js that you've tried means that the script should be
under a js subdir.
Derek
On Thu, Aug 13, 2009 at 7:57 PM, Peter Robinett pe...@bubblefoundry.comwrote:
My Lift project is in a git repository and to the repository I've
added a submodule. Since right now I only want one javascript file
from this submodule, my thought was to make the directory src/main/
webroot/js and then make a symbolic link to the javascript file in
question. Unfortunately, when I try to request the file at
http://localhost:9090/js/jquery.sparkline.js, I get a 403 response
that says the page is not defined in my sitemap. There was no note of
the request in the stdout.
Thinking that the js subdirectory is the problem, I then tried making
the symlink in the webroot directory and got a 404 error. On stdout it
said:
2009-08-13 18:38:23.051::WARN: Aliased resource: file:/Users/peter/
Sites/Equal%20Networks/server/src/main/webapp/
jquery.sparkline.js==file:/Users/peter/Sites/Equal%20Networks/server/
vendors/dashboard/www/jquery.sparkline.js
From this I gather than Lift is troubled by the presence of a symlink
and refused to acknowledge its presence. Is this true? If so, why?
From the thread last week on ExtJS I see a discussion on loading files
in webroot, including supporting a css directory by adding the
following to Boot.scala:
ResourceServer.allow {
case css :: _ = true
}
I already have a css file being served from a directory in the exact
same location without any additions to Boot.scala. Nonetheless, I
tried the following:
ResourceServer.allow {
case js :: _ = true
}
Unfortunately, this had no effect. So, how can I get my symlinked
javascript to be server? Or should I just give up on symlinks
altogether (I'm not a git master, so perhaps that was the wrong
approach anyway).
Peter Robinett
PS I'm on 1.1-SNAPSHOT.
PPS The YUI Compressor works well. Very cool.
--~--~-~--~~~---~--~~
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: is that a lift's bug?
That looks like a typo in the book. I'll fix it. Derek On Fri, Aug 14, 2009 at 2:10 AM, xiaomingzhen...@gmail.com xiaomingzhen...@gmail.com wrote: i am a newer to lift, and now i am reading the book the definitive guide to lift. In chapter 5.1, book told me this: val helpMenu = Menu(Loc(helpHome,(help :: :: Nil) - true,Help)) make all the files under help folder accessible, but i found the loc object in the Menu item should write like this: (help :: Nil) - true. Is that book wrong? and sometimes i wrote Menu(Loc(Home, /, Home)) and got a compile wrong, and i have to write Menu(Loc(Home, / :: Nil, Home)). i have imported Loc._, why / string can not convert to a list? is that a lift bug? besides, does all pages accessible in lift project must be import to Sitemap? if so, when the website is large, the work may be tiring? --~--~-~--~~~---~--~~ 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: is that a lift's bug?
On Fri, Aug 14, 2009 at 1:10 AM, xiaomingzhen...@gmail.com xiaomingzhen...@gmail.com wrote: i am a newer to lift, and now i am reading the book the definitive guide to lift. In chapter 5.1, book told me this: val helpMenu = Menu(Loc(helpHome,(help :: :: Nil) - true,Help)) make all the files under help folder accessible, but i found the loc object in the Menu item should write like this: (help :: Nil) - true. Is that book wrong? and sometimes i wrote Menu(Loc(Home, /, Home)) and got a compile wrong, and i have to write Menu(Loc(Home, / :: Nil, Home)). i have imported Loc._, why / string can not convert to a list? is that a lift bug? besides, does all pages accessible in lift project must be import to Sitemap? No. If you do not declare the sitemap, then all the pages in the app will be available, however you'll have to manually enforce access control and manually build menus. You can also define particular directories as anything in this directory gets served. if so, when the website is large, the work may be tiring? It's been my experience that having a large site is a very good reason to have SiteMap... you can have each module define its pages, access control, etc. and roll that up into a nice menu. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Attributes question
Yes, 7.12 vs. 7.13.
Apparently the prefix is not supposed to be lift like I thought but the prefix
of the node it belongs to. But I still have the question. It would seem more
logical that just like nodes, attributes that are prefixed are not html, and
html attributes should not be prefixed. What was the reasoning behind this?
-
marius d.marius.dan...@gmail.com wrote:
What listing from the book are you referring to ? 7.13 ?
lift:Ledger.balance
ledger:time ledger:id=myId class=bold/
/lift:Ledger.balance
and the code:
class Ledger {
def balance (content : NodeSeq ) : NodeSeq = {
bind (ledger, content,
time - span{(new java.util.Date).toString}/span)
}
}
would output
span id=”myId”Sat Mar 28 16:43:48 EET 2009/span.
so ledger:id was preserved in the output node. So class attribute is
not preserved. Is that you are referring to ?
Well ledger:time node is just an xml node meaningless without the
snippet's magic. You can access the unprefixed attributes passed to
this node with BindHelpers.attrs such as
bind (ledger, content,
time - {node:NodeSeq = span class={BindHelpers.attr(class)}
{(new java.util.Date).toString}/span)}
}
to your questions ... why we preserve the attributes having the same
prefix with the node and not the default ones is simply a design
choice (the way I see it) that by the common prefix there is a hint
that this attribute should stay in the output node. It is not a rock
solid argumentation but kinda makes sense. Unprefixed attributes here
may be attributes that have nothing to do with output node, but rather
with processing logic.
To change this behavior a consensus should be made. Personally I'm not
truly convinced it should be but who knows ...
Br's,
Marius
On Aug 14, 7:06 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
What I would like to do:
label for=nameName/labelnbsp;person:name I'd=name size=10
class=special style=vertical-align: top maxlength=5 tabindex=1 /
Okay, just a little contrived...
My understanding is you can do this by prefixing the attribute with lift:;
otherwise it will not be output but is available to the snippet code, i.e.,
without the prefix you are making an attribute available to the snippet but
that's it.
I'm getting this from Exploring Lift page 115.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
Why was the decision made, if I understand correctly, that normal
attributes are not preserved in a bound node, and are are only available for
the snippet's usage, and if you want the attribute to be sticky you have
to prefix it with lift:? Wouldn't it be better the other way?
I don't understand your question. Are you talking about Helpers.bind() or
are you talking about snippet dispatching?
Can you please provide an example of what happens now and what you would
expect to happen?
One of lift's design goals is to help keep the static html in the view and
the logic in the code, and to provide a templating system that doesn't
interfere with visual web designers. It seems to me that it would further
this goal if html attributes could be properly specified in the view html.
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Welcome Joni Freeman to the Lift committers
On Fri, Aug 14, 2009 at 12:31 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: David Pollak feeder.of.the.be...@gmail.com writes: * DSL to produce valid JSON Examples: http://github.com/jonifreeman/liftweb/tree/e2e59b63a427258e7dde9b0877691322c29c8552/lift-json Sweet! Will this be integrated with Lift's Js constructs so we can use this to e.g construct a JsObj? Yeah we may break Lift's JavaScript support out into a separate module which may break some code, but will ultimately result in more flexibility. /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 Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: how to use BySql query
On Thu, Aug 13, 2009 at 10:26 PM, pravin pravinka...@gmail.com wrote: Hi, I am new to lift . I am using mapper framework. i have table emp with name ,salary, location columns now i want to put query to find employee whose salary is less than 1 and greater that 1000 and location is California. For this i am using BySql query...as foolows - val emp_List = emp_details.findAll(BySql(salary between ? and ?, 1000,1,IHaveValidatedThisSQL(pravin,2009-08-03))); The first issue is the misplaced quotes. This is a Scala compiler issue... the compiler should report a syntax error: val emp_List = emp_details.findAll(BySql(salary between ? and ?, 1000,1,IHaveValidatedThisSQL(pravin,2009-08-03))); Should be: val emp_List = emp_details.findAll(BySql(salary between ? and ?, 1000,1,IHaveValidatedThisSQL(pravin,2009-08-03))); But once it compiles, it's still going to result in a run-time error. salary between ? and ?, 1000,1 is not valid SQL. You probably want something like: val emp_List = emp_details.findAll(BySql(salary between ? and ?,IHaveValidatedThisSQL(pravin,2009-08-03), 1000, 1)); Note that 1000 and 1 are not part of the query string, but are parameters bound to the two '?'. but when i compileing this i get following error - java.io.IOException: MALFORMED[1] at scala.tools.nsc.io.SourceReader$.decode(SourceReader.scala: 134) at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:95) at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:46) at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:65) at scala.tools.nsc.Global.getSourceFile(Global.scala:211) at scala.tools.nsc.Global.getSourceFile(Global.scala:217) at scala.tools.nsc.Global$Run$$anonfun$compile$1.apply (Global.scala:667) at scala.tools.nsc.Global$Run$$anonfun$compile$1.apply (Global.scala:667) at scala.List.map(List.scala:805) at scala.tools.nsc.Global$Run.compile(Global.scala:667) at scala.tools.nsc.Main$.process(Main.scala:73) at scala.tools.nsc.Main$.main(Main.scala:87) at scala.tools.nsc.Main.main(Main.scala) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.scala_tools.maven.executions.MainHelper.runMain (MainHelper.java:105) at org.scala_tools.maven.executions.MainWithArgsInFile.main (MainWithArgsInFile.java:26) error: IO error while decoding C:\Documents and Settings\pravin_karne \Scala_workspace\mobworx\src\main\scala\com\mobworx\snip pet\DisplayResults.scala with UTF-8 Please try specifying another one using the -encoding option one error found So what is cause of this error and is there other way to find it out Thanks in advance -Pravin -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Attributes question
Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Attributes question
Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Attributes question
On Fri, Aug 14, 2009 at 9:08 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. This has nothing to do with snippets. This is below the level of the snippet. This is the operation of the bind() operation (if I understand your question correctly.) With a bind, you are replacing one Elem with a NodeSeq. There are plenty of helpers that allow you to do this. If you want to do something that's not provided by the helper, you can write a function and wrap it in a FuncBindParam to do things the way you want. Nothing in Lift is stopping that from happening. How, why is did I make the choice to do a pure substitution rather than doing something fancier by default: 1. You get what you bind rather than having some attributes magically added. 2. There's no requirement that you bind an Elem to an Elem... thus if you bind a NodeSeq, what's the correct behavior (adding attrs to every Elem, every top-level Elem, the first Elem)? 3. If there is magic, no matter what the rules are, someone will be confused (look through the archives relating to the newbie issue of not explicitly setting the return type of snippets to NodeSeq) So, I believe the default behavior is the correct behavior. If you want to add a helper that will copy attrs from the bound Elem to a newly provided Elem (not anything other than an Elem because of #2 above), you're a committer... you can add it. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Attributes question
Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Attributes question
On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Attributes question
The book seems to think it's intentional! But why can't unprefixed nodes by preserved automatically? Maybe there could be a setting? Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Attributes question
On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: The book seems to think it's intentional! I'm not sure how the code crept in, but it's wrong and should not have been part of Lift. But why can't unprefixed nodes by preserved automatically? I explained this above. Maybe there could be a setting? I explained this above as well. Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to
[Lift] Skip lift processing for single html file
Hi, How do I tell lift to serve /foo.html directly (without parsing xml or adding javascript) where foo.html is a file that lives in my webapp folder? I still want lift to process the rest of my html files. - Jon --~--~-~--~~~---~--~~ 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: Attributes question
Where above? Do mean when you said that binding is about inserting xml in well defined points? If so, I understand that, but it would be convenient if there was a simple way that SHtml inputs could take their attributes from the view. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: The book seems to think it's intentional! I'm not sure how the code crept in, but it's wrong and should not have been part of Lift. But why can't unprefixed nodes by preserved automatically? I explained this above. Maybe there could be a setting? I explained this above as well. Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala
[Lift] Re: Skip lift processing for single html file
LiftRules.liftRequest.append {
case Req(foo :: Nil, _, _) = false
}
On Fri, Aug 14, 2009 at 9:54 AM, jon jonhoff...@gmail.com wrote:
Hi,
How do I tell lift to serve /foo.html directly (without parsing xml
or adding javascript) where foo.html is a file that lives in my
webapp folder? I still want lift to process the rest of my html
files.
- Jon
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Attributes question
On Fri, Aug 14, 2009 at 9:55 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Where above? The contents of my messages send 35 minutes ago: This has nothing to do with snippets. This is below the level of the snippet. This is the operation of the bind() operation (if I understand your question correctly.) With a bind, you are replacing one Elem with a NodeSeq. There are plenty of helpers that allow you to do this. If you want to do something that's not provided by the helper, you can write a function and wrap it in a FuncBindParam to do things the way you want. Nothing in Lift is stopping that from happening. How, why is did I make the choice to do a pure substitution rather than doing something fancier by default: 1. You get what you bind rather than having some attributes magically added. 2. There's no requirement that you bind an Elem to an Elem... thus if you bind a NodeSeq, what's the correct behavior (adding attrs to every Elem, every top-level Elem, the first Elem)? 3. If there is magic, no matter what the rules are, someone will be confused (look through the archives relating to the newbie issue of not explicitly setting the return type of snippets to NodeSeq) So, I believe the default behavior is the correct behavior. If you want to add a helper that will copy attrs from the bound Elem to a newly provided Elem (not anything other than an Elem because of #2 above), you're a committer... you can add it. Do mean when you said that binding is about inserting xml in well defined points? If so, I understand that, but it would be convenient if there was a simple way that SHtml inputs could take their attributes from the view. As I said: *If you want to add a helper that will copy attrs from the bound Elem to a newly provided Elem (not anything other than an Elem because of #2 above), you're a committer... you can add it.* But more broadly (and this applies to everyone on the list), it's much better to speak in code rather than English. So, had you asked: bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) returns foo id=foo class=bar / but: bind(ledger, ledger:entry id=foo class=bar /, entry - foo/) returns foo/ Shouldn't it be the other way around? You would have expressed the same question, but I wouldn't have asked 3 times what you were talking about. You would have framed the question in a way I (and other folks on the list) could have understood it. Whether it's posting a ticket or asking a question, put together as much code as possible will help everyone understand what's going on, get on the same page, and get to a good answer. Thanks, David - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: The book seems to think it's intentional! I'm not sure how the code crept in, but it's wrong and should not have been part of Lift. But why can't unprefixed nodes by preserved automatically? I explained this above. Maybe there could be a setting? I explained this above as well. Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind
[Lift] Cookie not being removed for custom user logout
I'm seeing some odd behaviour with a cookie I'm setting not being
removed. I'm unsure which phase of my code is broken or how deep my
misunderstandings are here... so I'm looking for some clues.
I'm setting a keep me logged in cookie for users of my application.
That works fine using...
val c = HTTPCookie(COOKIE_NAME, encode(user)).setMaxAge(three_months_as_seconds)
S.addCookie(c)
The encode(user) is, when all is said and done, returning the user PK
as the cookie value.
I'm not using ProtoUser, I'm using the scheme outlined in
http://groups.google.com/group/liftweb/msg/85a8e790d5efec26
That is, I have...
object LoginContext {
object userId extends SessionVar[Box[Long]](KeepMeLoggedIn.findUserId)
// etc...
}
...and the findUserId function tries to decode the cookie and find a
matching user:
def findUserId:Box[Long] = for {
cookie - S.findCookie(COOKIE_NAME);
cookie_value - cookie.value;
(id, salt) - decode(cookie_value);
u - User.find(By(User.id, id),By(User.salt,salt))
} yield {
println(u)
id
}
And that's all working for me.
The problem comes when the user clicks the logout link, and I want to
remove this cookie.
The logout link is:
SHtml.link(/logout, LoginContext.logout, spanLogout/span )
... and LoginContext.logout is
KeepMeLoggedIn.removeCookie()
// the above is just: S.deleteCookie(COOKIE_NAME)
userId.remove()
currentUser.remove()
S.request.foreach(_.request.session.terminate)
And for completeness, my /logout page is a redirect to the home page:
Menu(Loc(logout, List(logout) - false, Logout, Hidden, If(
()=false, ()=RedirectResponse(/index)) ))
What I'm seeing is:
- user clicks logout
- logout function called, and Jetty tells me /logout took N
milliseconds to render
- then I'm seeing activity in the findUserId function, a result is
found, and the user is logged back in again.
- then Jetty tells me /index took N milliseconds to render.
When I dig into HTTP headers, I'm not seeing the cookie value being
set in the response header (which I believe is required to remove it).
I'm guessing my confusion is perhaps over how the SHtml.link magic works?
Any suggestions of where I might poke around next?
I'm using 1.1-SNAPSHOT (updated a few hours ago).
Thank you
Richard
--~--~-~--~~~---~--~~
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: Attributes question
I guess #2 was what I was looking for. :) I wrote some code that enables me to bind query % SHtml.text(clientQuery, clientQuery=_) which means you're actually binding to a function that preserves the input node's attributes. Does anyone like/dislike the syntax or feature? Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:55 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Where above? The contents of my messages send 35 minutes ago: This has nothing to do with snippets. This is below the level of the snippet. This is the operation of the bind() operation (if I understand your question correctly.) With a bind, you are replacing one Elem with a NodeSeq. There are plenty of helpers that allow you to do this. If you want to do something that's not provided by the helper, you can write a function and wrap it in a FuncBindParam to do things the way you want. Nothing in Lift is stopping that from happening. How, why is did I make the choice to do a pure substitution rather than doing something fancier by default: 1. You get what you bind rather than having some attributes magically added. 2. There's no requirement that you bind an Elem to an Elem... thus if you bind a NodeSeq, what's the correct behavior (adding attrs to every Elem, every top-level Elem, the first Elem)? 3. If there is magic, no matter what the rules are, someone will be confused (look through the archives relating to the newbie issue of not explicitly setting the return type of snippets to NodeSeq) So, I believe the default behavior is the correct behavior. If you want to add a helper that will copy attrs from the bound Elem to a newly provided Elem (not anything other than an Elem because of #2 above), you're a committer... you can add it. Do mean when you said that binding is about inserting xml in well defined points? If so, I understand that, but it would be convenient if there was a simple way that SHtml inputs could take their attributes from the view. As I said: *If you want to add a helper that will copy attrs from the bound Elem to a newly provided Elem (not anything other than an Elem because of #2 above), you're a committer... you can add it.* But more broadly (and this applies to everyone on the list), it's much better to speak in code rather than English. So, had you asked: bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) returns foo id=foo class=bar / but: bind(ledger, ledger:entry id=foo class=bar /, entry - foo/) returns foo/ Shouldn't it be the other way around? You would have expressed the same question, but I wouldn't have asked 3 times what you were talking about. You would have framed the question in a way I (and other folks on the list) could have understood it. Whether it's posting a ticket or asking a question, put together as much code as possible will help everyone understand what's going on, get on the same page, and get to a good answer. Thanks, David - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: The book seems to think it's intentional! I'm not sure how the code crept in, but it's wrong and should not have been part of Lift. But why can't unprefixed nodes by preserved automatically? I explained this above. Maybe there could be a setting? I explained this above as well. Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived...
[Lift] ws-generated code in lift
Tim, Viktor, Do you wire your SOAP services into lift or do you keep that independent? i was just talking to DPP and according to him it appears you can successfully wire WS-generated code anywhere along in the http-request processing pipeline. He pointed out a gotcha that i think can be circumvented with HttpServletResponse trampoline. Both lift and the WS-generated code are likely to want to be in the driver's seat regarding who's returning the bytes. But, i think you can just fool the WS-generated code into thinking it's got an HttpServletResponse that is really a widget that will just write into the one lift returns. In this way you can write a 1-size-fits-all return adapter. Is this what you guys are doing, or am i making this too complicated? Best wishes, --greg -- 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: Symlinks and Javascript Files
It is not in my site map. I did try the ResourceServer with the
symlinked script in the 'js' subdir.
Peter
On Aug 14, 6:43 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
Is the path to that file defined in your SiteMap? In the case of using
ResourceServer, the js that you've tried means that the script should be
under a js subdir.
Derek
On Thu, Aug 13, 2009 at 7:57 PM, Peter Robinett
pe...@bubblefoundry.comwrote:
My Lift project is in a git repository and to the repository I've
added a submodule. Since right now I only want one javascript file
from this submodule, my thought was to make the directory src/main/
webroot/js and then make a symbolic link to the javascript file in
question. Unfortunately, when I try to request the file at
http://localhost:9090/js/jquery.sparkline.js, I get a 403 response
that says the page is not defined in my sitemap. There was no note of
the request in the stdout.
Thinking that the js subdirectory is the problem, I then tried making
the symlink in the webroot directory and got a 404 error. On stdout it
said:
2009-08-13 18:38:23.051::WARN: Aliased resource: file:/Users/peter/
Sites/Equal%20Networks/server/src/main/webapp/
jquery.sparkline.js==file:/Users/peter/Sites/Equal%20Networks/server/
vendors/dashboard/www/jquery.sparkline.js
From this I gather than Lift is troubled by the presence of a symlink
and refused to acknowledge its presence. Is this true? If so, why?
From the thread last week on ExtJS I see a discussion on loading files
in webroot, including supporting a css directory by adding the
following to Boot.scala:
ResourceServer.allow {
case css :: _ = true
}
I already have a css file being served from a directory in the exact
same location without any additions to Boot.scala. Nonetheless, I
tried the following:
ResourceServer.allow {
case js :: _ = true
}
Unfortunately, this had no effect. So, how can I get my symlinked
javascript to be server? Or should I just give up on symlinks
altogether (I'm not a git master, so perhaps that was the wrong
approach anyway).
Peter Robinett
PS I'm on 1.1-SNAPSHOT.
PPS The YUI Compressor works well. Very cool.
--~--~-~--~~~---~--~~
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: Attributes question
By the way, there does seem to be some other kind of built in attribute binding mechanism (BindWithAttr, etc.). How does it work? - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:55 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Where above? The contents of my messages send 35 minutes ago: This has nothing to do with snippets. This is below the level of the snippet. This is the operation of the bind() operation (if I understand your question correctly.) With a bind, you are replacing one Elem with a NodeSeq. There are plenty of helpers that allow you to do this. If you want to do something that's not provided by the helper, you can write a function and wrap it in a FuncBindParam to do things the way you want. Nothing in Lift is stopping that from happening. How, why is did I make the choice to do a pure substitution rather than doing something fancier by default: 1. You get what you bind rather than having some attributes magically added. 2. There's no requirement that you bind an Elem to an Elem... thus if you bind a NodeSeq, what's the correct behavior (adding attrs to every Elem, every top-level Elem, the first Elem)? 3. If there is magic, no matter what the rules are, someone will be confused (look through the archives relating to the newbie issue of not explicitly setting the return type of snippets to NodeSeq) So, I believe the default behavior is the correct behavior. If you want to add a helper that will copy attrs from the bound Elem to a newly provided Elem (not anything other than an Elem because of #2 above), you're a committer... you can add it. Do mean when you said that binding is about inserting xml in well defined points? If so, I understand that, but it would be convenient if there was a simple way that SHtml inputs could take their attributes from the view. As I said: *If you want to add a helper that will copy attrs from the bound Elem to a newly provided Elem (not anything other than an Elem because of #2 above), you're a committer... you can add it.* But more broadly (and this applies to everyone on the list), it's much better to speak in code rather than English. So, had you asked: bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) returns foo id=foo class=bar / but: bind(ledger, ledger:entry id=foo class=bar /, entry - foo/) returns foo/ Shouldn't it be the other way around? You would have expressed the same question, but I wouldn't have asked 3 times what you were talking about. You would have framed the question in a way I (and other folks on the list) could have understood it. Whether it's posting a ticket or asking a question, put together as much code as possible will help everyone understand what's going on, get on the same page, and get to a good answer. Thanks, David - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: The book seems to think it's intentional! I'm not sure how the code crept in, but it's wrong and should not have been part of Lift. But why can't unprefixed nodes by preserved automatically? I explained this above. Maybe there could be a setting? I explained this above as well. Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet
[Lift] Re: Attributes question
The book exposes current functionality for Lift 1.0. If functionality X was not intended to be there is a different story, but regardless it is there and the way I see it it is OK to be in the book. Personally I don't see it as defect as preserving attributes (to the top level resulting NodeSeq) may be quite handy in certain situations even that contradicts David's design intent. But this is just a personal opinion. After David removes this, a helper to copy attributes is needed IMO. So Naftoli if you want to do this please go ahead ... or if you don't want it I'll do it. Br's, Marius On Aug 14, 7:43 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: The book seems to think it's intentional! But why can't unprefixed nodes by preserved automatically? Maybe there could be a setting? Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- 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 -- 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 -- 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
[Lift] Re: Attributes question
As I mentioned, I wrote some code that allows you to use % instead of - to preserve the attributes. (I chose it because the % symbol is used to merge attributes to an Elem.) The right side can be an Elem or a Box/Option of an Elem. What do people think of this syntax? P.S. Another way is to append .%% to an Elem making it into a NodeSeq function. - marius d.marius.dan...@gmail.com wrote: The book exposes current functionality for Lift 1.0. If functionality X was not intended to be there is a different story, but regardless it is there and the way I see it it is OK to be in the book. Personally I don't see it as defect as preserving attributes (to the top level resulting NodeSeq) may be quite handy in certain situations even that contradicts David's design intent. But this is just a personal opinion. After David removes this, a helper to copy attributes is needed IMO. So Naftoli if you want to do this please go ahead ... or if you don't want it I'll do it. Br's, Marius On Aug 14, 7:43 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: The book seems to think it's intentional! But why can't unprefixed nodes by preserved automatically? Maybe there could be a setting? Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Exactly! - Derek Chen-Beckerdchenbec...@gmail.com wrote: Basically, you're asking why a bind tag like ledger:entry id=foo class=bar / doesn't preserve the id and class attrs when it binds, but ledger:entry ledger:id=foo ledger:class=bar / does? If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /, entry - foo/) results in anything other than foo/ it's a defect. Wow... looks like it does... it's a defect and I'll fix it. Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: What I would like to do: label for=nameName/labelnbsp;person:name I'd=name size=10 class=special style=vertical-align: top maxlength=5 tabindex=1 / Okay, just a little contrived... My understanding is you can do this by prefixing the attribute with lift:; otherwise it will not be output but is available to the snippet code, i.e., without the prefix you are making an attribute available to the snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to person:name/ and add the attributes in the person:name / element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null I'm getting this from Exploring Lift page 115. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Why was the decision made, if I understand correctly, that normal attributes are not preserved in a bound node, and are are only available for the snippet's usage, and if you want the attribute to be sticky you have to prefix it with lift:? Wouldn't it be better the other way? I don't understand your question. Are you talking about Helpers.bind() or are you talking about snippet dispatching? Can you please provide an example of what happens now and what you would expect to happen? One of lift's design goals is to help keep the static html in the view and the logic in the code, and to provide a templating system that doesn't interfere with visual web designers. It seems to me that it would further this goal if html attributes could be properly specified in the view html. -- 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 -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git
[Lift] Re: Attributes question
IMHO:
The problem with
name some_new_operator_beside_- expr
would lead to a handful of overloading as - in SuperArrowAssoc. Looks
a little messy to me.
Looks like we already have a way to do this:
import Helpers._
name - {node: NodeSeq = mixinAttributes(expr _that_yields_an_Elem)
(node)}
Would that be too ... boilerplate for you?
Br's,
Marius
On Aug 14, 11:18 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
As I mentioned, I wrote some code that allows you to use % instead of - to
preserve the attributes. (I chose it because the % symbol is used to merge
attributes to an Elem.) The right side can be an Elem or a Box/Option of an
Elem.
What do people think of this syntax?
P.S. Another way is to append .%% to an Elem making it into a NodeSeq
function.
-
marius d.marius.dan...@gmail.com wrote:
The book exposes current functionality for Lift 1.0. If functionality
X was not intended to be there is a different story, but regardless it
is there and the way I see it it is OK to be in the book.
Personally I don't see it as defect as preserving attributes (to the
top level resulting NodeSeq) may be quite handy in certain situations
even that contradicts David's design intent. But this is just a
personal opinion. After David removes this, a helper to copy
attributes is needed IMO. So Naftoli if you want to do this please go
ahead ... or if you don't want it I'll do it.
Br's,
Marius
On Aug 14, 7:43 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
The book seems to think it's intentional!
But why can't unprefixed nodes by preserved automatically? Maybe there
could be a setting?
Thanks.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
Exactly!
-
Derek Chen-Beckerdchenbec...@gmail.com wrote:
Basically, you're asking why a bind tag like
ledger:entry id=foo class=bar /
doesn't preserve the id and class attrs when it binds, but
ledger:entry ledger:id=foo ledger:class=bar /
does?
If bind(ledger, ledger:entry ledger:id=foo ledger:class=bar /,
entry - foo/)
results in anything other than foo/ it's a defect.
Wow... looks like it does... it's a defect and I'll fix it.
Derek
On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim naftoli...@gmail.com
wrote:
Of course you can access it from the snippet. But if you want it to be
output automatically, then you prefix it with whatever the node's prefix
is.
In other words, by default it's not outputted.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim naftoli...@gmail.com
wrote:
What I would like to do:
label for=nameName/labelnbsp;person:name I'd=name size=10
class=special style=vertical-align: top maxlength=5 tabindex=1
/
Okay, just a little contrived...
My understanding is you can do this by prefixing the attribute with
lift:; otherwise it will not be output but is available to the
snippet
code, i.e., without the prefix you are making an attribute available
to
the
snippet but that's it.
I'm sorry, but I'm still clueless about what you're talking about.
Do you want to bind to person:name/ and add the attributes in the
person:name / element to the resulting element?
The lift prefix has nothing to do with binding. Binding is done in
net.liftweb.util and is purely a way of substituting dynamic XML into
well
defined points in a NodeSeq.
So... if you want to include the attributes of an Elem that you are
replacing during a bind operation, you have access to the current node
via
Helpers.currentNode: Box[Elem] and you can get the attributes:
currentNode.map(_.attributes) openOr Null
I'm getting this from Exploring Lift page 115.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
Why was the decision made, if I understand correctly, that normal
attributes are not preserved in a bound node, and are are only
available
for
the snippet's usage, and if you want the attribute to be sticky
you
have
to prefix it with lift:? Wouldn't it be better the other way?
I don't understand your question. Are you talking about
Helpers.bind()
or
are you talking about snippet dispatching?
Can you please provide an example of what happens now and what you
would
expect to happen?
One of lift's design goals is to help keep the static html in the
view
and
the logic in the code, and to provide a templating system that
doesn't
interfere with
[Lift] Redirecting during stateful snippet instantiation
I have a stateful snippet:
class TemplateEditor
extends StatefulSnippet
{
...
val template =
(TemplateEditor.template.is
openOr
S.redirectTo(chooser, () = {
S.error(Session information lost, please choose what
template to edit again)
}))
...
}
with a companion object holding a RequestVar:
object TemplateEditor
{
/** Request var that is populated with what template is under
edit */
object template extends RequestVar[Box[Template]](Empty)
...
}
The flow is that another page with snippet chooses a template to edit,
and then uses:
S.redirectTo(/editor, () =
{ TemplateEditor.template(Full(template)) })
to stuff the template to edit into the RequestVar. I'd like for the
state of TemplateEditor to
use the value of the RequestVar, but not to require every link to re-
stuff that RequestVar once
the StatefulSnippet has been instantiated, and not require each
snippet method to be wrapped
with the logic to check the RequestVar and do the redirect if it's not
populated.
The problem I'm running into is that snippet instantiation is
apparently too early to use
S.redirectTo -- the Shortcut exception is being trapped as an
instantiation exception and not
being used as a redirect.
It doesn't look entirely trivial to touch up LiftSession to pass this
through, so I guess
I'm partly soliciting feedback on whether there's a better pattern to
use here (lazy val?) and
partly asking if the behavior as it stands is desired.
Thanks,
-Ross
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Redirecting during stateful snippet instantiation
Not sure if I read your message closely enough, but if you want to redirect to
a pre-initialized StatefulSnippet, one option is to instantiate it and use its
snippet function in call to S.mapSnippet, in the redirect function. This will
override lift's default behavior and use the snippet function to process the
page being redirected to.
-
Ross Mellgrendri...@gmail.com wrote:
I have a stateful snippet:
class TemplateEditor
extends StatefulSnippet
{
...
val template =
(TemplateEditor.template.is
openOr
S.redirectTo(chooser, () = {
S.error(Session information lost, please choose what
template to edit again)
}))
...
}
with a companion object holding a RequestVar:
object TemplateEditor
{
/** Request var that is populated with what template is under
edit */
object template extends RequestVar[Box[Template]](Empty)
...
}
The flow is that another page with snippet chooses a template to edit,
and then uses:
S.redirectTo(/editor, () =
{ TemplateEditor.template(Full(template)) })
to stuff the template to edit into the RequestVar. I'd like for the
state of TemplateEditor to
use the value of the RequestVar, but not to require every link to re-
stuff that RequestVar once
the StatefulSnippet has been instantiated, and not require each
snippet method to be wrapped
with the logic to check the RequestVar and do the redirect if it's not
populated.
The problem I'm running into is that snippet instantiation is
apparently too early to use
S.redirectTo -- the Shortcut exception is being trapped as an
instantiation exception and not
being used as a redirect.
It doesn't look entirely trivial to touch up LiftSession to pass this
through, so I guess
I'm partly soliciting feedback on whether there's a better pattern to
use here (lazy val?) and
partly asking if the behavior as it stands is desired.
Thanks,
-Ross
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Redirecting during stateful snippet instantiation
The missing piece there is that I would like it to redirect to another
page if the RequestVar is not populated. With mapSnippet, it sounds
like I'd have to have a dummy snippet with the same shape as the
original snippet where all the snippets redirect, e.g.
class InitializedTemplateEditor(template: Template)
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doOne _
case two = doTwo _
...
}
...
}
class TemplateEditor /* named TemplateEditor so that HTML templates
will use this unless mapSnippet has overridden */
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doRedirect _
case two = doRedirect _
...
}
def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo(chooser, ()
= { S.error(Session information lost, please choose what template to
edit again) })
}
and then some helper to map all the individual dispatches
object TemplateEditor
{
def redirectToEditor(template: Template) = {
val editor = InitializedTemplateEditor(template)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
...
S.redirectTo(/editor)
}
}
which seems pretty wordy. In this case I think I'd prefer lazy vals /
boxes as state. Also, the docs for S.mapSnippet claim per-session, but
the docs for S.snippetMap (which mapSnippet uses) claim per-request,
so it might be even more onerous.
-Ross
On Aug 14, 2009, at 5:30 PM, Naftoli Gugenheim wrote:
Not sure if I read your message closely enough, but if you want to
redirect to a pre-initialized StatefulSnippet, one option is to
instantiate it and use its snippet function in call to S.mapSnippet,
in the redirect function. This will override lift's default behavior
and use the snippet function to process the page being redirected to.
-
Ross Mellgrendri...@gmail.com wrote:
I have a stateful snippet:
class TemplateEditor
extends StatefulSnippet
{
...
val template =
(TemplateEditor.template.is
openOr
S.redirectTo(chooser, () = {
S.error(Session information lost, please choose what
template to edit again)
}))
...
}
with a companion object holding a RequestVar:
object TemplateEditor
{
/** Request var that is populated with what template is under
edit */
object template extends RequestVar[Box[Template]](Empty)
...
}
The flow is that another page with snippet chooses a template to edit,
and then uses:
S.redirectTo(/editor, () =
{ TemplateEditor.template(Full(template)) })
to stuff the template to edit into the RequestVar. I'd like for the
state of TemplateEditor to
use the value of the RequestVar, but not to require every link to re-
stuff that RequestVar once
the StatefulSnippet has been instantiated, and not require each
snippet method to be wrapped
with the logic to check the RequestVar and do the redirect if it's not
populated.
The problem I'm running into is that snippet instantiation is
apparently too early to use
S.redirectTo -- the Shortcut exception is being trapped as an
instantiation exception and not
being used as a redirect.
It doesn't look entirely trivial to touch up LiftSession to pass this
through, so I guess
I'm partly soliciting feedback on whether there's a better pattern to
use here (lazy val?) and
partly asking if the behavior as it stands is desired.
Thanks,
-Ross
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: ws-generated code in lift
I agree with Viktor - in a similar vein, this is exactly what I implemented with Akka; the servlet runs in conjunction with lifts filter and lift just hands off stuff it doesnt know what to do with. So if you want to use AxisServlet or whatever its real easy. From my point of view, you'd need a good reason to bring the SOAP stuff into lift; right now i havent found one... I write a lot of lift apps that consume SOAP services, but as yet have no good reason to write a SOAP serving app with lift - If i were to do one, id do exactly as with the JAX-RS stuff in Akka and passNotFoundToChain. Cheers, Tim On Aug 14, 10:24 pm, Viktor Klang viktor.kl...@gmail.com wrote: Gregory, Depending on what WS-* stuff you're using, you _should_ be able to wire the AxisServlet in web.xml under /ws/* or something like that, and then have lift passNotFoundToChain=true But I guess it boils down to what liftiness you're planning to do. Can you elaborate a bit on what you're aiming for? On Fri, Aug 14, 2009 at 9:00 PM, Meredith Gregory lgreg.mered...@gmail.comwrote: Tim, Viktor, Do you wire your SOAP services into lift or do you keep that independent? i was just talking to DPP and according to him it appears you can successfully wire WS-generated code anywhere along in the http-request processing pipeline. He pointed out a gotcha that i think can be circumvented with HttpServletResponse trampoline. Both lift and the WS-generated code are likely to want to be in the driver's seat regarding who's returning the bytes. But, i think you can just fool the WS-generated code into thinking it's got an HttpServletResponse that is really a widget that will just write into the one lift returns. In this way you can write a 1-size-fits-all return adapter. Is this what you guys are doing, or am i making this too complicated? Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com -- Viktor Klang Rogue Scala-head Blog: klangism.blogspot.com Twttr: viktorklang --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Redirecting during stateful snippet instantiation
I think it's a mistake, and it's per request. Could someone confirm?
In any case, I don't see why you need a separate template class or a RequesVar.
Just use an Option or Box var in your snippet, and let it redirect whenever
it's None/Empty. You can put the check in the dispatch partial function, in the
snippet functions, or in a def dispatch that if it's empty returns a case _ =
redirectTo ... PF.
I'm not sure if I'm missing something, but I've been doing something similar
(if not more complex):
When editing a Request you can go to the Client edit or search page, both of
which return to the Request screen with its state intact. The edit page is
populated with the current Client. The search page can also branch to the
client edit page, either editing an existing client or editing a new unsaved
client based on the search criteria. Editing returns to the search page while
saving a new Client returns to the Request page. This is all using
StatefulSnippets defined once and mapSnippet etc., except for ClientSearch
which isn't a snippet and so uses RequestVars.
-
Ross Mellgrendri...@gmail.com wrote:
The missing piece there is that I would like it to redirect to another
page if the RequestVar is not populated. With mapSnippet, it sounds
like I'd have to have a dummy snippet with the same shape as the
original snippet where all the snippets redirect, e.g.
class InitializedTemplateEditor(template: Template)
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doOne _
case two = doTwo _
...
}
...
}
class TemplateEditor /* named TemplateEditor so that HTML templates
will use this unless mapSnippet has overridden */
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doRedirect _
case two = doRedirect _
...
}
def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo(chooser, ()
= { S.error(Session information lost, please choose what template to
edit again) })
}
and then some helper to map all the individual dispatches
object TemplateEditor
{
def redirectToEditor(template: Template) = {
val editor = InitializedTemplateEditor(template)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
...
S.redirectTo(/editor)
}
}
which seems pretty wordy. In this case I think I'd prefer lazy vals /
boxes as state. Also, the docs for S.mapSnippet claim per-session, but
the docs for S.snippetMap (which mapSnippet uses) claim per-request,
so it might be even more onerous.
-Ross
On Aug 14, 2009, at 5:30 PM, Naftoli Gugenheim wrote:
Not sure if I read your message closely enough, but if you want to
redirect to a pre-initialized StatefulSnippet, one option is to
instantiate it and use its snippet function in call to S.mapSnippet,
in the redirect function. This will override lift's default behavior
and use the snippet function to process the page being redirected to.
-
Ross Mellgrendri...@gmail.com wrote:
I have a stateful snippet:
class TemplateEditor
extends StatefulSnippet
{
...
val template =
(TemplateEditor.template.is
openOr
S.redirectTo(chooser, () = {
S.error(Session information lost, please choose what
template to edit again)
}))
...
}
with a companion object holding a RequestVar:
object TemplateEditor
{
/** Request var that is populated with what template is under
edit */
object template extends RequestVar[Box[Template]](Empty)
...
}
The flow is that another page with snippet chooses a template to edit,
and then uses:
S.redirectTo(/editor, () =
{ TemplateEditor.template(Full(template)) })
to stuff the template to edit into the RequestVar. I'd like for the
state of TemplateEditor to
use the value of the RequestVar, but not to require every link to re-
stuff that RequestVar once
the StatefulSnippet has been instantiated, and not require each
snippet method to be wrapped
with the logic to check the RequestVar and do the redirect if it's not
populated.
The problem I'm running into is that snippet instantiation is
apparently too early to use
S.redirectTo -- the Shortcut exception is being trapped as an
instantiation exception and not
being used as a redirect.
It doesn't look entirely trivial to touch up LiftSession to pass this
through, so I guess
I'm partly soliciting feedback on whether there's a better pattern to
use here (lazy val?) and
partly asking if the behavior as it stands is desired.
Thanks,
-Ross
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
[Lift] Re: Redirecting during stateful snippet instantiation
The problem with the Box is unwrapping it in every snippet method,
when I really want to guarantee that if the StatefulSnippet is
instantiated, it has these parameters. Moreover, I have additional
pieces of state which need to be initialized based on the other
parameters.
For this particular snippet, I put a hack into place based on your
note about the dispatch function... there's a risk of NPE, but it
should work okay:
class TemplateEditor
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case _ if (template == null) = S.redirectTo(chooser, () = {
S.error(Session information lost, please choose what
template to edit again)
})
...
}
val template = TemplateEditor.template.is.openOr(null) // eww
lazy val imageFuncBinding = S.fmapFunc[String](() =
{ TemplateEditor.template(Full(template)) })(identity)
}
the key part is that I needed to make derived state lazy (so that if
it happens to be null I don't NPE early) and just ensure that no calls
will enter that are before dispatch gets called. Seems a bit ugly, but
at least I don't have to pass all my state down to the snippet methods
by hand.
You refer to Request, Client, etc, which don't mean anything to me.
What are you talking about?
-Ross
On Aug 14, 2009, at 6:27 PM, Naftoli Gugenheim wrote:
I think it's a mistake, and it's per request. Could someone confirm?
In any case, I don't see why you need a separate template class or a
RequesVar. Just use an Option or Box var in your snippet, and let it
redirect whenever it's None/Empty. You can put the check in the
dispatch partial function, in the snippet functions, or in a def
dispatch that if it's empty returns a case _ = redirectTo ... PF.
I'm not sure if I'm missing something, but I've been doing something
similar (if not more complex):
When editing a Request you can go to the Client edit or search page,
both of which return to the Request screen with its state intact.
The edit page is populated with the current Client. The search page
can also branch to the client edit page, either editing an existing
client or editing a new unsaved client based on the search criteria.
Editing returns to the search page while saving a new Client returns
to the Request page. This is all using StatefulSnippets defined once
and mapSnippet etc., except for ClientSearch which isn't a snippet
and so uses RequestVars.
-
Ross Mellgrendri...@gmail.com wrote:
The missing piece there is that I would like it to redirect to another
page if the RequestVar is not populated. With mapSnippet, it sounds
like I'd have to have a dummy snippet with the same shape as the
original snippet where all the snippets redirect, e.g.
class InitializedTemplateEditor(template: Template)
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doOne _
case two = doTwo _
...
}
...
}
class TemplateEditor /* named TemplateEditor so that HTML templates
will use this unless mapSnippet has overridden */
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doRedirect _
case two = doRedirect _
...
}
def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo(chooser, ()
= { S.error(Session information lost, please choose what template to
edit again) })
}
and then some helper to map all the individual dispatches
object TemplateEditor
{
def redirectToEditor(template: Template) = {
val editor = InitializedTemplateEditor(template)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
...
S.redirectTo(/editor)
}
}
which seems pretty wordy. In this case I think I'd prefer lazy vals /
boxes as state. Also, the docs for S.mapSnippet claim per-session, but
the docs for S.snippetMap (which mapSnippet uses) claim per-request,
so it might be even more onerous.
-Ross
On Aug 14, 2009, at 5:30 PM, Naftoli Gugenheim wrote:
Not sure if I read your message closely enough, but if you want to
redirect to a pre-initialized StatefulSnippet, one option is to
instantiate it and use its snippet function in call to S.mapSnippet,
in the redirect function. This will override lift's default behavior
and use the snippet function to process the page being redirected to.
-
Ross Mellgrendri...@gmail.com wrote:
I have a stateful snippet:
class TemplateEditor
extends StatefulSnippet
{
...
val template =
(TemplateEditor.template.is
openOr
S.redirectTo(chooser, () = {
S.error(Session information lost, please choose what
template to edit again)
}))
...
}
with a companion object holding a RequestVar:
object TemplateEditor
{
/** Request var that is populated with what
[Lift] Re: Redirecting during stateful snippet instantiation
They're just names of pages in my app which have a similar functionality.
Anyway, one method you can use is:
Make your snippet functions actually have a parameter list before the xhtml
parameter list:
def edit(x: X)(xhtml: NodeSeq) = ...
or alternatively
def edit(x: X) = (xhtml: NodeSeq) = ...
where x is the optional data.
Then change dispatch from a val to a def, which should pattern match on whether
you have a Full(x) or not; if yes it will return a disatch PF that returns
something like edit(x) _, in other words, a snippet function that knows an X;
and if it's empty it will return another PF that just redirects.
-
Ross Mellgrendri...@gmail.com wrote:
The problem with the Box is unwrapping it in every snippet method,
when I really want to guarantee that if the StatefulSnippet is
instantiated, it has these parameters. Moreover, I have additional
pieces of state which need to be initialized based on the other
parameters.
For this particular snippet, I put a hack into place based on your
note about the dispatch function... there's a risk of NPE, but it
should work okay:
class TemplateEditor
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case _ if (template == null) = S.redirectTo(chooser, () = {
S.error(Session information lost, please choose what
template to edit again)
})
...
}
val template = TemplateEditor.template.is.openOr(null) // eww
lazy val imageFuncBinding = S.fmapFunc[String](() =
{ TemplateEditor.template(Full(template)) })(identity)
}
the key part is that I needed to make derived state lazy (so that if
it happens to be null I don't NPE early) and just ensure that no calls
will enter that are before dispatch gets called. Seems a bit ugly, but
at least I don't have to pass all my state down to the snippet methods
by hand.
You refer to Request, Client, etc, which don't mean anything to me.
What are you talking about?
-Ross
On Aug 14, 2009, at 6:27 PM, Naftoli Gugenheim wrote:
I think it's a mistake, and it's per request. Could someone confirm?
In any case, I don't see why you need a separate template class or a
RequesVar. Just use an Option or Box var in your snippet, and let it
redirect whenever it's None/Empty. You can put the check in the
dispatch partial function, in the snippet functions, or in a def
dispatch that if it's empty returns a case _ = redirectTo ... PF.
I'm not sure if I'm missing something, but I've been doing something
similar (if not more complex):
When editing a Request you can go to the Client edit or search page,
both of which return to the Request screen with its state intact.
The edit page is populated with the current Client. The search page
can also branch to the client edit page, either editing an existing
client or editing a new unsaved client based on the search criteria.
Editing returns to the search page while saving a new Client returns
to the Request page. This is all using StatefulSnippets defined once
and mapSnippet etc., except for ClientSearch which isn't a snippet
and so uses RequestVars.
-
Ross Mellgrendri...@gmail.com wrote:
The missing piece there is that I would like it to redirect to another
page if the RequestVar is not populated. With mapSnippet, it sounds
like I'd have to have a dummy snippet with the same shape as the
original snippet where all the snippets redirect, e.g.
class InitializedTemplateEditor(template: Template)
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doOne _
case two = doTwo _
...
}
...
}
class TemplateEditor /* named TemplateEditor so that HTML templates
will use this unless mapSnippet has overridden */
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doRedirect _
case two = doRedirect _
...
}
def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo(chooser, ()
= { S.error(Session information lost, please choose what template to
edit again) })
}
and then some helper to map all the individual dispatches
object TemplateEditor
{
def redirectToEditor(template: Template) = {
val editor = InitializedTemplateEditor(template)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
...
S.redirectTo(/editor)
}
}
which seems pretty wordy. In this case I think I'd prefer lazy vals /
boxes as state. Also, the docs for S.mapSnippet claim per-session, but
the docs for S.snippetMap (which mapSnippet uses) claim per-request,
so it might be even more onerous.
-Ross
On Aug 14, 2009, at 5:30 PM, Naftoli Gugenheim wrote:
Not sure if I read your message closely enough, but if you want to
redirect to a pre-initialized StatefulSnippet, one option is to
instantiate it and
[Lift] Re: Redirecting during stateful snippet instantiation
Or you could define a def that returns it unboxed if possible or else redirects
the first time its accessed.
-
Ross Mellgrendri...@gmail.com wrote:
Yeah, I don't want to do that because then I have to either modify all
the snippet methods to handle the state or treat each snippet method
differently depending on which state I know it needs, and then also
pass down any state the snippet methods receive to any helper methods
they might call. Overall, I'd just rather have the state as locals and
non-Boxed to cut down on typing and extra crud.
-Ross
On Aug 14, 2009, at 7:09 PM, Naftoli Gugenheim wrote:
They're just names of pages in my app which have a similar
functionality.
Anyway, one method you can use is:
Make your snippet functions actually have a parameter list before
the xhtml parameter list:
def edit(x: X)(xhtml: NodeSeq) = ...
or alternatively
def edit(x: X) = (xhtml: NodeSeq) = ...
where x is the optional data.
Then change dispatch from a val to a def, which should pattern match
on whether you have a Full(x) or not; if yes it will return a
disatch PF that returns something like edit(x) _, in other words, a
snippet function that knows an X; and if it's empty it will return
another PF that just redirects.
-
Ross Mellgrendri...@gmail.com wrote:
The problem with the Box is unwrapping it in every snippet method,
when I really want to guarantee that if the StatefulSnippet is
instantiated, it has these parameters. Moreover, I have additional
pieces of state which need to be initialized based on the other
parameters.
For this particular snippet, I put a hack into place based on your
note about the dispatch function... there's a risk of NPE, but it
should work okay:
class TemplateEditor
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case _ if (template == null) = S.redirectTo(chooser, ()
= {
S.error(Session information lost, please choose what
template to edit again)
})
...
}
val template = TemplateEditor.template.is.openOr(null) // eww
lazy val imageFuncBinding = S.fmapFunc[String](() =
{ TemplateEditor.template(Full(template)) })(identity)
}
the key part is that I needed to make derived state lazy (so that if
it happens to be null I don't NPE early) and just ensure that no calls
will enter that are before dispatch gets called. Seems a bit ugly, but
at least I don't have to pass all my state down to the snippet methods
by hand.
You refer to Request, Client, etc, which don't mean anything to me.
What are you talking about?
-Ross
On Aug 14, 2009, at 6:27 PM, Naftoli Gugenheim wrote:
I think it's a mistake, and it's per request. Could someone confirm?
In any case, I don't see why you need a separate template class or a
RequesVar. Just use an Option or Box var in your snippet, and let it
redirect whenever it's None/Empty. You can put the check in the
dispatch partial function, in the snippet functions, or in a def
dispatch that if it's empty returns a case _ = redirectTo ... PF.
I'm not sure if I'm missing something, but I've been doing something
similar (if not more complex):
When editing a Request you can go to the Client edit or search page,
both of which return to the Request screen with its state intact.
The edit page is populated with the current Client. The search page
can also branch to the client edit page, either editing an existing
client or editing a new unsaved client based on the search criteria.
Editing returns to the search page while saving a new Client returns
to the Request page. This is all using StatefulSnippets defined once
and mapSnippet etc., except for ClientSearch which isn't a snippet
and so uses RequestVars.
-
Ross Mellgrendri...@gmail.com wrote:
The missing piece there is that I would like it to redirect to
another
page if the RequestVar is not populated. With mapSnippet, it sounds
like I'd have to have a dummy snippet with the same shape as the
original snippet where all the snippets redirect, e.g.
class InitializedTemplateEditor(template: Template)
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doOne _
case two = doTwo _
...
}
...
}
class TemplateEditor /* named TemplateEditor so that HTML templates
will use this unless mapSnippet has overridden */
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doRedirect _
case two = doRedirect _
...
}
def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo(chooser, ()
= { S.error(Session information lost, please choose what template
to
edit again) })
}
and then some helper to map all the individual dispatches
object TemplateEditor
{
def redirectToEditor(template: Template) = {
val editor =
[Lift] Re: Redirecting during stateful snippet instantiation
Yeah, I don't want to do that because then I have to either modify all
the snippet methods to handle the state or treat each snippet method
differently depending on which state I know it needs, and then also
pass down any state the snippet methods receive to any helper methods
they might call. Overall, I'd just rather have the state as locals and
non-Boxed to cut down on typing and extra crud.
-Ross
On Aug 14, 2009, at 7:09 PM, Naftoli Gugenheim wrote:
They're just names of pages in my app which have a similar
functionality.
Anyway, one method you can use is:
Make your snippet functions actually have a parameter list before
the xhtml parameter list:
def edit(x: X)(xhtml: NodeSeq) = ...
or alternatively
def edit(x: X) = (xhtml: NodeSeq) = ...
where x is the optional data.
Then change dispatch from a val to a def, which should pattern match
on whether you have a Full(x) or not; if yes it will return a
disatch PF that returns something like edit(x) _, in other words, a
snippet function that knows an X; and if it's empty it will return
another PF that just redirects.
-
Ross Mellgrendri...@gmail.com wrote:
The problem with the Box is unwrapping it in every snippet method,
when I really want to guarantee that if the StatefulSnippet is
instantiated, it has these parameters. Moreover, I have additional
pieces of state which need to be initialized based on the other
parameters.
For this particular snippet, I put a hack into place based on your
note about the dispatch function... there's a risk of NPE, but it
should work okay:
class TemplateEditor
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case _ if (template == null) = S.redirectTo(chooser, ()
= {
S.error(Session information lost, please choose what
template to edit again)
})
...
}
val template = TemplateEditor.template.is.openOr(null) // eww
lazy val imageFuncBinding = S.fmapFunc[String](() =
{ TemplateEditor.template(Full(template)) })(identity)
}
the key part is that I needed to make derived state lazy (so that if
it happens to be null I don't NPE early) and just ensure that no calls
will enter that are before dispatch gets called. Seems a bit ugly, but
at least I don't have to pass all my state down to the snippet methods
by hand.
You refer to Request, Client, etc, which don't mean anything to me.
What are you talking about?
-Ross
On Aug 14, 2009, at 6:27 PM, Naftoli Gugenheim wrote:
I think it's a mistake, and it's per request. Could someone confirm?
In any case, I don't see why you need a separate template class or a
RequesVar. Just use an Option or Box var in your snippet, and let it
redirect whenever it's None/Empty. You can put the check in the
dispatch partial function, in the snippet functions, or in a def
dispatch that if it's empty returns a case _ = redirectTo ... PF.
I'm not sure if I'm missing something, but I've been doing something
similar (if not more complex):
When editing a Request you can go to the Client edit or search page,
both of which return to the Request screen with its state intact.
The edit page is populated with the current Client. The search page
can also branch to the client edit page, either editing an existing
client or editing a new unsaved client based on the search criteria.
Editing returns to the search page while saving a new Client returns
to the Request page. This is all using StatefulSnippets defined once
and mapSnippet etc., except for ClientSearch which isn't a snippet
and so uses RequestVars.
-
Ross Mellgrendri...@gmail.com wrote:
The missing piece there is that I would like it to redirect to
another
page if the RequestVar is not populated. With mapSnippet, it sounds
like I'd have to have a dummy snippet with the same shape as the
original snippet where all the snippets redirect, e.g.
class InitializedTemplateEditor(template: Template)
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doOne _
case two = doTwo _
...
}
...
}
class TemplateEditor /* named TemplateEditor so that HTML templates
will use this unless mapSnippet has overridden */
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case one = doRedirect _
case two = doRedirect _
...
}
def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo(chooser, ()
= { S.error(Session information lost, please choose what template
to
edit again) })
}
and then some helper to map all the individual dispatches
object TemplateEditor
{
def redirectToEditor(template: Template) = {
val editor = InitializedTemplateEditor(template)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
S.mapSnippet(TemplateEditor.one, editor.doOne _)
...
S.redirectTo(/editor)
}
}
which seems
[Lift] Looking for Lift Developers
Hi all, I'm part of a very young Silicon Valley startup that is looking for Lift developers. We use ultra-low-power WiFi-based temperature sensors to monitor rack temperatures in datacenters. RIght now it's just me doing the main development, and as I'm sure you've noticed on this list, I'm quite new to Lift and Scala. So, we'd love more help, particularly someone who knows more Scala than me! If you're interesting in crunching lots of data and helping with things like building out our API with oAuth, XMPP (or perhaps AMQP?) and SNMP support, please drop me a line. Peter Robinett pe...@equal-networks.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 -~--~~~~--~~--~--~---
