[Lift] Re: Serious widget action
Please see here http://groups.google.com/group/liftweb/browse_thread/thread/5e4f5e424d33db40/32cfb6752954?lnk=gstq=ExtJs#32cfb6752954 I'd strongly encourage you to integrate ExtJs with Lift and potentially other frameworks. Depending on JS library licence we'd be happy to have integrations with other JS frameworks. JsArtifacts should provide you the necessary abstractions for such integrations but if you run into problems, please let us know. On Mar 10, 8:27 am, Jim Barrows jim.barr...@gmail.com wrote: On Tue, Mar 9, 2010 at 8:45 PM, aw anth...@whitford.com wrote: It is time for me to add some serious widgets to my lift app. So far, I am most enamored by ExtJS. Another alternative could possibly be ZK. Does anybody have any experience with these frameworks? Can you comment on why integrating them with Scala/Lift would be a bad idea (or not work)? I searched for some historical posts on ExtJS and discovered some threads about it's license and how it impacts inclusion in the lift framework. Would a commercial license prohibit it from being a lift- widget submodule candidate? Does anybody have a better suggestion that you think can compete with ExtJS? I'm using ExtJS in anger at 0rk. 3.1.1 is nice. 3.0.0 is weird. Some odd bugs being reported. We're also getting some weird interactions with some other js libraries ( I won't mention it, it's not available anymore, and if it was it just leave you scarred) and CSS. However, that's the other libraries fault more then ExtJS's. If you want something that looks and feels as close to a desktop app as you can get.. ExtJS can do the job well. With Lift providing the JSON, it would be hard to go wrong. That said.. ExtJS is not an easy beast to learn. It's even worse to try and L10N it easily. I would not try and use just pieces of it, it's really not designed to do that. It seems to me to be an all or nothing approach. That's not say you can't use it piecemeal, I think you lose a lot of flexibility (especially in layout) that way. I wouldn't use it if left to my own devices though, unless I had a requirement for a desktop app on the web. It's serious overkill. -- James A Barrows -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: RequestVar copy /clone ?
Is this currentClient(Full (c)), Text (Ajouter Facture)) called on
page X and ViewClient.add snippet on page Y?
If you want to preserve state between pages than you should use
SessionVars.
I don't know what Destination Post snippet means.
On Mar 9, 8:13 am, hexa hex...@gmail.com wrote:
Hi,
I have a RequestVar that I send to a snippet which will then do a
post...
But I would like the RequestVar to persist between the moment it it
received in the post snippet and the post itself...
The only way I found of doing it right now is like :
Source Snippet :
object ViewClient extends ViewClient
class ViewClient
{
object currentClient extends RequestVar [Box [Client]] (Empty)
bind (...
addInvoice - SHtml.link (/invoice/create, () = currentClient
(Full (c)), Text (Ajouter Facture)))
Destination Post Snippet :
def add (inhtml: NodeSeq) : NodeSeq = {
val inInvoice = Invoice.create
val clientBox = ViewClient.currentClient
val client_id = clientBox map (_.id.toLong)
def processEntry () {
Client.findByKey (client_id openOr 0) map (inInvoice.client (_))
inInvoice.save
S.notice (Entre : Description + inInvoice.description +
Montant : + inInvoice.amount)
}
bind (e, inhtml,
description - inInvoice.description.toForm,
amount - inInvoice.amount.toForm,
submit - SHtml.submit (Ajouter Facture, processEntry))
If I try to access the clientBox in processEntry, even with the
closure it should generate.. I get an empty box...
Is there any way to copy / ref or anything or make a new RequestVar
with a copy of the preceding one ?
Would have been nice not to be obligated to do the client_id toLong
code...
And juste do inInvoice.client (client) , inInvoice.save
Thanks a lot
hexa
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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 lazy-load?
I assume you are using Lift from master ... lazy-load should be able to wrap anything. I'll try to put in some ajaxSelects to see if I can repro. On Mar 8, 10:54 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Mon, Mar 8, 2010 at 5:42 PM, Marius marius.dan...@gmail.com wrote: Can you please send me a minimalistic example ? .. The comet actor shutdown looks correct to me as after the lazy content is rendered that comet is not needed anymore. Not easily. When I get some time I'll see if I can reproduce it in a sample. Can you check with firebug if you get any asynchronous javascript back from the comet request? It looks a bit strange. The normal request (with not lazy load) is about 3s. With the lazy load the comet request is almost 60s before anything (not the correct content) is returned (timed out?) Hold on! I did some more digging :-) Since this was just a naive application of lazy-load around an existing snippet, it contained bind with a few ajaxSelects inside. It seems this is what caused the problems. If I remove the ajaxSelects it seems to work. Not sure if this is a supported scenario or not, but if not we should probably emit some notification when running in dev mode.or at least document what can be put inside lazy-load /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Issue, The URL params can't contains ? ****
You need to do URL encoding first. Helpers.urlEcnode(str) does this. On Mar 9, 3:47 pm, Neil.Lv anim...@gmail.com wrote: Hi all, I have a silly question about the URL rewrite . How to let the URL params can contains the character. Here is the code: ### The url rewrite. case RewriteRequest( ParsePath(List(download, link), html, _, _), GetRequest, _) = RewriteResponse(List(download), Map(link - link)) ### When i input this link and get these value that the link param can't contains the char.http://localhost:8080/download.html?link=http://test.com/file.zip123... The link param is: (that doesn't contains the char in the param) S.param(link) =http://test.com/file.zip So how can i get the 12345678 value from the link param ? Maybe the URL rewrite is not correctly ? Thanks for any help! Cheers, Neil -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: More dynamic Lift
On Mar 9, 1:08 pm, Timothy Perrett timo...@getintheloop.eu wrote: BTW, with SBT, don't forget you can do: jetty-run (make changes to your code) prepare-webapp That will redeploy chnaged files / classses to the running jetty instance so development with SBT can still be slick without javarebel :-) Lift is really elegant - some how, this approach feels pretty ugly. I haven't looked at it, but no doubt it's using some classloader trickery? Of course this is why one can get into cast failures as ProtectionDomain may change. I haven't seen Dave's code so he can provide more details of what he did. Cheers, Tim Sent from my iPhone On 9 Mar 2010, at 10:45, Lukasz Kuczera kuk...@gmail.com wrote: But on the other hand it happens not too often. I'm personally very very happy with current productiveness using Lift + Jetty + JRebel. But what happens when Zeroturnaround will turn back to Scala ? It is quite possible that Scala will go mainstream. It might be viable solution then. Simple solution would be putting Menu building just before page rendering in development mode. But i can live perfectly without that as well (using JRebel). On Mar 9, 9:37 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett timo...@getintheloop.eu wrote: I'm afraid I agree with Marius... I'm just not sure on the benefit here over JRebel? My main pain point was changes to Sitemap. JRebel doesn't help you here as it's fixed once Lift is booted... /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en . -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 lazy-load?
Dear Jeppe, I spent some time today in looking to your issue. I was able to reproduce. The problem was that a NPE was thrown as the S,functionsMap was not initialized as I was doing a light S init to capture original request state. I have a fix for it but I need to do some more testing on it first. I'll open a ticket for this. Br's, Marius On Mar 9, 1:21 pm, Marius marius.dan...@gmail.com wrote: I assume you are using Lift from master ... lazy-load should be able to wrap anything. I'll try to put in some ajaxSelects to see if I can repro. On Mar 8, 10:54 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Mon, Mar 8, 2010 at 5:42 PM, Marius marius.dan...@gmail.com wrote: Can you please send me a minimalistic example ? .. The comet actor shutdown looks correct to me as after the lazy content is rendered that comet is not needed anymore. Not easily. When I get some time I'll see if I can reproduce it in a sample. Can you check with firebug if you get any asynchronous javascript back from the comet request? It looks a bit strange. The normal request (with not lazy load) is about 3s. With the lazy load the comet request is almost 60s before anything (not the correct content) is returned (timed out?) Hold on! I did some more digging :-) Since this was just a naive application of lazy-load around an existing snippet, it contained bind with a few ajaxSelects inside. It seems this is what caused the problems. If I remove the ajaxSelects it seems to work. Not sure if this is a supported scenario or not, but if not we should probably emit some notification when running in dev mode.or at least document what can be put inside lazy-load /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Issue, The URL params can't contains ? ****
Your request needs to be like: http://localhost:8080/download.html?link=http%3A%2F%2Ftest.com%2Ffile.zip%2612345678 and on the server side you can get the link from parameter with S.param(link) On Mar 9, 4:38 pm, Neil.Lv anim...@gmail.com wrote: I want get the these strings (http://test.com/file.zip12345678) from the URL (http://localhost:8080/download.html?link=http://test.com/ file.zip12345678) Thanks very much! Cheers, Neil -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 lazy-load?
I opened defect 412 and this is now on the review board: http://reviewboard.liftweb.net/r/263/diff/#index_header On Mar 9, 6:08 pm, Marius marius.dan...@gmail.com wrote: Dear Jeppe, I spent some time today in looking to your issue. I was able to reproduce. The problem was that a NPE was thrown as the S,functionsMap was not initialized as I was doing a light S init to capture original request state. I have a fix for it but I need to do some more testing on it first. I'll open a ticket for this. Br's, Marius On Mar 9, 1:21 pm, Marius marius.dan...@gmail.com wrote: I assume you are using Lift from master ... lazy-load should be able to wrap anything. I'll try to put in some ajaxSelects to see if I can repro. On Mar 8, 10:54 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Mon, Mar 8, 2010 at 5:42 PM, Marius marius.dan...@gmail.com wrote: Can you please send me a minimalistic example ? .. The comet actor shutdown looks correct to me as after the lazy content is rendered that comet is not needed anymore. Not easily. When I get some time I'll see if I can reproduce it in a sample. Can you check with firebug if you get any asynchronous javascript back from the comet request? It looks a bit strange. The normal request (with not lazy load) is about 3s. With the lazy load the comet request is almost 60s before anything (not the correct content) is returned (timed out?) Hold on! I did some more digging :-) Since this was just a naive application of lazy-load around an existing snippet, it contained bind with a few ajaxSelects inside. It seems this is what caused the problems. If I remove the ajaxSelects it seems to work. Not sure if this is a supported scenario or not, but if not we should probably emit some notification when running in dev mode.or at least document what can be put inside lazy-load /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: London Lift talk
Really nice talk Richard. Great stuff !!! On Mar 9, 9:05 pm, Richard Dallaway dalla...@gmail.com wrote: On Sat, Feb 20, 2010 at 8:22 PM, andy andy1...@gmail.com wrote: The London Scala User Group (LSUG) will be presenting a talk by Richard Dallaway on 'Getting started with Lift' at SkillsMatter It is done:http://icanhaz.com/gswl... where you will find a link to the Skillsmatter video. Richard -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Javascript Dependencies
On Mar 8, 11:02 am, Peter Robinett pe...@bubblefoundry.com wrote: Marius, I love the simplicity of your proposal but I think that's also its problem. Let's say I have something with several dependencies: lift:MySnipet.work lift:dependencies script src=dep1.js/ script src=dep2.js/ script src=myLib.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work As you can see, the user may as well be writing raw XHTML for a head tag: they're required to know all the dependencies and put them in the correct order. Of course library authors can make this easier by writing snippets and such that provide the dependencies: def flotSelectableJS = lift:dependencies script src=/classpath/jquery.js/ script src=/classpath/jquery.flot.js/ script src=/classpath/jquery.flot.selectable.js/ /lift:dependencies However, there is no representation of the Javascript files and their individual dependencies independent on the XML tags and the order in which they are placed. This is why I like using a Scala class better: a developer can look at any instance of a Javascript file class and see its dependencies without having to do any (easy) XML querying, only converting the instance to XML when necessary. I guess one reason I am pushing this approach is that I'm thinking in terms of lift-flot, where the user does all their manipulation of the charts in straight Scala, not Javascript or XHTML. This is also corresponds to how various Javascript and jQuery operations are represented in net.liftweb.http.js, and I'd like to complement them and continue in that vein. Please feel free to implement your proposal and we'll discuss either here or on review board. Oh, and I definitely want to be able to have conditional snippets like you mention, that's a great feature. Conditional snippets are supported today. For instance TestCond.loggedn or TestCont.loggedOut snippets. Any application can choose to render or not a snippet especially when talking about nested snippets. What do you think? Peter On Mar 6, 11:33 am, Marius marius.dan...@gmail.com wrote: On Mar 6, 9:14 pm, Peter Robinett pe...@bubblefoundry.com wrote: Hi guys, Sorry I'm only coming back to this discussion now. I think what you're both proposing are the two parts of what should be the complete use- case. Yes, dependencies _exist_ per page and, yes, you want to _declare_ them per snippet or CometActor. The last (and only) commit on my pr1001_issue_branch shows my first stab at managing and registering the dependencies:http://github.com/dpp/liftweb/tree/pr1001_issue_281. I think it is quite similar to what has been mentioned (compare JsScript to Marius' JsDependenciesTree, ignoring that his is more elegant =). I think my resolve and satisfied_? methods work correctly, though they still need someone with some CS knowledge to check them (for instance, I'm not doing any checks for circular dependencies right now). The only real question is _when_ to call them and how to act upon them. I was thinking at the snippet level, not the page level. Anything outputting (X)HTML to the browser needs to be able to register their dependencies (CometActors by their nature should really only do it in their initial render) for a page-wide set of dependencies which are then resolved and merged into the head of the HTML document when the page is finally rendered. Hmmm ... anything that is outputting (x)html. We have snippets, comet actors, LiftView-s. Any of these can called multiple times but IMHO registration should happen once. For snippets and comet we could a nested snippet such as: lift:MySnipet.work lift:dependencies script src=bla.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work lift:comet ... lift:dependencies script src=bla.js/ /// you got the ides /lift:dependencies ... /lift:comet In this sense we are describing dependencies (could be both js and css) per snippet / per comet. the dependencies snippet could be either eagerly evaluated or not - shouldn't really matter. What it does it just put the script and link tags in a head element that lift will automatically merge. This could also be useful for conditional snippets . Say we have snippet A and snippet B on the same page each having different dependencies. But snippet A is invoked only when the user is logged on and snippet B only when user is logged off. Thus we won't have to modify scala API at all. Cause it seems that Lift already provides the goodies for us. Of course this can work even today if we replace lift:dependencies with head tag but people would probably find this nomenclature odd. I'm not sure if we should worry about circular dependencies in this case and neither for duplicates as lift head merge mechanism detects
[Lift] Re: How to use lazy-load?
Can you please send me a minimalistic example ? .. The comet actor shutdown looks correct to me as after the lazy content is rendered that comet is not needed anymore. Can you check with firebug if you get any asynchronous javascript back from the comet request? On Mar 8, 4:31 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, I have a page with a somewhat lengthy first-time load. So I found lazy-load that looked handy, but it doesn't seem to work. This is my template: lift:surround with=wide at=content h2Udvikling per måned/h2 lift:lazy-load lift:performanceChart div class=span-5 Vis:br/ performance:mapReduce/br/ Opdel efter:br/ performance:groupBy/ /div div class=column span-19 last performance:chart/ div id=tableperformance:dataTable//div /div /lift:performanceChart /lift:lazy-load /lift:surround Nothing in the performanceChart snippet is rendered when wrapped with lazy-load (but I see from the logs that the snippet as being called) If I wait a while, I can see the comet actor shutdown: 15:29:55.096 [ool-2-thread-13] INFO lift - The CometActor net.liftweb.builtin.snippet.asyncrenderco...@131e8e72 Received Shutdown What am I missing? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: 2.0-M3 JQuery 1.4
The scaladocs of WithResourceId snippet looks like this: /** * Adds a resource id entity for each URI in order to control browser caching. * The rules of creating unique URI's are defined in LiftRules.attachResourceId function. * * pre * lt;lift:with-resource-id * lt;link ... / * lt;script ... / * lt;/lift:with-resource-id * /pre */ By default LiftRules.attachResourceId attaches a random query string to the URI-s (This is a quantity unique per application lifetime on a single JVM). You can of course register your own function and define your own behavior of how the resources (script and link) are modeled to control caching. On Mar 8, 7:55 pm, Channing Walton channingwal...@mac.com wrote: I am interested in this too but I don't understand the lift:with-resource-id thing, where can I find out more? AnthonyW wrote: Ugh, I must have had a cache issue despite the fact that I certainly did hit refresh before... I am now seeing 1.4.2 JQuery. Regarding lift:with-resource-id, I just added that too. This is definitely a nice feature because caching has been an issue for me. Thanks Marius! -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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. -- View this message in context:http://old.nabble.com/2.0-M3---JQuery-1.4-tp27802013p27825013.html Sent from the liftweb mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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] Js normalizations
Dear all, Looking at Js api and specifically JsCmds and JqJsCmds (the Js abstractions vs Jquery specify abstractions) IMHO there are several redundancies: 1. JsCmds has ~ method for referencing member of objects (i.e elem.focus()) but JQuery abstractions have method that chains a JQueryLeft with JQueryRight 2. JQueryLeft and JQueryRight also seems redundant because JsExp already have the support for building expressions, composing them, chaining expressions etc. My proposal is to normalize this API and have the JQuery specific things to rely on the JsExp support. I'm aware that this would lead to some breaking changes but I believe they are necessary. If you think that this makes sense I'll add a ticket and put it in my backlog. Thoughts? Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Js normalizations
I'm not sure about the fastness as I also have other things and a 4 days baby boy ;) ... but I think this is fairly important and I'll try to prioritize. On Mar 7, 8:52 pm, Mads Hartmann Jensen mads...@gmail.com wrote: Marius, I think this sounds like a great idea - but I only have 2 Lift projects under development so it would be quite fast for me to make any changes Mads On 07/03/2010, at 19.37, Marius wrote: Dear all, Looking at Js api and specifically JsCmds and JqJsCmds (the Js abstractions vs Jquery specify abstractions) IMHO there are several redundancies: 1. JsCmds has ~ method for referencing member of objects (i.e elem.focus()) but JQuery abstractions have method that chains a JQueryLeft with JQueryRight 2. JQueryLeft and JQueryRight also seems redundant because JsExp already have the support for building expressions, composing them, chaining expressions etc. My proposal is to normalize this API and have the JQuery specific things to rely on the JsExp support. I'm aware that this would lead to some breaking changes but I believe they are necessary. If you think that this makes sense I'll add a ticket and put it in my backlog. Thoughts? Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Js normalizations
Yes that's the idea ... I apologize I didn't actually mean to just remove things out of the sudden. But I'll know more once I get to dig deeper. On Mar 7, 10:13 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: Can it be changed with a deprecation phase? - Mariusmarius.dan...@gmail.com wrote: I'm not sure about the fastness as I also have other things and a 4 days baby boy ;) ... but I think this is fairly important and I'll try to prioritize. On Mar 7, 8:52 pm, Mads Hartmann Jensen mads...@gmail.com wrote: Marius, I think this sounds like a great idea - but I only have 2 Lift projects under development so it would be quite fast for me to make any changes Mads On 07/03/2010, at 19.37, Marius wrote: Dear all, Looking at Js api and specifically JsCmds and JqJsCmds (the Js abstractions vs Jquery specify abstractions) IMHO there are several redundancies: 1. JsCmds has ~ method for referencing member of objects (i.e elem.focus()) but JQuery abstractions have method that chains a JQueryLeft with JQueryRight 2. JQueryLeft and JQueryRight also seems redundant because JsExp already have the support for building expressions, composing them, chaining expressions etc. My proposal is to normalize this API and have the JQuery specific things to rely on the JsExp support. I'm aware that this would lead to some breaking changes but I believe they are necessary. If you think that this makes sense I'll add a ticket and put it in my backlog. Thoughts? Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Js normalizations
You must be unique :) On Mar 7, 10:21 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: Then it sounds good to me, although that doesn't count as much since I must admit I haven't really had the opportunity to use Lift's ajax and javascript parts. - Mariusmarius.dan...@gmail.com wrote: Yes that's the idea ... I apologize I didn't actually mean to just remove things out of the sudden. But I'll know more once I get to dig deeper. On Mar 7, 10:13 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: Can it be changed with a deprecation phase? - Mariusmarius.dan...@gmail.com wrote: I'm not sure about the fastness as I also have other things and a 4 days baby boy ;) ... but I think this is fairly important and I'll try to prioritize. On Mar 7, 8:52 pm, Mads Hartmann Jensen mads...@gmail.com wrote: Marius, I think this sounds like a great idea - but I only have 2 Lift projects under development so it would be quite fast for me to make any changes Mads On 07/03/2010, at 19.37, Marius wrote: Dear all, Looking at Js api and specifically JsCmds and JqJsCmds (the Js abstractions vs Jquery specify abstractions) IMHO there are several redundancies: 1. JsCmds has ~ method for referencing member of objects (i.e elem.focus()) but JQuery abstractions have method that chains a JQueryLeft with JQueryRight 2. JQueryLeft and JQueryRight also seems redundant because JsExp already have the support for building expressions, composing them, chaining expressions etc. My proposal is to normalize this API and have the JQuery specific things to rely on the JsExp support. I'm aware that this would lead to some breaking changes but I believe they are necessary. If you think that this makes sense I'll add a ticket and put it in my backlog. Thoughts? Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: superficial first impressions from a rails junkie
On 6 mar., 06:43, cageface milese...@gmail.com wrote:
Like many other web developers, I abandoned some heavyweight Java web
frameworks about 6 years ago for Rails and have been working pretty
much exclusively in Rails ever since. However, I've always had a
secret lust for functional languages so when I heard about Scala and
Lift I decided to take a closer look. My first impression of the
community from studying this list and many other blogs, articles etc
is that it's a group of smart, dedicated folks that have generously
dedicated a lot of time and energy to making Lift a first-class
alternative to the more conventional options.
However, my first brush with the framework itself has so far left a
very different impression. I think one of the reasons Rails caught on
so quickly in the beginning was that it was marketed brilliantly. DHH
made Rails look so simple, stylish and intuitive that anybody drowning
in the bulk and complexity of Java web dev at the time couldn't help
but take notice. Lift, in contrast, and particularly for anybody with
a prior history in Java, seems very daunting and rough. The following
impressions are very much superficial first impressions and may really
have no deeper substance than that but I think first impressions count
for a lot in this sphere.
First, the liftweb.net site is nice. It's a clean, elegant,
contemporary design. So far so good. Let's click on getting started.
What's this? PDF? Who uses PDF? Nevermind, let's look at the HTML.
Gack! This looks like an academic LaTEX conversion from the 90s.
Layout and formatting are next to non-existent. This doesn't look like
the intro for a simple, ready-to-use tool.
Oh well, pushing past the wall of text intro we discover that we need
Maven. Alarms are starting to go off in the heads of many Java
refugees that remember Maven as the nadir of the XML-situp
overabstracted agony that was pre-Rails Java web dev. I imagine many
people have signed off by this point. We go download maven and press
on to the first actual command we can run, which is an impressively
cryptic 8-line mvn invocation that seems to take about 10 minutes to
download every single apache and codehaus jar file.
When this finally winds down we start the server and take a look at
our homely start page and bounce back to the docs. XHTML. Hmmm. Didn't
everybody give up on that a few years ago?
Lift is not a MVC framework - it is rather a View First framework. It
intentionally avoids putting code in the template. This keeps the
template clean. Xhtml in Scala? YES ! because:
1. Snippets are UI complementers ... putting xhtml in other app layers
is your application design responsibility
2. Scala supports xml literals which makes in practice this paradigm
extremely useful and clean
3. It respects separation of concerns because the template itself
and the snippets have the same concern - rendering static
respectively dynamic content. Putting code inside the template is one
of the worse design decisions ever. Putting template fragments inside
Scala code makes tremendous sense as it allows a truly flexible way of
achieving compositionality, reusability etc.
whether you abuse this or not is your choice, but every framework has
element that can be abused leading to really poor design.
HTML literals *in* the
code? All the snippets we're going to be editing live six levels
deep in the project directory structure? This will be fun with emacs/
vim...
Actually I'm using emacs like many other folks. It is a very good
experience and I'm happy with it.
By this point our enthusiasm is seriously waning but our dreams of an
expressive but statically typed platform keep us going on to the next
section anyway. We begin with another mvn invocation that mysteriously
fails. After futzing with it for a bit and googling around we discover
that there are spaces following each of the \ line continuations so we
copy and paste the whole thing into a file, clean it up, and invoke it
via sh. After this finishes we create the first model, which actually
looks pretty reasonable, similar to a Django model with a little more
boilerplate but nothing too intimidating. We discover to our chagrin
that we're going to have to manually add each model to the toplevel
Schemifier invocation in Boot.scala, which makes us grumpy. We skim
through the explanation of the views and we're not sure what to make
of the html binding approach. On one hand it looks pretty precise. On
the other hand it suggests an even tighter straightjacket than Django
templates. We reserve judgement.
We work through the next few instructions to come to the creation of
TD.scala only to be greeted by a *19* line file header:
package com.liftworkshop.snippet
import com.liftworkshop._
import model._
import net.liftweb._
import http._
import SHtml._
import S._
import js._
import JsCmds._
import mapper._
import util._
import Helpers._
import scala.xml.{NodeSeq,
[Lift] Re: 2.0-M3 JQuery 1.4
? Did you refresh the browser to make sure that the resources is fetched? If you don't want to bother we resource refresh you can try this: lift:with-resource-id // put your script tags here /lift:with-resource-id I just re-tested and it is working just fine for me JQuery14Artifacts points to JQuery 1.4.2 On 6 mar., 06:50, aw anth...@whitford.com wrote: I understand from Issue 363 that I can control which version of JQuery to use. I generally prefer the latest and greatest, and I see that I am using 1.3.2, so I want to set it to 1.4.2. According to this thread: http://groups.google.com/group/liftweb/browse_thread/thread/807a9397f... I thought it was as easy as adding this line to boot: LiftRules.jsArtifacts = JQuery14Artifacts Alas, this doesn't seem to work for me as I am still getting 1.3.2... Also, I see that Issue 311, which was closed in 2.0-M2, says that 1.4.1 is the default. But I don't think that was the case, right? Can somebody please tell me what I am missing? This strikes me as a good Wiki topic. ;-) -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Problem with FocusOnLoad and passing attributes through bind
In the short term you would solve it as I suggested:
Use in your bind
searchBox -% doSearch
and define your doSearch as:
def doSearch: NodeSeq = {
... do your stuff here
}
Actually thinking more into it there is a good reason for -% to not
have a (NodeSeq) = NodeSeq support. -% means that it preserves the
attributes specified in the template to the resulting node.But having
a bunch of attributes we can't apply them to a NodeSeq because aa
NodeSeq means a sequence of Nodes with no commn parent so we can;t
determine to which node we'd apply those attributes. AFAIK only an
Elem can have attributes.
On Mar 6, 6:45 pm, Luke Nezda lne...@gmail.com wrote:
Thanks for responding Marius. You're right, my doSearch method
doesn't need the msg parameter -- that was just an artifact of
transforming an example (removed now). As far as my specific issue, I
guess you're saying the best solution is for the framework to add
overload def -%(in: NodeSeq = NodeSeq) congruent with - -- should I
file a feature request? As you said, Group(FocusOnLoad...) doesn't
compile either because it returns a Node, not the currently required
Element. Did I misunderstand?
You are correct. I mainly pointed to Group just as a reminder as it
can be useful to aggregate nodes. It wont work in your case.
In the short term how would you solve
this ?
Thanks,
- Luke
On Mar 6, 1:39 am, Marius marius.dan...@gmail.com wrote:
On 22 feb., 04:12, Luke Nezda lne...@gmail.com wrote:
Hello,
I am new to Scala and Lift. I am having a problem using 2 features
together which seem to work fine individually. Here's a simplified
piece of the code:
class Ajax {
def someResult(q:String) = spansome results for query {q}.../
span
// searchField closure
def searchField(xhtml: NodeSeq): NodeSeq = {
// build up an ajax text box
def doSearch(msg: NodeSeq) = {
// doesn't compile with bind: searchBox -% doSearch _
FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
someResult(q
// compiles with bind: searchBox -% doSearch _
// SHtml.ajaxText(, q = SetHtml(resultz, someResult(q)))
}
// bind the view to the functionality
bind(ajax, xhtml,
searchBox - doSearch _
// doesn't compile if doSearch returns result of FocusOnLoad
//searchBox -% doSearch _
)
}
}
and the template invocation:
lift:surround with=default at=content
lift:Ajax.searchField id_msgs=messages
ajax:searchBox class=text type=search tabindex=1 /
hr class=space/
div id=resultz/div
div id=messages/div
/lift:Ajax.searchField
/lift:surround
My goal is an Ajax-enabled text input that gets focus when the page
loads and has various attributes of the input element set. I realize
I can use the SHtml.ajaxText variant that takes attribute-value pairs,
as in:
FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)), (class, text), (type, search), (tabindex,
1)))
but I'm trying to keep the various element attributes in the template.
When I try to bind with:
searchBox -% doSearch _
instead of:
searchBox - doSearch _
I get the following compile error:
snippet/Ajax.scala:109: error: overloaded method value -% with
alternatives ((scala.xml.NodeSeq) =
scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam and
(Option[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindParam and
(net.liftweb.common.Box[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindPa
ram
and (scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam cannot be
applied to ((scala.xml.NodeSeq) = scala.xml.NodeSeq)
searchBox -% doSearch _
^
one error found
Why your doSearch function takes a msg parameter? ... it doesn't seam
to use it.
doSearch _ is a partially applied function and acts as a (NodeSeq) =
NodeSeq however -% has only a definition like:
def -%(in: NodeSeq = Elem)
while - also has
def -(in: NodeSeq = NodeSeq)
which is why you get the compile error. We should add the same
definition for NodeSeq = NodeSeq
You can simply say:
searchBox -% doSearch
and have def doSearch: NodeSeq = ...
FocusOnLoad returns a NodeSeq because it returns a sequence of nodes
which conceptually cannot be converted to an elem. You could try to
have a Group(FocusOnLoad ...) ... but Group is a Node not an Elem.
Between all the bind() and -()/-%() overloads and my general Scala /
Lift ignorance, I can't understand what the right way to resolve this
is. I think it has something to do with FocusOnLoad returning a
NodeSeq (input/script/) vs. an Element, but I don't know where to
go from here...
Thanks in advance,
- Luke
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email
[Lift] Re: superficial first impressions from a rails junkie
A few notes from my behalf. I understand Tim's perspective and I fully agree with, but this is a perspective of a guy coming from Lift side which is likely to differ from the perspective of a new comer. 1. I definitely do not agree with something like here is why you should use A and not B thus you need to persevere with A ... this sounds like an american anti-commercial for detergents (no offense US folks). Where you believe it or not we do value the good things of other frameworks and learn from their mistakes. 2. Even if Lift docs are way behind I still think that there is truly enough material out there to convince people of its value or help them make a decision whether to adopt it or not. There are hundreds of people using Lift and quite a handful of corporates (SAS, Novell, Twitter, Xerox, ... Tim and Dave have a wider list) 3. You say ... for those design decisions that have made Lift harder to use what design decisions? I'm quite aware about lift's design and guts and I'm not aware of any of design decisions that made Lift harder to use. There is a fundamental difference between understanding the design and just say or allude that Lift is hard to use by design. 4. Yes I agree that Lift has a powerful contribution to Scala adoption but in reality I think it is a mutual thing. 5. How much of the difficulty that people seem to have in using Lift is intrinsic to the framework and how much to poor docs? good question but hard to tell. People come with different mindsets and backgrounds. For some it is hard to accept View-First as they seem to have a too strong MVC mind set. Some are just open minded (most of people on this list I'd add) and this people came with concrete cases and I truly believe that Lift team helped them quite a bit. 6. Lift strengths were communicated by this list, by talks done by David, Tim, Derek myself etc., By the Definitive guide to Lift book, numerous blog posts etc. numerous examples, .. if you checkout Lift you'll get a list of example apps that demonstrates it power. So I resent this argument. 7. I don't know what you are refer to appeal when you are talking about Lift. Is it about visual design of site, docs etc ? If not please define appeal in this context? .. I tend to thing that this is a subjective term in many respects. On Mar 6, 7:02 pm, jonathan mawson umpti...@gmail.com wrote: Timothy Perrett wrote: By all means, come here with questions and you will find this group to be very responsive and helpful, but do not come here and automatically assume that you can illuminate to us the errors in our project marketing or experience. What's automatic about Mark's analysis? He's a new Lift user, he's told you what the new user experience is like - he did the appropriate work to be able to do this. If there is anything automatic here it is your dismissal of the problems that Mark had. This sort of user feedback is gold - he's made a real effort to tell you what trying to get started with Lift was like for him. And reading what Mark wrote, I'm sure that he is much brighter and more interested in Lift than the average Java/RoR programmer. Lift is not Rails. It really bugs me when people are like oh, well rails does XYZ. The guy never said it was. He explained why he switched to Rails and why he thinks Rails has been successful. The important point that Rails people who want their framework to takeoff have to understand here is ***that at no time during Mark's experience did anyone communicate a reason to him why Lift was worth persevering with.*** That's what marketing is about. If Mark had known there was a strong enough potential benefit then he would have persisted. At the moment Lift's only perceived benefit seems to be that it provides you with a web framework for Scala. That's a nice strategy for getting a couple of dozen FPophiles to commit code, but it won't take Lift anywhere in the real world of What does this framework do for my project/career/business. You need to start telling people what Lift especially well so that they have some idea why they might use it! The best effort I have seen to do this comes not from the Lift community but from another reviewer, here - http://ikaisays.com/2009/03/03/first-impressions-of-lift-scala-web-de... Other concerns: - I suspect that Lift has enough mass inside the Scala community to prevent the emergence of another web framework. And that without an acceptable web framework Scala - which I am now 100% in love with - will not be a successful language. - How much of the difficulty that people seem to have in using Lift is intrinsic to the framework and how much to poor docs? What are the ***pay-offs*** for those design decisions that have made Lift harder to use? (Even when this simply means less Rails-like.) Communicating these would go a long way to reducing newbie frustration. Is Lift even designed to have as wide an appeal as RoR or Grails? If not, be frank
[Lift] Re: Javascript Dependencies
On Mar 6, 9:14 pm, Peter Robinett pe...@bubblefoundry.com wrote: Hi guys, Sorry I'm only coming back to this discussion now. I think what you're both proposing are the two parts of what should be the complete use- case. Yes, dependencies _exist_ per page and, yes, you want to _declare_ them per snippet or CometActor. The last (and only) commit on my pr1001_issue_branch shows my first stab at managing and registering the dependencies:http://github.com/dpp/liftweb/tree/pr1001_issue_281. I think it is quite similar to what has been mentioned (compare JsScript to Marius' JsDependenciesTree, ignoring that his is more elegant =). I think my resolve and satisfied_? methods work correctly, though they still need someone with some CS knowledge to check them (for instance, I'm not doing any checks for circular dependencies right now). The only real question is _when_ to call them and how to act upon them. I was thinking at the snippet level, not the page level. Anything outputting (X)HTML to the browser needs to be able to register their dependencies (CometActors by their nature should really only do it in their initial render) for a page-wide set of dependencies which are then resolved and merged into the head of the HTML document when the page is finally rendered. Hmmm ... anything that is outputting (x)html. We have snippets, comet actors, LiftView-s. Any of these can called multiple times but IMHO registration should happen once. For snippets and comet we could a nested snippet such as: lift:MySnipet.work lift:dependencies script src=bla.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work lift:comet ... lift:dependencies script src=bla.js/ /// you got the ides /lift:dependencies ... /lift:comet In this sense we are describing dependencies (could be both js and css) per snippet / per comet. the dependencies snippet could be either eagerly evaluated or not - shouldn't really matter. What it does it just put the script and link tags in a head element that lift will automatically merge. This could also be useful for conditional snippets . Say we have snippet A and snippet B on the same page each having different dependencies. But snippet A is invoked only when the user is logged on and snippet B only when user is logged off. Thus we won't have to modify scala API at all. Cause it seems that Lift already provides the goodies for us. Of course this can work even today if we replace lift:dependencies with head tag but people would probably find this nomenclature odd. I'm not sure if we should worry about circular dependencies in this case and neither for duplicates as lift head merge mechanism detects duplicates. I think this would cover snippets and comet actors and it should also work for LiftView-s Thoughts ? So, what if we have something like req.registerDependency(myJsScript)? The Request would store the dependencies that the LiftResponse would then take, resolve, and merge into the XHTML it's outputting. However, CometActors exist outside of normal requests. How do we get around this? CometActors are created initially in a Request, so we should be able to connect then but I don't know that part of Lift well enough to say how. Jeppe, Marius, what do you think? Am I on the right track? Do my suggestions address both of your concerns? Peter On Mar 1, 7:17 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Marius marius.dan...@gmail.com writes: Yes we do have different perspectives. I'm saying for page X here these are the JS dependencies whether you seem to say here is a snippet, and it needs these dependencies Yes I'd still prefer my paradigm (not because of my ego) because it'd be easier to manage redundancies, it applies generically for snippets, comet actors etc. without having to induce other type of API. It is maybe coarse grained vs. your proposal that seems to me finner grained. I think the two can co-exist, although I haven't thought it through wrt comet actors etc. That was what I was hinting at in the previous mail. At the of the day (or before sending a response at least :-) a page needs to have a well-defined list of script files to include. So it makes sense to start with your paradigm and my paradigm should be able to be layered on top if one wishes... However I'd be happy to see an implementation of any of these proposals. Maybe other people would have better ideas so perhaps Peter and/oryou could dig could make this happen? I'll let Peter take the lead and help where ever I can :-) /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Problem with FocusOnLoad and passing attributes through bind
You could also do it like this:
bind(ajax, xhtml,
searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q))
) ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))
SetValueAndFocus is already in JqJsCmds but it really should in in
JsCmds as it does not depend on JQuery.
On Mar 6, 10:10 pm, Marius marius.dan...@gmail.com wrote:
Ahh sorry for not posting this earlier.
Assume you know the id of your text box (say myfield) and you're using
JQuery.
import net.liftweb.http.js.jquery._
bind(ajax, xhtml,
searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q))
) ++ Script(JqOnLoad(JqFocus(myfield)))
where:
object JqFocus {
def apply(id : String) = JqId(id) new JsExp with JQueryRight {
def toJsCmd = focus()
}
}
I can add JqFocus to Lift tomorrow (by opening a ticket) but could you
please try it first?
Br's,
Marius
On Mar 6, 9:00 pm, Luke Nezda lne...@gmail.com wrote:
Marius -
First, thank you for your time! (sorry for the accidental double
response post - browser fail :))
Ok, so below is my current solution. What I don't understand is how
to avoid hard coding the attributes when constructing the
SHtml.ajaxText AND getting that ajaxText's input to FocusOnLoad. I
understand how to leave off the parameter for doSearch (fixed below --
you're totally right, that was spurious) and I understand that passing
through attributes to a whole NodeSeq doesn't make much sense. What
I'm wondering is if there's some way of achieving both: FocusOnLoad
attribute pass through -- maybe a nested bind or something?
Thanks again,
- Luke
// get FocusOnLoad, hard code attributes
object AjaxWithFocusOnLoad extends DispatchSnippet {
override def dispatch = {
case searchField = searchField
}
// searchField closure
def searchField(xhtml: NodeSeq): NodeSeq = {
// build up an ajax text box
def doSearch:NodeSeq = {
FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)), (size,30), (tabindex, 1), (type,
search)))
}
// bind the view to the functionality
bind(ajax, xhtml,
searchBox - doSearch
)
}
}
// ditch FocusOnLoad functionality, take advantage of attribute pass
through
object AjaxWithAttributePassThrough extends DispatchSnippet {
override def dispatch = {
case searchField = searchField
}
// searchField closure
def searchField(xhtml: NodeSeq): NodeSeq = {
// build up an ajax text box
def doSearch:Elem = {
//FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)), (size,30), (tabindex, 1), (type,
search)))
// kill FocusOnLoad functionality, take advantage of attribute
pass through in bind below
SHtml.ajaxText(, q = SetHtml(resultz, Yawni.query(q)))
}
// bind the view to the functionality
bind(ajax, xhtml,
//searchBox - doSearch
// use attribute pass through variant
searchBox -% doSearch
)
}
}
On Mar 6, 10:57 am, Marius marius.dan...@gmail.com wrote:
In the short term you would solve it as I suggested:
Use in your bind
searchBox -% doSearch
and define your doSearch as:
def doSearch: NodeSeq = {
... do your stuff here
}
Actually thinking more into it there is a good reason for -% to not
have a (NodeSeq) = NodeSeq support. -% means that it preserves the
attributes specified in the template to the resulting node.But having
a bunch of attributes we can't apply them to a NodeSeq because aa
NodeSeq means a sequence of Nodes with no commn parent so we can;t
determine to which node we'd apply those attributes. AFAIK only an
Elem can have attributes.
On Mar 6, 6:45 pm, Luke Nezda lne...@gmail.com wrote:
Thanks for responding Marius. You're right, my doSearch method
doesn't need the msg parameter -- that was just an artifact of
transforming an example (removed now). As far as my specific issue, I
guess you're saying the best solution is for the framework to add
overload def -%(in: NodeSeq = NodeSeq) congruent with - -- should I
file a feature request? As you said, Group(FocusOnLoad...) doesn't
compile either because it returns a Node, not the currently required
Element. Did I misunderstand?
You are correct. I mainly pointed to Group just as a reminder as it
can be useful to aggregate nodes. It wont work in your case.
In the short term how would you solve
this ?
Thanks,
- Luke
On Mar 6, 1:39 am, Marius marius.dan...@gmail.com wrote:
On 22 feb., 04:12, Luke Nezda lne...@gmail.com wrote:
Hello,
I am new to Scala and Lift. I am having a problem using 2 features
together which seem to work fine individually. Here's a simplified
piece of the code:
class Ajax {
def someResult(q:String) = spansome
[Lift] Re: Problem with FocusOnLoad and passing attributes through bind
Yes you understanding is correct.
FocusOnLoad is not an appropriate solution for your particular problem
as -% and FocusOnLoad operate on two different types which are not
interchangeable due to attributes preservation as you well noticed.
Besides the solution I posted above is similar with what FocusOnLoad
does except that it does the Script append a bit later on.
FocusOnLoad is not really functional well not in the sense of
functional programming :)
There are other approaches of course but would require more coding as
form the NodeSeq produced by FocusOnLoad(Shtml.ajaxText()) pattern
match for the Elem you want that add the attributes.
You could of course put the js code that puts the focus on your field
right in your template in the script tag and this would require no
Scala code for it. you code would simply be
bind(ajax, xhtml,
searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)))
)
and in your template
script type=text/javascript
$(document).ready(function() {
$(#myfield).focus();
});
/script
On 6 mar., 23:56, Luke Nezda lne...@gmail.com wrote:
Hi, Marius -
Ok, I think I catch the drift of your solution. You said:
bind(ajax, xhtml,
searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q))
) ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))
which is missing a paren -- I think you meant:
bind(ajax, xhtml,
searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)))
) ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))
The gist of your solution is to append a Script (which references the
ajaxText input element by a manually introduced id) onto the NodeSeq
returned by bind() right ?
It works, and I appreciate your assistance, though it seems a shame to
have to give up the slick, functional FocusOnLoad wrapper, add an id,
and bolt this onto the end.
Thanks,
- Luke
On Mar 6, 2:39 pm, Marius marius.dan...@gmail.com wrote:
You could also do it like this:
bind(ajax, xhtml,
searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q))
) ++ Script(JqOnLoad(SetValueAndFocus(myfield, )))
SetValueAndFocus is already in JqJsCmds but it really should in in
JsCmds as it does not depend on JQuery.
On Mar 6, 10:10 pm, Marius marius.dan...@gmail.com wrote:
Ahh sorry for not posting this earlier.
Assume you know the id of your text box (say myfield) and you're using
JQuery.
import net.liftweb.http.js.jquery._
bind(ajax, xhtml,
searchBox -% SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q))
) ++ Script(JqOnLoad(JqFocus(myfield)))
where:
object JqFocus {
def apply(id : String) = JqId(id) new JsExp with JQueryRight {
def toJsCmd = focus()
}
}
I can add JqFocus to Lift tomorrow (by opening a ticket) but could you
please try it first?
Br's,
Marius
On Mar 6, 9:00 pm, Luke Nezda lne...@gmail.com wrote:
Marius -
First, thank you for your time! (sorry for the accidental double
response post - browser fail :))
Ok, so below is my current solution. What I don't understand is how
to avoid hard coding the attributes when constructing the
SHtml.ajaxText AND getting that ajaxText's input to FocusOnLoad. I
understand how to leave off the parameter for doSearch (fixed below --
you're totally right, that was spurious) and I understand that passing
through attributes to a whole NodeSeq doesn't make much sense. What
I'm wondering is if there's some way of achieving both: FocusOnLoad
attribute pass through -- maybe a nested bind or something?
Thanks again,
- Luke
// get FocusOnLoad, hard code attributes
object AjaxWithFocusOnLoad extends DispatchSnippet {
override def dispatch = {
case searchField = searchField
}
// searchField closure
def searchField(xhtml: NodeSeq): NodeSeq = {
// build up an ajax text box
def doSearch:NodeSeq = {
FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)), (size,30), (tabindex, 1), (type,
search)))
}
// bind the view to the functionality
bind(ajax, xhtml,
searchBox - doSearch
)
}
}
// ditch FocusOnLoad functionality, take advantage of attribute pass
through
object AjaxWithAttributePassThrough extends DispatchSnippet {
override def dispatch = {
case searchField = searchField
}
// searchField closure
def searchField(xhtml: NodeSeq): NodeSeq = {
// build up an ajax text box
def doSearch:Elem = {
//FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)), (size,30), (tabindex, 1), (type,
search)))
// kill FocusOnLoad functionality, take advantage of attribute
pass through in bind below
SHtml.ajaxText(, q
[Lift] Re: Customizing generated form elements without touching scala code
I disagree with the unglyness you are talking about just because
Snipets are UI elements. However you can preserve the attributes from
the markup such as:
def doit(xhtml: NodeSeq): NodeSeq = {
bind(f, xhtml,
text -% SHtml.text(name, println _)
)
}
and in the markup
lift:MySnippet.doit
f:text class=abc size=3/
/lift:MySnippet.doit
On Mar 5, 2:07 pm, Julian Backes julianbac...@googlemail.com wrote:
Hi,
I'm trying to get my first form in Lift running and I'm having the
following problem:
I use for example SHtml.text(..) to create a text input element.
Unfortunately, this element has no specific class or id such that I can
customize it using CSS or whatever.
I know that I can add some parameters to SHtml.text(..) which are passed
to the generated form element but this means that I have style
information in my scala code. And this is, in my opinion, very ugly.
Is there a better solution?
I could imagine something like e:myfield class=somecssclass/. This
class information is accessible in scala so the form generator could
automatically add it to the generated element...
Thanks in advance for your help!!
Julian
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Wow... Lift has some amazing stats
I'm sooo proud being a little part of it ;) On 5 mar., 19:46, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, I just looked at Lift's stats on ohloh. (http://www.ohloh.net/p/liftweb) A couple of key items: Very large, active development team Over the past twelve months, 33 developershttp://www.ohloh.net/p/liftweb/contributorscontributed new code to Lift http://www.ohloh.net/p/liftweb. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 45 developers have contributed. Increasing year-over-year development activity Over the last twelve months, Lift http://www.ohloh.net/p/liftweb has seen a substantial increase in activity. This is probably good sign that interest in this project is rising, and that the open source community has embraced this project. Ohloh makes this determination by comparing total number of commits made by all developers during the most recent twelve months with the same figure for the twelve months before that. The number of developers and total lines of code are not considered. So, a big thanks to the community for driving Lift and another big thanks to the Lift committers for adding so much to Lift! Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Problem with FocusOnLoad and passing attributes through bind
On 22 feb., 04:12, Luke Nezda lne...@gmail.com wrote:
Hello,
I am new to Scala and Lift. I am having a problem using 2 features
together which seem to work fine individually. Here's a simplified
piece of the code:
class Ajax {
def someResult(q:String) = spansome results for query {q}.../
span
// searchField closure
def searchField(xhtml: NodeSeq): NodeSeq = {
// build up an ajax text box
def doSearch(msg: NodeSeq) = {
// doesn't compile with bind: searchBox -% doSearch _
FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
someResult(q
// compiles with bind: searchBox -% doSearch _
// SHtml.ajaxText(, q = SetHtml(resultz, someResult(q)))
}
// bind the view to the functionality
bind(ajax, xhtml,
searchBox - doSearch _
// doesn't compile if doSearch returns result of FocusOnLoad
//searchBox -% doSearch _
)
}
}
and the template invocation:
lift:surround with=default at=content
lift:Ajax.searchField id_msgs=messages
ajax:searchBox class=text type=search tabindex=1 /
hr class=space/
div id=resultz/div
div id=messages/div
/lift:Ajax.searchField
/lift:surround
My goal is an Ajax-enabled text input that gets focus when the page
loads and has various attributes of the input element set. I realize
I can use the SHtml.ajaxText variant that takes attribute-value pairs,
as in:
FocusOnLoad(SHtml.ajaxText(, q = SetHtml(resultz,
Yawni.query(q)), (class, text), (type, search), (tabindex,
1)))
but I'm trying to keep the various element attributes in the template.
When I try to bind with:
searchBox -% doSearch _
instead of:
searchBox - doSearch _
I get the following compile error:
snippet/Ajax.scala:109: error: overloaded method value -% with
alternatives ((scala.xml.NodeSeq) =
scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam and
(Option[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindParam and
(net.liftweb.common.Box[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindPa
ram
and (scala.xml.Elem)net.liftweb.util.Helpers.FuncBindParam cannot be
applied to ((scala.xml.NodeSeq) = scala.xml.NodeSeq)
searchBox -% doSearch _
^
one error found
Why your doSearch function takes a msg parameter? ... it doesn't seam
to use it.
doSearch _ is a partially applied function and acts as a (NodeSeq) =
NodeSeq however -% has only a definition like:
def -%(in: NodeSeq = Elem)
while - also has
def -(in: NodeSeq = NodeSeq)
which is why you get the compile error. We should add the same
definition for NodeSeq = NodeSeq
You can simply say:
searchBox -% doSearch
and have def doSearch: NodeSeq = ...
FocusOnLoad returns a NodeSeq because it returns a sequence of nodes
which conceptually cannot be converted to an elem. You could try to
have a Group(FocusOnLoad ...) ... but Group is a Node not an Elem.
Between all the bind() and -()/-%() overloads and my general Scala /
Lift ignorance, I can't understand what the right way to resolve this
is. I think it has something to do with FocusOnLoad returning a
NodeSeq (input/script/) vs. an Element, but I don't know where to
go from here...
Thanks in advance,
- Luke
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: superficial first impressions from a rails junkie
Yes we know ... we are working to change the Lift website but it's going slower than I expected to. On 6 mar., 08:34, ngocdaothanh ngocdaoth...@gmail.com wrote: I think with its power and number of developers, Lift can have a better home page. At least better than this because it only has one developer:http://nitrogenproject.com/ -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: File Download
If you want to download through Lift than yes you can use
StreamingResponse, or simply any other LiftResponse (depending on your
mime-type) and use LiftRules.dispatch mechanism. But you could also
let the container to serve the file. By default Lift is trying to
serve .html, .xhtml, .htm, .xml etc.. You can write your own rules by
setting
LiftRules.liftRequest = {
case req = true // Pattern match whatever you like and return a
Boolean
}
If Lift cannot find a resource for some reason and you want the
container (or subsequent filters) to handle that you can set
LiftRules.passNotFoundToChain = true
On 4 mar., 17:09, DavidV david.v.villa...@gmail.com wrote:
I am also looking to download a file from the server that is hosting
my Lift web app. There is a very useful fileUpload method in the
SHtml class and I was wondering if there may be something similar for
a file download? I was unable to find anything, and searching for
Lift or Scala Lift download on Google returns nothing but pages to
download the libraries, plugins or source code. I suppose I could use
the StreamingResponse, but I am already saving the file I need to the
server and it would be nice to be able to download it to any client
computer with the typical Browse button, similar to the upload,
Thanks,
David
On Feb 14, 3:58 pm, Gang wangga...@gmail.com wrote:
Thanks Tim, that's exactly what I'm looking for!
On Feb 14, 11:27 am, Timothy Perrett timo...@getintheloop.eu wrote:
See:
http://blog.getintheloop.eu/2009/3/19/understanding-lift-s-streamingr...
Construct the CSV in memory and just then stuff it into a streaming
response as a byte array.
Cheers, Tim
On 14 Feb 2010, at 16:18, Gang wrote:
Hi,
I have a question and it may not be a pure Lift one. But since I'm
working on a Lift app and this group is the most responsive one I have
seen, might just try it here.
I need todownloaddata from database in CSV format. What is the best
approach within Lift framework? Do I have to write the data on the
server somewhere and then provide user with a link? I have tried to
google scala, lift,filedownload..., but could not come up with
what I'm looking for. Maybe I didn't use the right key words in
search? Thanks in advance!
Brs
Gang
--
You received this message because you are subscribed to the Google
Groups Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.-Hidequoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: minified js artifacts (was Re: Re-opened #363)
Folks let's keep in mind that even now users can decide whichever version they want for the underlying js script framework. Just override override def pathRewriter: PartialFunction[List[String], List[String]] from the JsArtifacts. JQuery13Artifacts and JQuery14Artifacts are just helpers and IMHO these should point to the minified versions. Br's, Marius On 3 mar., 20:39, Peter Robinett pe...@bubblefoundry.com wrote: I like Jeppe's option: Or 2.5: use 1. for the js artifacts included with Lift and let the user decide how to handle their own js files. I would hate to be forced into using the yui compressor for my own files that I put in toserve (not that it isn't a good idea :-) This lets us keep plain js source in Lift (makes upgrading included js artifacts easier and gives nicer diffs) while giving the user complete control over their own files (e.g. perhaps they don't want a file minified in test mode so that they can more easily track method calls via Firebug). Peter On Mar 3, 9:19 am, Indrajit Raychaudhuri indraj...@gmail.com wrote: On 03/03/10 10:21 PM, Jeppe Nejsum Madsen wrote: Indrajit Raychaudhuriindraj...@gmail.com writes: [...] My interest in the current context, is to have consistent behavior in the js artifacts bundled with Lift. To me (and Marius) #2 is also worth consideration. True that you'd have a compressed (IDE unfriendly) js in the codebase but you'd also be able to remove build-time dependency on yui compressor. (one less dependency, one less step etc.) But why is it a problem with the build-time dependency on yui compressor if it only concerns the building of the lift-*.jar? Or am I missing something? No question with the worthiness of yui-compressor as such, it does the job perfectly and great for the purpose :) It about when to use it. If we are using it to minify the set of third party js files (jquery, json etc.) repeatedly which never change we might as well consider keeping the minified form directly. Hence the worthiness behind consideration. Note that Lift's internal js files (e.g., jlift.js) are fine going the yui-compressor route. But more than anything, we need to be consistently following either of these (particularly for the 3rd party js artifacts). Ideally the lift jars should contain both, and the non-minified used in development. Yes, better. Which actually led to the other thought (#3). But git should contain only one form in that case (the un-minified one). /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Javascript Dependencies
Yes I believe this needs a bit more thinking. I didn;t spend too much
time into this but perhaps add a LiftRules function to describe the
dependency tree per page:
i.e.
var jsDependencies : (Req) = JsDependencyTree
where
case class JsDependencyTree (url: String, dependencies:
JsDependencyTree *) // not sure if we'd need more info
The head merge (and potentially tail merge as well) mechanism in Lift
would obtain the JsDependencyTree from LiftRules passing the Req
(hence you can have a different dependency tree per page, or per
application depending how you do pattern matching). Thus head merge
would arrange the scripts according to the dependency tree. If a
script is not in the dependency tree, it will just be appended to the
scripts list. Adjacent features that I see:
1. Detect if a dependency is missing
2. Construct a suite of dependency trees for most used JQuery plugins
that people can easily re-use.
Br's,
Marius
On Mar 1, 1:54 am, Peter Robinett pe...@bubblefoundry.com wrote:
Issue 281 is not going to make it into M3. The specific issue that
needs to be solved first is how to manage dependencies across multiple
snippets on one page. See the Assembla page for more
information:http://www.assembla.com/spaces/liftweb/tickets/281
Peter
On Feb 26, 5:14 pm, Peter Robinett pe...@bubblefoundry.com wrote:
Mads, thanks for bringing ticket 281 to my attention, I'll address it
in my patch.
Jeppe, that's how I plan on using it with Flot: having Flot.init
register the plugins and in the charts call toHTML as needed.
Should have everything up on my pr1001_issue_322 branch by tomorrow.
Peter
On Feb 25, 1:14 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Peter Robinett pe...@bubblefoundry.com writes:
Hi all,
[...]
// Usage in boot.scala
val myJsScript = new JsScript(flot :: jquery.flot.selectable.js ::
Nil)
ResourceServer.allow(myJsScript.allowResource)
// Usage in a normal snippet
def mySnippet = {
head
{ myJsScript.toHTML }
/head
div
The rest of the snippet...
/div
}
// Usage in a CometActor
class myActor extends CometActor with JsScriptDependency {
override def scripts = List(new JsScript(flot ::
jquery.flot.selectable.js :: Nil));
}
What do you think? It's a really quite basic but I think such an
approach could work well for things like as lift-flot.
It might be a start :-) I'm a little unsure if it supports the use case
I would like to see:
I'm using jqPlot (a flot-like lib) and would like to, in boot, just
initialize the widget:
jqPlot.init
jqPlot comes with numerous plugins and this should be handled by the
widget. Whether a plugin is loaded on a page depends on some higher
level structure. Ie. if I wish to draw a pie chart, the pie chart plugin
should be loaded.
Looking back at this, it seems like this could work with the above
In init: register all plugins
In the specific charts, call toHtml on the plugins needed
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Javascript Dependencies
On Mar 1, 1:50 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Marius marius.dan...@gmail.com writes: Yes I believe this needs a bit more thinking. I didn;t spend too much time into this but perhaps add a LiftRules function to describe the dependency tree per page: i.e. var jsDependencies : (Req) = JsDependencyTree where case class JsDependencyTree (url: String, dependencies: JsDependencyTree *) // not sure if we'd need more info The head merge (and potentially tail merge as well) mechanism in Lift would obtain the JsDependencyTree from LiftRules passing the Req (hence you can have a different dependency tree per page, or per application depending how you do pattern matching). Thus head merge would arrange the scripts according to the dependency tree. If a script is not in the dependency tree, it will just be appended to the scripts list. I can't help to think this is a bit too low level. I would hate to have to go in and modify LiftRules everytime I add/change something on a page. Or maybe I don't understand it correctly? The way I see it, we can have some named values that corresponds to files that need to be included (not sure about actual syntax), ie In snippet A: I need flot In snippet B: I need flot-piechart-plugin It seems fairly straight forward to compute a tree of dependencies (basically the JsDependencyTree) having the correct order depending on the above declarations: Process snippets in order and avoid duplicates: A needs Flot which needs Jquery - [jquery, flot] B needs flot-piechart-plugin which needs flot which needs jquery - [jquery, flot] ++ [jquery, flot, flot-piechart-plugin] = [jquery, flot, flot-piechart-plugin] I'm not sure that doing this per snippet is the right approach. The reason I'd put it LiftRules is that it CAN use a dependency tree per page ... after all, scripts are specified per page. There will have to be some validations (circular dependencies etc), but this should be fixable Adjacent features that I see: 1. Detect if a dependency is missing 2. Construct a suite of dependency trees for most used JQuery plugins that people can easily re-use. That would be cool /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Javascript Dependencies
Yes we do have different perspectives. I'm saying for page X here these are the JS dependencies whether you seem to say here is a snippet, and it needs these dependencies I'd still prefer my paradigm (not because of my ego) because it'd be easier to manage redundancies, it applies generically for snippets, comet actors etc. without having to induce other type of API. It is maybe coarse grained vs. your proposal that seems to me finner grained. However I'd be happy to see an implementation of any of these proposals. Maybe other people would have better ideas so perhaps Peter and/oryou could dig could make this happen? Br's, Marius On Mar 1, 2:45 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Marius marius.dan...@gmail.com writes: [...] I'm not sure that doing this per snippet is the right approach. Maybe we differ in our thinking then :-) I'm thinking more in a component oriented approach where I would like to put a widget on a page. I'll just add the correct snippet tags to my page and don't want to worry about which js dependencies I need to include before the snippet works. The reason I'd put it LiftRules is that it CAN use a dependency tree per page ... after all, scripts are specified per page. Yeah, maybe some flexibility is needed and as usual it seems like a good idea to have the low level foundations in place first and build the higher level abstractions on top. If we have the function in LiftRules it should be possible to what I want by creating a smarter Req = Tree function. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 do I add sitemap.xml and robots.txt
To served back an xml file you'd probably want to use proper mimetype
text/xml, or application/xml.
Id' recommend using DispatchPf. In Boot:
val dispatcher: LiftRules.DispatchPF = {
case Req(sitemap :: Nil, xml, _) = () = Full(new
XmlResponse(cities
city name=Boston/
city name=New York/
city name=San Francisco/
city name=Dallas/
city name=Chicago/
/cities)
}
LiftRules.dispatch.prepend(dispatcher);
On Feb 28, 3:03 am, Bob Folkerts robertfolke...@gmail.com wrote:
I'm trying to add robots.txt and a sitemap.xml to a web site. My
Boot.scala has a snippet that looks like
val entries = Menu(Loc(Home, List(index), Home)) ::
galleryMenu :: servingYouMenu ::
socialSitesMenu :: aboutUsMenu ::
Menu(Loc(ContactUs, List(ContactUs), Contact
Us)) ::
Menu(Loc(robots, List(robots.txt),
robots.txt, Hidden)) ::
Menu(Loc(sitemap, List(sitemap.xml),
sitemap.xml, Hidden)) ::Nil
The robots.txt file shows up right away, but I get a 404 when I try to
access /sitemap.xml . I have a static sitemap.xml that I want to
include. I tried this as a static xml file in the webapp directory.
I also tried it without the explicit '.xml', but I had the same
results. I tried to make it look more like my html, so I added a
sitemap-tempate.xml in templates-hidden and had the sitemap.xml
reference that.
Eventually, I would like to generate the sitemap.xml from the SiteMap
assuming that the user has not logged into the application. I would
also assume that for most users, a default robots.txt would be easy to
generate. This seems like something of general utility that would be
a good chance to learn more about Lift.
Can anyone explain how to display the simple, static sitemap.xml. I'm
sure this is a newbie mistake, but I'm not seeing it on my own.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: serving images from a directory
If you want Lift to serve images you should put them in /resources/
toserve folder and reference them as /classpath/{image file}
If you want to put images say in /img folder at the same level with /
WEB-INF for example, you just reference tham /img/{image file} ...
these will not be served by Lift but by web container.
There is no need for SiteMap when serving other resources.
On Feb 27, 10:53 am, jack jack.wid...@gmail.com wrote:
I would like to access an image on the client via a URL. How do I
generate that URL. Currently, I'm getting the error
The requested page was not defined in your SiteMap, so access was
blocked.
I understand what this error means for html pages. How does it work
for images?
Thanks.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: The role of LiftRules
Well you summarized pretty well what I feel about this. Essentially the way I see it startup configuration things could exists in other classes/objects but should be accessible through LiftRules. A little off-topic ... I'm not at all a FactoryMaker-s fan :p Br's, Marius On Feb 26, 5:01 am, Naftoli Gugenheim naftoli...@gmail.com wrote: Hi, I'd like to get some opinions on the following. You may want to readhttp://reviewboard.liftweb.net/r/158/. I have on Review Board a patch for some date-and-time parsing and formatting configuration. I put the settings inside a singleton object called ConversionRules. The question is, where do these configurations belong? Marius feels that LiftRules is the place where people look for all Lift-related configuration. So that the LiftRules code shouldn't become too monstrous, it makes sense to put the code in ConversionRules and have a val in LiftRules pointing to ConversionRules. My opinion is that LiftRules is, at least for the most part, http- (lift-webkit) related, and should be that way. I would actually prefer to ConversionRules in lift-util, but it relies on Factory which is in webkit. Preferably Factory could be moved to lift-util and ConversionRules with it. Now I suppose pointing LiftRules to ConversionRules is possible even if the latter is moved to lift-util, so I guess it really boils down to whether it would be beneficial for ConversionRules to be presented as side by side with LiftRules, or as a member of it. (If the latter, I suppose ConversionRules could be made private[liftweb] so there's only one path to it...) Thoughts? Thanks! -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Direct access to response.outputStream?
On Feb 26, 11:50 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, I need to create a response that downloads a file. The file is generated by a 3rd party api that takes an output stream as the target for the file. As the file can be rather large, I would like to stream this file directly to the client. I've looked at StreamingResponse, but this seem to require something akin to an input stream. As there a way to generate a response with direct access to the output stream? No. IMO this would bring serious problems related with committed response if people will start writing directly into servlet's response output stream. But you should be able to bridge the outputstream needed by that library and the inputstream from the StreamingResponse ( which takes a structural type not really an InputStream) through mechanisms similar with Pipes. You could also build your own OutputStream that also has def read(buf: Array[Byte]): Int. Thus your library will write stuff in your OutputStream, you would then buffer the data and wait for that data to be drained by the servlet's input stream. A simple producer/consumer approach. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Direct access to response.outputStream?
On Feb 26, 1:29 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
On Fri, Feb 26, 2010 at 12:06 PM, Jeppe Nejsum Madsen je...@ingolfs.dk
wrote:
So the thread creation/scheduling and the two times file copying could be
avoided by writing directly to the output stream. But I agree this would
have to be special cased somehow. It's not an urgent issue atm, but I'll
try to see if some clean solution can be implemented.
An idea just struck :-) Could this be handled in much the same way as
a redirect? Something like
S.sendFile(application/pdf, myfilename.pdf, outputStream =
mylibrary.write(outputStream))
this would throw an exception like ResponseShortcutException, lift
would intercept it, write the appropriate headers and execute the
passed function with the response outputstream as parameter.
This would prohibit accidental output to response.
Thoughts?
I would prefer something like :
final case class OutputStreamingResponse(data: (OutputStream) = Unit,
size: Long, headers: List[(String, String)], cookies:
List[HTTPCookie], code: Int) extends BasicResponse {
..
}
hence remain consistent with Lift's response paradigm.
We *COULD* provide the OutputStrem from the servlet response but that
would be ok since we are in a LiftResponse and NOT inside the
rendering pipeline.
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Reasoning Behind Box
Box has : 1. A rather richer API than Option 2. The Failure case that you are already aware of = a logical existence of Box-ification. I fail to see what is the problem that we use Box and not Option especially that you can seamlessly convert one to the other. Is there a law that we should have been using Option? Are the methods naming differences so dramatic that induces such confusion ? - I do not feel this in practice. It sometimes seems to me that people are view-ing Option as an absolute term - a complete Maybe monad that everyone should obey. Br's, Marius On Feb 26, 4:30 pm, Daniel Spiewak djspie...@gmail.com wrote: Either would be the purely stdlib way to go, and Naftoli is right that it would be a lot more verbose. I would argue that the difference isn't *so* substantial if you sprinkle in a type alias and some implicit conversions (so that you can map/flatMap/filter over something of type Either[Option[A], String]). I am aware of the Failure case, and that's why I argue that Box *isn't* a drop-in Option replacement. API naming differences are inconsequential, but adding another case to the ADT is a pretty dramatic difference. However, Lift seems to use Box *everywhere*, even in places where it is only using it as if it were Option. Daniel On Feb 26, 1:17 am, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 26 February 2010 08:09, Naftoli Gugenheim naftoli...@gmail.com wrote: Either -- but it's more verbose. I'm not so sure David will want to rewrite the entire lift anyway... Right now, I only would like to listen to Daniel, OK? Heiko Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 execute JsCmd after submit
Well it looks like you are submitting a non ajax form. You can easily
use ajax forms.
something like:
def calcForm(xhtml:NodeSeq):NodeSeq = {
SHtml.ajaxForm(Helpers.bind(f, xhtml,
age - SHtml.text(ageVar.is.toString, v = ageVar(v.toInt)),
male - SHtml.text(maleVar.is.toString, v =
maleVar(v.toBoolean)),
submit - SHtml.ajaxSubmit(Calculate, () = {
// return your JSCmd here
}),
le - le.toString
))
On 26 feb., 18:58, sdillard spencer.dill...@gmail.com wrote:
I am probably confused on what exactly is going on in the request /
response cycle here, but I am trying to show a table cell after a
calculation is performed, and I can't seem to get the js to run. The
JS is being called in the showResults method that is bound to the
submit action. I am guessing that the submit action is reloading the
page, so there is no opportunity to run the js. Any suggestions on
how I should be doing this instead? I am learning lift, and I am
working on an app that needs to be completely stateless (no db
backend, no cookies, no session).
I have the following for my page:
lift:surround with=default at=content
table
tbody
tr
td
lift:mortality.calcForm form=POST id=mortalityForm
Age: f:ageinput
type=text//f:agebr/
Male: f:maleinput
type=text//f:malebr/
f:submitinput type=submit
value=calculate//f:submit
/lift:mortality.calcForm
/td
td id=mortalityResult style=display:none;
lift:mortality.doCalculate
Life Expectancy: r:le50/r:le
/lift:mortality.doCalculate
/td
/tr
/tbody
/table
/lift:surround
Then in my snippet code I have the following:
class Mortality {
object ageVar extends RequestVar[Int](S.param(age).map(_.toInt)
openOr 0)
object maleVar extends RequestVar[Boolean]
(S.param(male).map(_.toBoolean) openOr false)
var le = 0
def calculateLifeExp = {
val calcLE = Annuity2000.lifeExpectancy(ageVar.is, maleVar.is)
le = String.format(%.2f,double2Double(calcLE))
}
def doCalculate(xhtml:NodeSeq):NodeSeq = {
calculateLifeExp
Helpers.bind(r, xhtml,
le - le.toString
)
}
def showResults():JsCmd = {
JsCmds.Run($('#mortalityResult').show();alert('I ran'))
}
def calcForm(xhtml:NodeSeq):NodeSeq = {
Helpers.bind(f, xhtml,
age - SHtml.text(ageVar.is.toString, v = ageVar(v.toInt)),
male - SHtml.text(maleVar.is.toString, v =
maleVar(v.toBoolean)),
submit - SHtml.submit(Calculate, showResults),
le - le.toString
)
}
}
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Logging, part 2
I'd opt in for something like: LiftRules.logger = Log4J or LiftRule.logger = MyOwnLogger Br's, Marius On Feb 25, 11:23 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, I'm about to start sprinkling the new logging code over some of Lift's internals. But first, the logging backend needs configuring. When the dust has settled and the new logging code is fully implemented, this needs to happen in a client app: 1) Choose a logging backend and add the dependency (ie slf4j-log4j or logback-classic) 2) Initialize the logging backend For step 2) I was thinking of some simple helpers that configures the logging backend using lift's properties: Log4j.configure Logback.configure Very simple, so I don't think there is a need to specify a setup function in either LogBoot or LiftRules. But opinions wanted! The current logging code will be deprecated and until removed, the following will happen: 1) slf4j-log4j will be added as dependency to lift-util 2) The current LogBoot.loggerSetup will call Log4j.configure Thoughts? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Logging, part 2
Then perhaps: LiftRules.initLogger(Log4J) On Feb 25, 12:16 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Thu, Feb 25, 2010 at 10:32 AM, Marius marius.dan...@gmail.com wrote: I'd opt in for something like: LiftRules.logger = Log4J Agree this fits the current idioms, but how should this be triggered? The new logging code is in lift-common so cannot call stuff in LiftRules. Note we're not talking about Loggers (objects that have warn info methods) but about configuring the logging system, which needs to be done before Loggers can be used. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Advice for maintaining application state
Why SessionVars are almost always a bad idea IMHO ? On Feb 24, 9:54 pm, tiro tim.romb...@googlemail.com wrote: Hi, I had a similar discussion on this list a while ago. http://groups.google.com/group/liftweb/browse_thread/thread/69898fb51... I haven't found THE idiomatic answer in Lift. For now I'm using StatefulSnippets for the more complex cases; they work quite well. SessionVars are almost always a bad idea IMHO. For the simple cases I pass URL parameters around. The thing to remember is that the StatefulSnippet lifecycle is held together only by hidden fields whose value is posted back (as explained in the Lift book). So the user can easily work with different state sets (StatefulSnippets) in parallel on different tabs. Best wishes, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: bind(): suppress automatic attribute mixin
1. what Lift version are you using? 2. Can you try with other attribute name or with multiple attributes? On Feb 25, 6:53 pm, jasper jasper.raedi...@gmail.com wrote: val xml = t:node attr=some/t:node with val processed = bind(t,xml, node - a /) becomes a attr=some/a How do I suppress the mixin of attr? Thank you, Jasper -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Logging, part 2
Why not? LiftRules is about configuring a lift app at startup. On 25 feb., 16:56, Naftoli Gugenheim naftoli...@gmail.com wrote: Why should an initLogger method be in LiftRules? - Mariusmarius.dan...@gmail.com wrote: Then perhaps: LiftRules.initLogger(Log4J) On Feb 25, 12:16 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Thu, Feb 25, 2010 at 10:32 AM, Marius marius.dan...@gmail.com wrote: I'd opt in for something like: LiftRules.logger = Log4J Agree this fits the current idioms, but how should this be triggered? The new logging code is in lift-common so cannot call stuff in LiftRules. Note we're not talking about Loggers (objects that have warn info methods) but about configuring the logging system, which needs to be done before Loggers can be used. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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] This is the style of SQL persistence that I like ...
Maybe most of you have seen it: http://max-l.github.com/Squeryl/ Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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] *Minor breaking change* - issue #363
Folks, The ability to specify the JQuery version was changed from: LiftRules.jQueryVersion = ... to LiftRules.jsArtifacts = JQuery14Artifacts // this points to JQuery 1.4.2. By default this points to JQuery13Artifacts which points to jQuery 1.3.2 Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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] LiftRules.jQueryVersion ... :(
Guys,
This has been added not so long ago, and I am aware that I should
express my perspective on this back then as now it might be too late.
IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
ResourceServer should not even be aware of the underlying JS framework
thus the JQuery name in LiftRules is very unsound to me.
Here is other proposal of keeping things decoupled:
.
We currently have JQueryArtifacts which holds the JQuery
implementation.
We add in the JsArtifacts this:
trait JsArtifacts {
...
def version
}
then
case class JQueryArtifacts1_3_2 extends JQueryArtifacts {
def version = 1.3.2-min
}
case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
def version = 1.4.1-min
}
Then to select one or another we use the existent mechanism:
LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
can change this easily
then in ResourceServer we can easily make the version selection.
In this way LiftRules has no idea about JQuery, YUI etc and it
doesn't need to. it is only about feeding different implementations of
JsArtifact.
Thoughts?
Br's,
Marius
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: LiftRules.jQueryVersion ... :(
(yeah forgive me :) ...)
On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
+1 (and we might as well add 1.4.2 as well/instead :-)
On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
Guys,
This has been added not so long ago, and I am aware that I should
express my perspective on this back then as now it might be too late.
IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
ResourceServer should not even be aware of the underlying JS framework
thus the JQuery name in LiftRules is very unsound to me.
Here is other proposal of keeping things decoupled:
.
We currently have JQueryArtifacts which holds the JQuery
implementation.
We add in the JsArtifacts this:
trait JsArtifacts {
...
def version
}
then
case class JQueryArtifacts1_3_2 extends JQueryArtifacts {
def version = 1.3.2-min
}
case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
def version = 1.4.1-min
}
Then to select one or another we use the existent mechanism:
LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
can change this easily
then in ResourceServer we can easily make the version selection.
In this way LiftRules has no idea about JQuery, YUI etc and it
doesn't need to. it is only about feeding different implementations of
JsArtifact.
Thoughts?
Br's,
Marius
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: LiftRules.jQueryVersion ... :(
I opened this ticket:
http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryversion-should-not-be-there-
I realize that this would bring a slight breaking change but I believe
it is worth it.
Folks please speak up if you think otherwise.
Br's,
Marius
On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
(yeah forgive me :) ...)
On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
+1 (and we might as well add 1.4.2 as well/instead :-)
On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
Guys,
This has been added not so long ago, and I am aware that I should
express my perspective on this back then as now it might be too late.
IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
ResourceServer should not even be aware of the underlying JS framework
thus the JQuery name in LiftRules is very unsound to me.
Here is other proposal of keeping things decoupled:
.
We currently have JQueryArtifacts which holds the JQuery
implementation.
We add in the JsArtifacts this:
trait JsArtifacts {
...
def version
}
then
case class JQueryArtifacts1_3_2 extends JQueryArtifacts {
def version = 1.3.2-min
}
case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
def version = 1.4.1-min
}
Then to select one or another we use the existent mechanism:
LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
can change this easily
then in ResourceServer we can easily make the version selection.
In this way LiftRules has no idea about JQuery, YUI etc and it
doesn't need to. it is only about feeding different implementations of
JsArtifact.
Thoughts?
Br's,
Marius
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
On Feb 22, 8:12 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Sun, Feb 21, 2010 at 9:49 AM, Marius marius.dan...@gmail.com wrote: Guys, I'm starting to have second thoughts about having css or js combine (concatenation of multiple files into a single response) on lift side. I'm starting to question that real benefits as in production sites in many cases the lift app has a http reverse proxy front end that can serve static content js/css etc. Thus combining multiple js/css with simple tools seems more practical. Thoughts? By simple tools I assume you mean at build time? How would this handle classpath resources? Yes on build time. /classpath/myresourcescombined.css will reside in the reverse proxy. This file will reside in the reverse proxy document root. I don't think that doing it on the lift side conflicts with the reverse proxy. If everything is configured correctly, the proxy should only fetch the resource from lift once, see that the resource expires far in the future and cache it. There are a number of (I think) conflicting scenarios that Lift should support: 1) Good defaults that deliver great performance out of the box without too much hassle during development/build/deploy time. This is where I think Lift combining resources would be used. I somehow disagree. IMO production tuning is necessary regardless of the web framework used. How do other frameworks behave in this are. I don't know of any that does the resources combining and claim that this is preferable then using the reverse proxy. 2) The absolute best performance no matter what. I think this is a utopia.In my experience having reverse proxies serving static content (combined wherever possible) will give you best performance. The application server should not be burden with serving static content as long as there are cheap reverse proxies out there. This probably includes multiple hosts for static resources, CDNs etc. If you're going this route you're willing to sacrifice ease of use for that last ounce of speed. Application performance should be tuned in production environments. I don't see where the ease of use sacrifice is. Lift apps will function properly without a reverse proxy but the reverse proxy is much more suitable for serving static content than the application server which will be burden with other requests. If/when load time becomes an issue for us this will be one of the first things I'll try to investigate :-) /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: LiftRules.jQueryVersion ... :(
Personally I think Jon followed the correct process. I do remember
discussions on this list and on review board. JsArtifacts is somehow
under-explored ... I carry a good part of the blame as I should have
pointed the perspective towards JsArtifacts.
Anyways the proposed fix for #363 is on the review board now.
Essentially the JsArtifacts implementation owns the path rewriting
rules now for its own domain.
Br's,
Marius
On 23 feb., 22:04, Timothy Perrett timo...@getintheloop.eu wrote:
Jon, did it go through a discussion on the mailing list? I dont
remember seeing it? (and I cant find it in the archives if it was)
Anything like this really needs discussion on the mailing list as its
fundamental to the Lift story and we need to maintain a consistent
API.
Cheers, Tim
On Feb 23, 7:48 pm, Jonathan Hoffman jonhoff...@gmail.com wrote:
I originally added LiftRules.jQueryVersion, but I agree that this is a much
better solution.
thanks,
- Jon
On Feb 23, 2010, at 6:00 AM, Marius wrote:
I opened this
ticket:http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryve...
I realize that this would bring a slight breaking change but I believe
it is worth it.
Folks please speak up if you think otherwise.
Br's,
Marius
On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
(yeah forgive me :) ...)
On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
+1 (and we might as well add 1.4.2 as well/instead :-)
On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
Guys,
This has been added not so long ago, and I am aware that I should
express my perspective on this back then as now it might be too late.
IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
ResourceServer should not even be aware of the underlying JS framework
thus the JQuery name in LiftRules is very unsound to me.
Here is other proposal of keeping things decoupled:
.
We currently have JQueryArtifacts which holds the JQuery
implementation.
We add in the JsArtifacts this:
trait JsArtifacts {
...
def version
}
then
case class JQueryArtifacts1_3_2 extends JQueryArtifacts {
def version = 1.3.2-min
}
case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
def version = 1.4.1-min
}
Then to select one or another we use the existent mechanism:
LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
can change this easily
then in ResourceServer we can easily make the version selection.
In this way LiftRules has no idea about JQuery, YUI etc and it
doesn't need to. it is only about feeding different implementations of
JsArtifact.
Thoughts?
Br's,
Marius
--
You received this message because you are subscribed to the Google
Groups Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
Guys, I'm starting to have second thoughts about having css or js combine (concatenation of multiple files into a single response) on lift side. I'm starting to question that real benefits as in production sites in many cases the lift app has a http reverse proxy front end that can serve static content js/css etc. Thus combining multiple js/css with simple tools seems more practical. Thoughts? Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Has anyone gotten the uservoice javascript to work?
In boot try setting LiftRules.useXhtmlMimeType = false;
If that doesn't work please try to set up a minimalistic lift app that
you can share so we can try it really quick and diagnose.
Br's,
Marius
On 20 feb., 19:43, Jim Barrows jim.barr...@gmail.com wrote:
I'm trying to get the uservoice widget working correctly, but it doesn't
like working from the server, but works from a file just fine when I view
source and copy and paste to a file. Any help would be appreciated!
Uservoice adds it's feedback tab via some javascript that looks like:
script type=text/javascript
var uservoiceOptions = {
/* required */
key: 'customerelevator',
host: 'customerelevator.uservoice.com',
forum: '39338',
showTab: true,
/* optional */
alignment: 'left',
background_color:'#f00',
text_color: 'white',
hover_color: '#06C',
lang: 'en'
};
function _loadUserVoice() {
var s = document.createElement('script');
s.setAttribute('type', 'text/javascript');
s.setAttribute('src', (https: == document.location.protocol ?
https://; : http://;) +
cdn.uservoice.com/javascripts/widgets/tab.js);
document.getElementsByTagName('head')[0].appendChild(s);}
_loadSuper = window.onload;
window.onload = (typeof window.onload != 'function') ? _loadUserVoice
: function() { _loadSuper(); _loadUserVoice(); };
/script
You add it at the end of the page, near the /body tag. I put tthe
//![CDATA[wrapper around the javascript itself:
script type=text/javascript
// ![CDATA[
/* Javascript from above goes here */
// ]]
If I view source, and copy/paste the code to a file, it works just fine.
When I addhttp://localhost:8080to all the now broken links, it works just
fine. It's just when I view the page from the server that it's b0rked.
--
James A Barrows
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: London Lift talk
Neat ! ... will there be any video ? Br's, Marius On 20 feb., 22:22, andy andy1...@gmail.com wrote: Hi all The London Scala User Group (LSUG) will be presenting a talk by Richard Dallaway on 'Getting started with Lift' at SkillsMatter on the March 8th 2010 at 6:30. This will be a general talk on the basic of Lift, what can be achieved and how you can perform common web tasks. For details of this talk can be found at:http://www.meetup.com/london-scala/calendar/12468165/ and to sign up:http://skillsmatter.com/event/java-jee/getting-started-with-lift All are welcome, and there will be a visit to the pub afterwards. andy -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 put UTF string into the redirect URL?
I think you need to URL encode it. On 21 feb., 04:33, wm min...@gmail.com wrote: I need put some UTF string into the URL to be redirected, e.g.: str = 'some-UTF-str' S.redirectTo(/foo?bar=+str) But after the redirection, in the browser address bar it becomes:http://localhost:8080//foo?bar=??? '???' is the messed up UTF string. How can I fix this? thanks! -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Comet issue for Lift-2.0-scala280-SNAPSHOT
Can you also try with Scala 2.7.7 ?
On Feb 19, 2:26 pm, tbje trond.bjerkestr...@gmail.com wrote:
Hi,
I've been testing out the Lift-2.0-scala280-SNAPSHOT a little bit and
found a issue with Comet actor, setHtml and ajaxInvoke.
When trying to invoke the following partial update nothing seems to
happen:
partialUpdate(SetHtml(field, input type=button
onclick={ajaxInvoke(() = JsRaw(alert('hi')))._2} value=Say hi /
))
This works as expected however:
partialUpdate(SetHtml(field, a(() = JsRaw(alert('hi')),
spanLink/span)))
I've created a example app to illustrate the problem if someone is
interested:
git://github.com/tbje/Lift-2.0-scala280-SNAPSHOT-issue.git
Best regards
Trond
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Comet issue for Lift-2.0-scala280-SNAPSHOT
Yeah AFAIK Scala 2.8 integration is not 100% done and fully tested.
Br's,
Marius
On Feb 19, 3:52 pm, tbje trond.bjerkestr...@gmail.com wrote:
Hi Marius,
I discovered the issue while porting a working application from 2.7.7
to lift 2.0-scala280-SNAPSHOT and scala 2.8.0.Beta1.
In the example application I provided it's possible to change the
pom.xml by replacing
scala.version2.8.0.Beta1/scala.version
lift.version2.0-scala280-SNAPSHOT/lift.version
with
scala.version2.7.7/scala.version
lift.version2.0-SNAPSHOT/lift.version
and the application is working as I'd like it to :)
I therefor believe it's a lift 2.0-scala280 issue.
Best regards
Trond
On 19 Feb, 14:12, Marius marius.dan...@gmail.com wrote:
Can you also try with Scala 2.7.7 ?
On Feb 19, 2:26 pm, tbje trond.bjerkestr...@gmail.com wrote:
Hi,
I've been testing out the Lift-2.0-scala280-SNAPSHOT a little bit and
found a issue with Comet actor, setHtml and ajaxInvoke.
When trying to invoke the following partial update nothing seems to
happen:
partialUpdate(SetHtml(field, input type=button
onclick={ajaxInvoke(() = JsRaw(alert('hi')))._2} value=Say hi /
))
This works as expected however:
partialUpdate(SetHtml(field, a(() = JsRaw(alert('hi')),
spanLink/span)))
I've created a example app to illustrate the problem if someone is
interested:
git://github.com/tbje/Lift-2.0-scala280-SNAPSHOT-issue.git
Best regards
Trond
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Error processing SHtml functions withing nested NodeSeq/Scala code
Well so you're using it from your own actor. I would not recommend
this due to state preservation. I mean S context is very likely lost
because your LiftActor is running on a different thread. What you need
is to pass the LiftSession instance to your LiftActor say using some
distinct message like:
case class Init(session: LiftSession)
then in your messageHandler
protected def messageHandler = {
case FileManagerMsg(someMsg) =
{
S.initIfNotInitted(session) {
var fileList = listFilesInDir(/Users/soumik/Movies/)
Log.info(OUTPUT: + fileList)
}
}
}
But I'm not sure from your code wht you do with the output of your
listFilesInDir since that never gets to be rendered.
I strongly recommend using CometActor whenever you want to render
something asynchronously. It does a lots of good things for you.
Br's,
Marius
On Feb 16, 9:33 am, soumik soum...@gmail.com wrote:
Hi Marius,
Thanks for your response. I'm sorry for mis-communicating my problem
earlier. As you pointed out the problem doesn't occur when the call to
the function is made from a CometActor.
In my case too, it was not a CometActor. Rather, it was the LiftActor.
(Sometime back we had different CometActors for different feature
threads, now we have 1 single CometActor which takes care of the
display and different LiftActor threads which do the feature related
stuff. Hence the confusion on my part).
Anyways, here's the relevant code:
-
object TheVideoPlayerThread extends LiftActor
{
val threadName = FileManager
def listFilesInDir(dirName:String): NodeSeq =
{
Log.info(Recursing for: + dirName)
val files = (new java.io.File(dirName)).listFiles
def showFile1() = AAA
li class=fileElem id=dir{dirName}/li
ul
{files.flatMap(f = {
if (f.isDirectory())
{
Log.info(Directory: + f.toString)
listFilesInDir(f.toString)
}
else
{
Log.info(Regular file: + f.getName)
li class=fileElem id=regfile
{SHtml.link(, () = showFile1,
Text(f.getName)) } //This is the line causing the
issue
/li
}
}
)}
/ul
}
protected def messageHandler = {
case FileManagerMsg(someMsg) =
{
var fileList = listFilesInDir(/Users/soumik/Movies/)
Log.info(OUTPUT: + fileList)
}
}
-
(I've omitted some of code in this thread which are not related to the
file listing functionality.)
The problem I see is as soon as I encounter the first file in the
directory specified, it prints - Regular file: filename, but after
that I don't see the log - OUTPUT - The function never returns.
Same function works perfectly in a CometActor and I see the nodeseq of
files in li tags to be rendered.
Also in the same method in my LiftActor object, if I replace the line:
{SHtml.link(, () = showFile1, Text(f.getName)) }
with just
{f.getName}
I see the function return and print the log OUTPUT - .. with the
list of all the files as li entries.
I'm sorry I couldn't give a more concrete example which you could run
and reproduce the issue. I'll appreciate if you could just give this
function a try from any LiftActor object and check the output on
console.
Also, I'm still on 1.1-SNAPSHOT. I've a fairly big codebase, so not
sure if migrating to 2.0-SNAPSHOT will cause any other issues,
particularly with jquery(i'm using lot of jquery plugins dependent on
1.3.2, not sure if all of them works nicely with 1.4).
Thanks,
Soumik
On Feb 15, 11:22 pm, Marius marius.dan...@gmail.com wrote:
I don't think the cause is in SHtml. I tried your code from a snippet
and from a Comet actor and there was no lock whatsoever. But I did use
lift 2.0-SNAPSHOT. can you try with 2.0-SNAPSHOT ?
Br's,
Marius
On 15 feb., 15:20, soumik soum...@gmail.com wrote:
Hi,
I'm using 1.1-SNAPSHOT lift release and am experiencing strange
behaviour when trying to output a NodeSeq formed from nested NodeSeq
Scala code.
To highlight the problem let me show you the code I'm trying to
execute:
---
def listFilesInDir(dirName:String): NodeSeq =
{
Log.info(Recursing for: + dirName)
val files = (new java.io.File(dirName)).listFiles
def playFile1() = AAA
li class=fileElem id=dir{dirName}/li
ul
{files.flatMap(f = {
if (f.isDirectory())
{
Log.info(Directory: + f.toString)
listFilesInDir(f.toString)
span/span
}
else
{
Log.info
[Lift] Re: Cached CSS (and Javascript?) issue
On Feb 16, 3:55 pm, Alex Black a...@alexblack.ca wrote: calculating an md5 of a file would induce additional computation time and we'd need to maintain hashes for each resource file. The prototype that I have now is a function in LiftRules that by default returns a random value generated on startup. Applications that needs MD5 per file could calculate that and maintain them. Hi Marius, what does the proposed token represent? It looks to me like it represents a given resource (css file) per running instance of Jetty. In my prototype it is a random string generated once at startup. So this is the same for all css/js references. But this is imposed just by the default implementation of the LiftRules.attachResourceId function. A different implementation can generate unique MD5 sequences based on each individual file. But I'm not convinced that this should be on the framework side. By using MD5 it instead represents the file itself. Problems with using a token that represents a given resource per running instance of jetty: - if the server restarts you use a new token, so all clients are forced to re-get the 'new' resource Correct. - if you run more than one server, then each server has different tokens, so clients think there are different resources Correct again. I also like the suggestion that a solution to the consolidation problem be kept separate from the problem of generating unique urls for cachable resources (such as CSS, javascript, etc). The MD5 generation if we want it to reflect the file content would take some time to generate. It would indeed happen once if that resource was not seen yet. But along with this there will be other logic: 1. Detect when files changes ... for that we'd need a polling mechanism as we wouldn't want hash calculation on each page rendering. 2. Maintain the hash cache Personally I do not think this is an imperative thing for the framework. I think it is more important for Lift to allow the flexibility to apply this type of logic and this is what I'm aiming to. I agree with you that MD5 approach is more consistent but this random token applied per server instance is not that bad as it's main purpose is not to optimize the resource loading but to have a minimal mechanism to force browsers to refresh the resources if we change css/ js on server side (as the original issue was). Other people may not prefer the MD5 approach but rely more on expiration headers and so on. Your two cases described would be solved by using the MD5 approach but I don't think it is a disaster if we restart the servers clients will fetch again the CSS as they think that the resource changed. Furthermore if one of the committers wants to add this MD5 logic after this support is in, he can certainly do it. To me the proper abstraction in allowing that is more important right now. 2. Consolidation of CSS files on a given page for performance firstly, and secondly for caching. Would there be times when people would not want the behaviour of 2? Im generally not a huge fan of things that mess with user code or could provide uneasy behaviour; im thinking specifically when people build there templates where CSS values are overridden by values loaded after initial value ad unless its munged together right, it might damage the expected behaviour (think blueprint)...? Can I suggest we solve the caching problem using the known hack of random strings, then deal with this proposal of resource consolidation? What I'm playing with is lift:css.combine res:css name=abc.css/ res:css name=def.css/ /lift:css.combine under the hood this would be a function that return a Stream Response that concatenates the streams of files in questions serving them sequentially in the corresponding order. So from Lift's perspective there is no additional computation involved comparing with current situation except we serve desired resources in one response. To sum up the random string is what I think we should start with. IMO it is a fairly good solution that can evolve in time towards something else. Cheers Tim On 13 Feb 2010, at 08:45, Marius wrote: On 12 feb., 23:04, Alex Black a...@alexblack.ca wrote: Yes, that's how it should work if everything was configured correctly (which I think it wasn't for the OP) Heh, I'm the OP. I'll have to dig into why its not working as expected I guess. But what we were discussing (at least I was :-) was more that Lift should serve resources with an Expires date in the far future. That way the browser will only make a single request for a resource (as long as the file is cached). This works well for returning visitors. But of course an updated resource should be fetched, hence the unique filenames. There are some things I like about that solution, but the unique filenames just seems wrong. So I see that a far
[Lift] Re: Error processing SHtml functions withing nested NodeSeq/Scala code
On Feb 16, 11:17 am, soumik soum...@gmail.com wrote:
Hi Marius,
Thanks for the quick update.
The xhtml returned from the listFilesInDir() is actually sent as a
message to a display CometActor which renders the xhtml it receives
within a specific div tag.
So in essence we have these multiple feature threads running(the one
in question is intended to be a local file manager feature) which
generates xhtml for different functions which are then sent to this
one display CometActor which displays it.
So we intend to handle multi-feature tasking by running just the one
CometActor and not multiples of them which obviously is a problem for
lift(since the max no. of CometActors in a page is 2).
But back to your explanation of the S context getting lost, I think I
understand what you mean regarding the session context. But does it
also apply for SHtml generator methods?? I mean, does SHtml generator
methods depend on the state of the session??
Yes if you bind functions. Functions are kept per session.
Another question I have is - even if SHtml generator methods fail to
co-relate the session, shouldn't SHtml generator methods return?? or
throw an exception?
No as SHtml should be used in the proper S context. That's why it is
called [S]html.
I don't know if you happened to use the exact same function in a
LiftActor object or not, but if you do that you'll see that the
function just doesn't return.
Also, I don't intend to maintain state preservation.
You do not explicitly but as you are trying to bind functions (attach
a scla function to a link, button etc) you need the proper context.
I just want to
create a list of a href tags for all files which when clicked should
make an Ajax call to a specific function in the LiftActor thread which
processes the selection. Could you suggest some alternative way I
could go about this with the current architecture(1 comet actor for
display and individual feature-specific LiftActors sending xhtml to
CometActor for rendering)??
Take Dave's advice. It is very good and leads to cleaner separation of
concern.
Thanks,
Soumik
On Feb 16, 1:16 pm, Marius marius.dan...@gmail.com wrote:
Well so you're using it from your own actor. I would not recommend
this due to state preservation. I mean S context is very likely lost
because your LiftActor is running on a different thread. What you need
is to pass the LiftSession instance to your LiftActor say using some
distinct message like:
case class Init(session: LiftSession)
then in your messageHandler
protected def messageHandler = {
case FileManagerMsg(someMsg) =
{
S.initIfNotInitted(session) {
var fileList = listFilesInDir(/Users/soumik/Movies/)
Log.info(OUTPUT: + fileList)
}
}
}
But I'm not sure from your code wht you do with the output of your
listFilesInDir since that never gets to be rendered.
I strongly recommend using CometActor whenever you want to render
something asynchronously. It does a lots of good things for you.
Br's,
Marius
On Feb 16, 9:33 am, soumik soum...@gmail.com wrote:
Hi Marius,
Thanks for your response. I'm sorry for mis-communicating my problem
earlier. As you pointed out the problem doesn't occur when the call to
the function is made from a CometActor.
In my case too, it was not a CometActor. Rather, it was the LiftActor.
(Sometime back we had different CometActors for different feature
threads, now we have 1 single CometActor which takes care of the
display and different LiftActor threads which do the feature related
stuff. Hence the confusion on my part).
Anyways, here's the relevant code:
-
object TheVideoPlayerThread extends LiftActor
{
val threadName = FileManager
def listFilesInDir(dirName:String): NodeSeq =
{
Log.info(Recursing for: + dirName)
val files = (new java.io.File(dirName)).listFiles
def showFile1() = AAA
li class=fileElem id=dir{dirName}/li
ul
{files.flatMap(f = {
if (f.isDirectory())
{
Log.info(Directory: + f.toString)
listFilesInDir(f.toString)
}
else
{
Log.info(Regular file: + f.getName)
li class=fileElem id=regfile
{SHtml.link(, () = showFile1,
Text(f.getName)) } //This is the line causing the
issue
/li
}
}
)}
/ul
}
protected def messageHandler = {
case FileManagerMsg(someMsg) =
{
var fileList = listFilesInDir(/Users/soumik/Movies/)
Log.info(OUTPUT: + fileList)
}
}
-
(I've
[Lift] Re: Error processing SHtml functions withing nested NodeSeq/Scala code
On Feb 16, 8:11 pm, soumik soum...@gmail.com wrote:
Thanks Marius and David for your suggestions.
I'll try that out.
As to the problem itself, don't you think there should some kind of
exception generation to avoid the issue happening?
I still don't think there is a hang involved. Can you wrap your method
call with a try/catch ? ... I have the feeling that a NPE (due to lack
of proper S context) is thrown but because this is thrown on a
different thread (as you'r inside a LiftActor) that is not shown
anywhere.
On Feb 16, 10:35 pm, Marius marius.dan...@gmail.com wrote:
On Feb 16, 11:17 am, soumik soum...@gmail.com wrote:
Hi Marius,
Thanks for the quick update.
The xhtml returned from the listFilesInDir() is actually sent as a
message to a display CometActor which renders the xhtml it receives
within a specific div tag.
So in essence we have these multiple feature threads running(the one
in question is intended to be a local file manager feature) which
generates xhtml for different functions which are then sent to this
one display CometActor which displays it.
So we intend to handle multi-feature tasking by running just the one
CometActor and not multiples of them which obviously is a problem for
lift(since the max no. of CometActors in a page is 2).
But back to your explanation of the S context getting lost, I think I
understand what you mean regarding the session context. But does it
also apply for SHtml generator methods?? I mean, does SHtml generator
methods depend on the state of the session??
Yes if you bind functions. Functions are kept per session.
Another question I have is - even if SHtml generator methods fail to
co-relate the session, shouldn't SHtml generator methods return?? or
throw an exception?
No as SHtml should be used in the proper S context. That's why it is
called [S]html.
I don't know if you happened to use the exact same function in a
LiftActor object or not, but if you do that you'll see that the
function just doesn't return.
Also, I don't intend to maintain state preservation.
You do not explicitly but as you are trying to bind functions (attach
a scla function to a link, button etc) you need the proper context.
I just want to
create a list of a href tags for all files which when clicked should
make an Ajax call to a specific function in the LiftActor thread which
processes the selection. Could you suggest some alternative way I
could go about this with the current architecture(1 comet actor for
display and individual feature-specific LiftActors sending xhtml to
CometActor for rendering)??
Take Dave's advice. It is very good and leads to cleaner separation of
concern.
Thanks,
Soumik
On Feb 16, 1:16 pm, Marius marius.dan...@gmail.com wrote:
Well so you're using it from your own actor. I would not recommend
this due to state preservation. I mean S context is very likely lost
because your LiftActor is running on a different thread. What you need
is to pass the LiftSession instance to your LiftActor say using some
distinct message like:
case class Init(session: LiftSession)
then in your messageHandler
protected def messageHandler = {
case FileManagerMsg(someMsg) =
{
S.initIfNotInitted(session) {
var fileList = listFilesInDir(/Users/soumik/Movies/)
Log.info(OUTPUT: + fileList)
}
}
}
But I'm not sure from your code wht you do with the output of your
listFilesInDir since that never gets to be rendered.
I strongly recommend using CometActor whenever you want to render
something asynchronously. It does a lots of good things for you.
Br's,
Marius
On Feb 16, 9:33 am, soumik soum...@gmail.com wrote:
Hi Marius,
Thanks for your response. I'm sorry for mis-communicating my problem
earlier. As you pointed out the problem doesn't occur when the call to
the function is made from a CometActor.
In my case too, it was not a CometActor. Rather, it was the LiftActor.
(Sometime back we had different CometActors for different feature
threads, now we have 1 single CometActor which takes care of the
display and different LiftActor threads which do the feature related
stuff. Hence the confusion on my part).
Anyways, here's the relevant code:
-
object TheVideoPlayerThread extends LiftActor
{
val threadName = FileManager
def listFilesInDir(dirName:String): NodeSeq =
{
Log.info(Recursing for: + dirName)
val files = (new java.io.File(dirName)).listFiles
def showFile1() = AAA
li class=fileElem id=dir{dirName}/li
ul
{files.flatMap(f = {
if (f.isDirectory
[Lift] Re: Error processing SHtml functions withing nested NodeSeq/Scala code
I don't think the cause is in SHtml. I tried your code from a snippet
and from a Comet actor and there was no lock whatsoever. But I did use
lift 2.0-SNAPSHOT. can you try with 2.0-SNAPSHOT ?
Br's,
Marius
On 15 feb., 15:20, soumik soum...@gmail.com wrote:
Hi,
I'm using 1.1-SNAPSHOT lift release and am experiencing strange
behaviour when trying to output a NodeSeq formed from nested NodeSeq
Scala code.
To highlight the problem let me show you the code I'm trying to
execute:
---
def listFilesInDir(dirName:String): NodeSeq =
{
Log.info(Recursing for: + dirName)
val files = (new java.io.File(dirName)).listFiles
def playFile1() = AAA
li class=fileElem id=dir{dirName}/li
ul
{files.flatMap(f = {
if (f.isDirectory())
{
Log.info(Directory: + f.toString)
listFilesInDir(f.toString)
span/span
}
else
{
Log.info(Regular file: + f.getName)
li class=fileElem id=regfile
{SHtml.link(, () = playFile1,
Text(Something)) } /* Problem in this line */
/li
}
}
)}
/ul
---
I'm trying to render the output of the above function in a comet
actor. The problem i see is with the highlighted line of code. When
the execution reaches this line of code, it gets stuck; the function
doesn't return and i don't get a NodeSeq to render.
However, for some reason if I change the highlighted line of code to
say:
{f.getName}
I get the proper NodeSeq which lists all the files in the directory.
Seems to me that the SHtml class functions are encountering an error
scenario(frm which its unable to recover). I've tried a couple of
SHtml functions(a, text, link, submit etc.) all of them show the same
problem, but if I use some other scala code it executes properly.
Could anyone look into this and verify whether this is indeed a bug
with the SHtml functions?
Thanks,
Soumik
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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 Record
I hardly own the Record :) ... as I stated with other occasions I'm
not a fan of ORM either :) ( I'm also not a fan of annotated POJO crap
which claim purity but they are polluted with annotations. )
I didn't follow too closely the couch DB implementation so I don't
have a formed opinion on it. I guess we can debate all day if active
records are right or not ... it's in many respects a matter of taste.
If one switched from a RDBMS to Couch DB or viceversa they'll probably
have bigger problems then changing CouchRecord to DBRecord or
viceversa. Personally I don't see a too big impediment in active
record's approach and I don't see it as an invation of the domain
model.
class Person extends CouchRecord[Person] {
//..
}
class Animal extends CouchRecord[Animal] {
}
could be replaced (at least in theory) with a proxy trait
(pseudocode cause I'm lazy now ...)
trait MyDomainRecord[A} extends CouchRecord[A]
class Person extends MyDomainRecord[Person] {
//..
}
class Animal extends MyDomainRecord[Animal] {
}
... thus have the CouchDB invasion in a single place.
The author says something like The moment you define a domain
abstraction as being statically dependent on a persistence
implementation, you lose the ability to reuse it in other contexts..
I disagree completly. I can think of a couple of options:
Option 1
class Person extends CouchRecord[Person] with PersonView {
//..
}
in my UI layer I can have:
def render (person: PersonView): NodeSeq = ...
Option 2
def render (person: Person): NodeSeq = ...
Option 3 ... there has to be one or more
so I'm able to pass a CouchDB record to other layers without
explicitly passing the persistence store information. So I don't see
much loss ...
Br's,
Marius
On 15 feb., 17:28, Timothy Perrett timo...@getintheloop.eu wrote:
Sounds like a good plan Ross - have you any specific suggestions about how
best to untangle things?
Marius - your thoughts as the own of Record?
Cheers, Tim
On 15 Feb 2010, at 15:03, Ross Mellgren wrote:
FWIW, I agree mostly completely, and when I was writing the integration I
didn't like the fact that I couldn't make one model object usable for both
Couch and an RDBMS (for example). I guess it could be made to support more
than one if the persistence-specific stuff was untangled from
MetaRecord/Record subclasses and made into mixable traits?
-Ross
On Feb 15, 2010, at 4:34 AM, Timothy Perrett wrote:
Debasish just posted this:
http://debasishg.blogspot.com/2010/02/why-i-dont-like-activerecord-fo...
Interesting feedback especially regarding the current design of
Record...
Cheers, Tim
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
That is an option, thanks. On 14 feb., 04:45, Naftoli Gugenheim naftoli...@gmail.com wrote: May I suggest that instead of naming the tag 'css,' it be given a name that's more agnostic of the content it affects and more indicative of what it does? Technically this could be used for any type of resource. What about something like lift:uniqueurl path=url / Or something else? Thanks for contributing this! 2010/2/12 Marius marius.dan...@gmail.com On 12 feb., 21:31, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Fri, Feb 12, 2010 at 8:20 PM, Marius marius.dan...@gmail.com wrote: Jeppe probably we can combine the two proposals. Yes, that would be natural Perhaps something like: lift:css name=mycss.css, some_other.css. /classpath/baz.css / thus Lift could generate: link rel=stylesheet type=text/css href=compound_2434rfe34534.css? i784yrfiuhferfhweir57=_/ compound_2434rfe34534.css is a synthetic name that would contain the mycss.css, some_other.css. /classpath/baz.css concatenated. Same thing for JS. This content could potentially be compressed. One thing that I think will be important (at some point :-) is to do combining of individual tags. If a page is constructed from several snippets/widgets, each emitting different js files (think jQuery plugins) and css files, these need to be combined somehow. This means that each page will get it's own unique synthetic css/js file. This probably needs to be configurable in some way :-) Yeah that is a slightly different use-case that require more noodling. But would worth considering in the future. I can open a ticket and start looking into this. Awesome! I'll watch from the sideline! /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: New logging code
Overall it's looking pretty good, but why do we need both Logging and
Loggable ?
Br's,
Marius
On 14 feb., 15:40, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Hi,
I've added first shot at the new logging code:
http://github.com/dpp/liftweb/blob/e7ed6c6bc013aea768bfe34a6e4eca22d2...
I've tried to keep it as simple as possible, really just a Scala layer
on top of the SLF4J api.
Note that no backend (log4j or logback) configuration is included. This
has to go into lift-util to use runmode etc.
You can have your choice of a nested logger:
object MyObj extends Logging {
logger.info(nested Hello)
}
or direct access:
object MyObj extends Loggable {
info(direct Hello)
}
Thoughts?
Next step, when this has been committed, is to update Lift internals to
use the new code (as part of #310) and deprecate the old logging in util.
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
On 12 feb., 22:56, Alex Black a...@alexblack.ca wrote: If this was implemented, it should be a unique id once per CSS change, not once per application start. There is no proper API to see when file names are changed unless we poll. I prefer to have LiftRules function that by default takes a value generated at startup. User's can override it to generate the token more frequently depending on their use-case. E.g. we deploy to production every few weeks, and client browsers should be able to cache files that entire time until change them, regardless of reboots. But obviously a value once per application start is much easier. I think what this points out is that its the file's datetime that is the state that needs to be used here, and the existing mechanism of HTTP looks like the way to go. Perhaps I'll dig into it and try to understand why this is not working as one would expect. If you can dig deeper that would be useful. On Feb 12, 1:28 pm, Marius marius.dan...@gmail.com wrote: Oh yes I did and I hate it. Ironically I was about to propose a solution for this. instead of link rel=stylesheet type=text/css href=mycss.css/ do something like: lift:css name=mycss.css / this would render: link rel=stylesheet type=text/css href=mycss.css? i784yrfiuhferfhweir57=_/ the query string parameter would be generated at application start-up. If you update you css/js and restart the application the browser will refresh it. Potentially generating the random query string param could be a LiftRules function that by default generates a sequence once per application time. Thus you could potentially set your own function that reads this for a config file? Similarly lift:js name=myjs.js/ would do the same. Br's, Marius On 12 feb., 19:25, Alex Black a...@alexblack.ca wrote: I'm wondering if other people have encountered this issue, or if we're doing something wrong, or if there is a nice solution to this. Whenever we update our site, with new code and CSS and JS, any user who visits it gets OLD css and js files (from their browser cache) unless they force a refresh. This is a jarring experience, users's see the site with old CSS and old JS which is effectively broken. Any thoughts? If it helps, our site is athttp://snapsort.com. We're using Jetty, behind nginx. I notice that when the browser requests the CSS files, the server responds 304 not modified, so I figured if the CSS was modified (when we update) then the server would not respond 304 not modified :) - Alex -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
On 12 feb., 23:04, Alex Black a...@alexblack.ca wrote: Yes, that's how it should work if everything was configured correctly (which I think it wasn't for the OP) Heh, I'm the OP. I'll have to dig into why its not working as expected I guess. But what we were discussing (at least I was :-) was more that Lift should serve resources with an Expires date in the far future. That way the browser will only make a single request for a resource (as long as the file is cached). This works well for returning visitors. But of course an updated resource should be fetched, hence the unique filenames. There are some things I like about that solution, but the unique filenames just seems wrong. So I see that a far in the future expires works, but the reason you need the unique filenames is because it doesn't really work. The far in the future expires says you can cache this for a long time cause it won't change. The other option is say you can cache this for like the next hour but every time you fetch it, you can tell me when you last got it (conditional GET), and I won't send it to you if it hasn't changed (304 not modified). This results in more requests, but no need for unique filenames or anything, instead if the file changes then the server will serve it up to whoever needs it. It doesn't sound like today this solution is consistent on all major browsers. Can you confirm that it does? I used the query string solution in the past (like many others) and this works reasonably well. It is not a perfect solution but better then today. Besides if we want to adopt a different solution that would be pretty easy because this knowledge will be built in the snippet and the user code wont really change. Combining individual files will improve load times for first time visitors by reducing the number of requests. That sounds like a great idea.. would like the same thing for JS. Does the YUI compressor tool that lift uses with maven have this type of feature? I Thought I read that it did. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
On 13 feb., 18:44, Timothy Perrett timo...@getintheloop.eu wrote: Seems like this conversation is diverging somewhat. Can I suggest there are two things in play here, and they address different problems. 1. Stopping the caching of resource files for an application build; the proposed solution is an md5 of the file contents so that the value persists application restarts (or with whatever random string) calculating an md5 of a file would induce additional computation time and we'd need to maintain hashes for each resource file. The prototype that I have now is a function in LiftRules that by default returns a random value generated on startup. Applications that needs MD5 per file could calculate that and maintain them. 2. Consolidation of CSS files on a given page for performance firstly, and secondly for caching. Would there be times when people would not want the behaviour of 2? Im generally not a huge fan of things that mess with user code or could provide uneasy behaviour; im thinking specifically when people build there templates where CSS values are overridden by values loaded after initial value ad unless its munged together right, it might damage the expected behaviour (think blueprint)...? Can I suggest we solve the caching problem using the known hack of random strings, then deal with this proposal of resource consolidation? What I'm playing with is lift:css.combine res:css name=abc.css/ res:css name=def.css/ /lift:css.combine under the hood this would be a function that return a Stream Response that concatenates the streams of files in questions serving them sequentially in the corresponding order. So from Lift's perspective there is no additional computation involved comparing with current situation except we serve desired resources in one response. To sum up the random string is what I think we should start with. IMO it is a fairly good solution that can evolve in time towards something else. Cheers Tim On 13 Feb 2010, at 08:45, Marius wrote: On 12 feb., 23:04, Alex Black a...@alexblack.ca wrote: Yes, that's how it should work if everything was configured correctly (which I think it wasn't for the OP) Heh, I'm the OP. I'll have to dig into why its not working as expected I guess. But what we were discussing (at least I was :-) was more that Lift should serve resources with an Expires date in the far future. That way the browser will only make a single request for a resource (as long as the file is cached). This works well for returning visitors. But of course an updated resource should be fetched, hence the unique filenames. There are some things I like about that solution, but the unique filenames just seems wrong. So I see that a far in the future expires works, but the reason you need the unique filenames is because it doesn't really work. The far in the future expires says you can cache this for a long time cause it won't change. The other option is say you can cache this for like the next hour but every time you fetch it, you can tell me when you last got it (conditional GET), and I won't send it to you if it hasn't changed (304 not modified). This results in more requests, but no need for unique filenames or anything, instead if the file changes then the server will serve it up to whoever needs it. It doesn't sound like today this solution is consistent on all major browsers. Can you confirm that it does? I used the query string solution in the past (like many others) and this works reasonably well. It is not a perfect solution but better then today. Besides if we want to adopt a different solution that would be pretty easy because this knowledge will be built in the snippet and the user code wont really change. Combining individual files will improve load times for first time visitors by reducing the number of requests. That sounds like a great idea.. would like the same thing for JS. Does the YUI compressor tool that lift uses with maven have this type of feature? I Thought I read that it did. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: JsCmds disabled inputs do not submit information
I don't think right now that this is a Lift problem. Do you experience this on all browsers? If so can you put together a minimalistic app that reproduces the behavior and send it to us? Br's, Marius On 13 feb., 19:28, Strom strommo...@gmail.com wrote: It seems that when I disable form inputs and set their values via JsCmds.setValById, the values don't get submitted to Lift in the form. Has anyone else had this problem? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Simple JQueryUI call
Try this:
import JE._
import JqJE._
def openDialog:String = {
(JqId(dialogpopup) ~ JsFunc(dialog, open)).toJsCmd
}
or
def openDialog:String = {
(JqId(dialogpopup) new JsExp with JQueryRight {
def toJsCmd = dialog('open')
}).toJsCmd
}
Br's,
Marius
On 13 feb., 20:42, Richard richard.m.willi...@gmail.com wrote:
Can someone post an example of a very simple way to use JQuery UI to
open a dialog. I found this code online but it's not well documented
and I can't get it to work. I'm assuming that the scala code was in a
snippet and that the HTML was in a web page. I've also tried
implemententing as a View but no luck.
import net.liftweb.http.js.JE
import net.liftweb.http.js.jquery.JqJE
def openDialog:String = {
(JqJE.JqId(JE.Str(dialogpopup)) ~
JE.JsFunc(dialog)).cmd.toJsCmd
}
div id=dialogpopup title=Dialog Title/div
Please click a href= onclick={openDialog}here/a to open a new
window.
Thanks
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields
Excellent work Ross !
On Feb 12, 6:49 am, Ross Mellgren dri...@gmail.com wrote:
I just committed a change to lift-record in 2.0-SNAPSHOT that will possibly
(probably?) break your build if you use it.
This change makes it possible to have any record field be optional -- that
is, Box[MyType]. You use it like this:
object MyRecord extends Record[MyRecord] {
object myNormalField extends StringField(this, 100)
object myOptionalField extends StringField(this, 100) {
override def optional_? = true
override def defaultValueBox = Empty
override def defaultValue = nothin
}
}
val r: MyRecord
r.myNormalField.set(Hello) // as before the change
r.myOptionalField.setBox(Empty)
r.myNormalField.value == Hello // as before
r.myNormalField.valueBox == Full(Hello)
r.myOptionalField.valueBox == Empty
r.myOptionalField.value == nothin // because defaultValue was used to give
back something
As part of this change, the semantics for field errors has changed somewhat
-- hopefully, to be more consistent.
Previously if you tried to set a field and checkCanWrite_? returned false
then an internal flag valueCouldNotBeSet on the field will be raised which
makes that field generate a validation error when validate is called on the
record. In addition, some fields (but not all) would raise the same flag and
return Failure or Empty from setFromString or setFromAny upon being given an
invalid value.
With this change, all types of failure to set now result in the field value
becoming a Failure. setFromAny, setFromString, and setBox all return that
Failure, while set will return defaultValue (due to its return type.)
validators and set filters have had their types changed to Boxed equivalents.
And finally, I made consistent the setFromAny methods of all the built-in
field types so that they all follow the same contract. For setFromAny it's
essentially accept one of MyType, Box[MyType], Option[MyType], or
List[MyType] as well as null, with a default to convert an unknown input to
string and use setFromString. For setFromString, it is as before, except if
the field is optional_? and the empty string is passed in, that's treated as
Empty.
As I'll mention in another message, I also pushed lift-couchdb to master. I
ran the unit tests that I wrote for that, but that doesn't give me full
confidence that all the fields are entirely bug free. Similarly I did not
test the form generation. If anybody runs into any issues please let me know
and I'll fix it as soon as I can. And of course if it causes too much
breakage we can revert it back out.
-Ross
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
Oh yes I did and I hate it. Ironically I was about to propose a solution for this. instead of link rel=stylesheet type=text/css href=mycss.css/ do something like: lift:css name=mycss.css / this would render: link rel=stylesheet type=text/css href=mycss.css? i784yrfiuhferfhweir57=_/ the query string parameter would be generated at application start-up. If you update you css/js and restart the application the browser will refresh it. Potentially generating the random query string param could be a LiftRules function that by default generates a sequence once per application time. Thus you could potentially set your own function that reads this for a config file? Similarly lift:js name=myjs.js/ would do the same. Br's, Marius On 12 feb., 19:25, Alex Black a...@alexblack.ca wrote: I'm wondering if other people have encountered this issue, or if we're doing something wrong, or if there is a nice solution to this. Whenever we update our site, with new code and CSS and JS, any user who visits it gets OLD css and js files (from their browser cache) unless they force a refresh. This is a jarring experience, users's see the site with old CSS and old JS which is effectively broken. Any thoughts? If it helps, our site is athttp://snapsort.com. We're using Jetty, behind nginx. I notice that when the browser requests the CSS files, the server responds 304 not modified, so I figured if the CSS was modified (when we update) then the server would not respond 304 not modified :) - Alex -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
Tim please see my proposal above :) On 12 feb., 21:12, Timothy Perrett timo...@getintheloop.eu wrote: This is pretty much what rails does. Straight from github: link href=/stylesheets/bundle_common.css?7371c81fbc6b010a32fb11b42a0fc322c3c578 63 media=screen rel=stylesheet type=text/css / link href=/stylesheets/bundle_github.css?7371c81fbc6b010a32fb11b42a0fc322c3c578 63 media=screen rel=stylesheet type=text/css / It would be nice to provide some kind of generic helper snippet for this. Some hash that is configured on boot up would be great; provide some function in lift rules to alter the behaviour and away we go. Perhaps something like: lift:css href=/whatever.css / Thoughts? Cheers, Tim On 12 Feb 2010, at 18:53, Jeppe Nejsum Madsen wrote: On Fri, Feb 12, 2010 at 7:28 PM, Marius marius.dan...@gmail.com wrote: Oh yes I did and I hate it. Ironically I was about to propose a solution for this. instead of link rel=stylesheet type=text/css href=mycss.css/ do something like: lift:css name=mycss.css / this would render: link rel=stylesheet type=text/css href=mycss.css? i784yrfiuhferfhweir57=_/ the query string parameter would be generated at application start-up. If you update you css/js and restart the application the browser will refresh it. Potentially generating the random query string param could be a LiftRules function that by default generates a sequence once per application time. Thus you could potentially set your own function that reads this for a config file? Similarly lift:js name=myjs.js/ would do the same. I had similar thoughts sometime ago, but haven't looked at it since then: http://groups.google.com/group/liftweb/browse_thread/thread/1130ce4f9... For me, the real benefit would be combining many requests into one and setting a future Expires date but still be sure that all artifacts will be updated correctly. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
Jeppe probably we can combine the two proposals. Perhaps something like: lift:css name=mycss.css, some_other.css. /classpath/baz.css / thus Lift could generate: link rel=stylesheet type=text/css href=compound_2434rfe34534.css? i784yrfiuhferfhweir57=_/ compound_2434rfe34534.css is a synthetic name that would contain the mycss.css, some_other.css. /classpath/baz.css concatenated. Same thing for JS. This content could potentially be compressed. I can open a ticket and start looking into this. Br's, Marius On 12 feb., 20:53, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Fri, Feb 12, 2010 at 7:28 PM, Marius marius.dan...@gmail.com wrote: Oh yes I did and I hate it. Ironically I was about to propose a solution for this. instead of link rel=stylesheet type=text/css href=mycss.css/ do something like: lift:css name=mycss.css / this would render: link rel=stylesheet type=text/css href=mycss.css? i784yrfiuhferfhweir57=_/ the query string parameter would be generated at application start-up. If you update you css/js and restart the application the browser will refresh it. Potentially generating the random query string param could be a LiftRules function that by default generates a sequence once per application time. Thus you could potentially set your own function that reads this for a config file? Similarly lift:js name=myjs.js/ would do the same. I had similar thoughts sometime ago, but haven't looked at it since then: http://groups.google.com/group/liftweb/browse_thread/thread/1130ce4f9... For me, the real benefit would be combining many requests into one and setting a future Expires date but still be sure that all artifacts will be updated correctly. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
I opened http://www.assembla.com/spaces/liftweb/tickets/346-Solve-CSS-JS-unwanted-caching Br's, Marius On 12 feb., 21:20, Marius marius.dan...@gmail.com wrote: Jeppe probably we can combine the two proposals. Perhaps something like: lift:css name=mycss.css, some_other.css. /classpath/baz.css / thus Lift could generate: link rel=stylesheet type=text/css href=compound_2434rfe34534.css? i784yrfiuhferfhweir57=_/ compound_2434rfe34534.css is a synthetic name that would contain the mycss.css, some_other.css. /classpath/baz.css concatenated. Same thing for JS. This content could potentially be compressed. I can open a ticket and start looking into this. Br's, Marius On 12 feb., 20:53, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Fri, Feb 12, 2010 at 7:28 PM, Marius marius.dan...@gmail.com wrote: Oh yes I did and I hate it. Ironically I was about to propose a solution for this. instead of link rel=stylesheet type=text/css href=mycss.css/ do something like: lift:css name=mycss.css / this would render: link rel=stylesheet type=text/css href=mycss.css? i784yrfiuhferfhweir57=_/ the query string parameter would be generated at application start-up. If you update you css/js and restart the application the browser will refresh it. Potentially generating the random query string param could be a LiftRules function that by default generates a sequence once per application time. Thus you could potentially set your own function that reads this for a config file? Similarly lift:js name=myjs.js/ would do the same. I had similar thoughts sometime ago, but haven't looked at it since then: http://groups.google.com/group/liftweb/browse_thread/thread/1130ce4f9... For me, the real benefit would be combining many requests into one and setting a future Expires date but still be sure that all artifacts will be updated correctly. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Cached CSS (and Javascript?) issue
On 12 feb., 21:31, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Fri, Feb 12, 2010 at 8:20 PM, Marius marius.dan...@gmail.com wrote: Jeppe probably we can combine the two proposals. Yes, that would be natural Perhaps something like: lift:css name=mycss.css, some_other.css. /classpath/baz.css / thus Lift could generate: link rel=stylesheet type=text/css href=compound_2434rfe34534.css? i784yrfiuhferfhweir57=_/ compound_2434rfe34534.css is a synthetic name that would contain the mycss.css, some_other.css. /classpath/baz.css concatenated. Same thing for JS. This content could potentially be compressed. One thing that I think will be important (at some point :-) is to do combining of individual tags. If a page is constructed from several snippets/widgets, each emitting different js files (think jQuery plugins) and css files, these need to be combined somehow. This means that each page will get it's own unique synthetic css/js file. This probably needs to be configurable in some way :-) Yeah that is a slightly different use-case that require more noodling. But would worth considering in the future. I can open a ticket and start looking into this. Awesome! I'll watch from the sideline! /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Logging changes
Not sure about Jeppe but this sounds really good to me. Br's, Marius On Feb 12, 6:56 am, David Pollak feeder.of.the.be...@gmail.com wrote: Jeppe Co., I've been thinking about the logging changes. How about a different approach? How about a new logging system in common that takes the best of the existing logging system plus a bunch of enhancements? We can deprecate the stuff in util, but not phase it out for a while. What do you think? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 combine sequence of JsCmd in SHtml.ajaxCall?
(JsCmds.SetHtml(...)
JsCmds.SetElemById(...)
JE.JsRaw(alert('1'))
JE.JsRaw(alert('2'); alert('3'))).cmd
Br's,
Marius
On Feb 10, 10:22 am, wm min...@gmail.com wrote:
Hi,
I have the following code:
def jsF(x: String): JsCmd = {
/*
JsCmds.SetHtml(...)
JsCmds.SetElemById(...)
*/
JE.JsRaw(alert('1')).cmd
JE.JsRaw(alert('2'); alert('3')).cmd // last cmd
}
button onclick={SHtml.ajaxCall(Str(x), jsF _)._2}
/button
when I tried, only the last cmd got executed, I know this is because
it's the return value for the whole function jsF().
I'm wondering is it possible to make it execute a sequence of JsCmd?
e.g. as the code that have been commented out? how this can be done in
Lift (instead of writing raw JsRaw)?
Thanks!
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Netty integration
Nick did you happen to make some progress on this? Are you still working on it ? Br's, Marius On 27 ian., 14:54, nick n...@glynnreeves.plus.com wrote: I'm just about to try and do aNettyintegration, which I might be able to contribute back. Searching the group I deduce that this is possible but hasn't been done yet. Before I start I thought I'd just post to check that someone else isn't doing this already. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 javier Goday to the Lift committers
WELCOME ! On 9 feb., 18:09, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Please join me in welcoming Javier Goday to the Lift committers. Javier wrote the Lift LDAP module and now that he's a committer, he can make the LDAP module part of the official Lift distribution (and the crowd goes wild). Welcome Javier!! Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: HTTP Reason Phrase
I think it worth to add this support even if servlet API is a little weird sometimes but Lift HTTP API could provide a nicer support. Furthermore such Lift API support would be handy for non JEE containers therefore I'd vote for it. Erkky would you please open a defect (https://www.assembla.com/spaces/ liftweb/tickets) and assign it to me ? Br's, Marius On 8 feb., 21:08, David Pollak feeder.of.the.be...@gmail.com wrote: I think this issue rests with Marius. He's done most of the interface between Lift and the servlet containers. Let's see what he has to say. On Sun, Feb 7, 2010 at 2:47 PM, Erkki Lindpere vill...@gmail.com wrote: Ok. The feature is not really that important for me, just something that would be nice to have. I think some hack could be made with sendError(int, String) and web.xml config, but that would be worse than using the deprecated method. Erkki L On Feb 7, 11:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: I agree Ross... I would be very reluctant to have Lift rely on some deprecated method in the servlet spec - even if it is in servlet 3.0. Cheers, Tim On 7 Feb 2010, at 20:48, Ross Mellgren wrote: Yeah you're very correct. It's unfortunate, but I think since it's deprecated in the container we should probably not add support for it. I can't believe they deprecated it for the reason they did, but there it is. -Ross On Feb 7, 2010, at 8:16 AM, Erkki Lindpere wrote: Actually, the reason phrase is not a normal HTTP header, but part of the status line: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Examples: HTTP/1.1 200 OK HTTP/1.1 404 The user with id 8 does not exist The only way of setting this in Java Servlets as far as I know is through HttpServletResponse.setStatus(int, String), which unfortunately is deprecated. A non-deprecated possibility is sendError(int, String), but that goes to the container's default error page (or the one defined in web.xml, I think) so it's not exactly what I would like. Also, I checked that FireBug actually does display the custom reason phrase, but Chrome displays the standard one instead. Erkki L On Feb 7, 1:08 pm, Timothy Perrett timo...@getintheloop.eu wrote: If you want to alter the Reason-Phrase, you can already do that - objects like NotFoundResponse are just helpers on InMemoryResponse... nothing stopping you adding your own helpers that set headers with customised reason codes; this should give you what you what. I haven't managed to find an RFC that lists reason-phrase as anything but a particular header in the HTTP response. Moreover, its not the wrong thing to return a plain text response if the request mime was text/plain... indeed, it would be even less helpful if it returned JSON or such. IMHO, the response type should match what was asked for by the caller - i.e. its an implementation issue not a framework level issue. Tim On 6 Feb 2010, at 21:55, Erkki Lindpere wrote: The NotFoundResponse (and others) puts the custom message into the request body. That works as well, but to be really lean (mainly for bragging rights :)) I'd like to remove any unnecessary elements from the rest api. Most of the error messages are going to be simple one- line messages (and short sentences). For some errors I might provide a detailed response and it could go into the body, as XML/JSON/... That's inconsistent if the other errors have a plain text message in the body. So I could either go with structured details for all messages or in simple cases use the HTTP headers or status line. A custom header would work, but the status line is standard and also more easily accessed with some client libraries. And last but perhaps not least, for debugging purposes, the HTTP Reason Code should show up better in web developer tools (for example FireBug, Chrome's tools). My web UI also goes through the REST API so it would be nice to read error messages right in the listing in firebug's net panel. So I'm suggesting that perhaps Lift would like to provide only the possibility of changing that value in user code. But I completely understand if it doesn't. Currently it doesn't seem to be supported in Lift's http.provider package and even in javax.servlet the setStatus(int, String) method is deprecated (I'm not sure if sendError(int, String) uses the reason phrase). Erkki L On Feb 6, 9:59 pm, Ross Mellgren dri...@gmail.com wrote: I think it would be fine to have different text there, probably better than having the standard text if you have refined detail. I don't think it'd be a good idea to conditionalize on the response text in client code - that's always fragile. If you want to give additional machine
[Lift] Re: Forcing Authentication not working
Please open a defect here http://www.assembla.com/spaces/liftweb/tickets
Br's,
Marius
On Feb 7, 10:44 pm, aw anth...@whitford.com wrote:
OK, I think I found the source code that is the culprit. From
LiftServlet.scala:
http://github.com/dpp/liftweb/blob/master/framework/lift-base/lift-we...
private def authPassed_?(req: Req): Boolean = {
val checkRoles: (Role, List[Role]) = Boolean = {
case (resRole, roles) = (false /: roles)((l, r) = l ||
resRole.isChildOf(r.name))
}
val role = NamedPF.applyBox(req,
LiftRules.httpAuthProtectedResource.toList)
role.map(_ match {
case Full(r) =
LiftRules.authentication.verified_?(req) match {
case true = checkRoles(r, userRoles.get)
case _ = false
}
case _ = true
}) openOr true
}
This logic seems to be inconsistent with the documentation found in
LiftRules.scala:
http://github.com/dpp/liftweb/blob/master/framework/lift-base/lift-we...
/**
* Defines the resources that are protected by authentication and
authorization. If this function
* is notdefined for the input data, the resource is considered
unprotected ergo no authentication
* is performed. If this function is defined and returns a Full can,
it means that this resource
* is protected by authentication,and authenticated subjed must be
assigned to the role returned by
* this function or to a role that is child-of this role. If this
function returns Empty it means that
* this resource is protected by authentication but no authorization
is performed meaning that roles are
* not verified.
*/
val httpAuthProtectedResource =
RulesSeq[HttpAuthProtectedResourcePF]
Shouldn't there be something like:
case Empty =
LiftRules.authentication.verified_?(req)
?
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Error messages are not displayed - 2.0-M1
Are you using in your html page lift:msgs/ ?
Br's,
Marius
On Feb 6, 10:45 am, wibblecp wibbl...@gmail.com wrote:
Hi all,
I'm newbie with lifts and I am having a little problem. I am using
Lift2.0-M1.
I have a snippet that runs the rescue of a model. The method is called
when the submit the form
[code]
def validateAndSave (): Unit = currentEntry.validate match {
case Nil = currentEntry.save ; S.notice(currentEntry.title +
SAVED!)
case x = println(x) ; S.error(x);
}
[/code]
I am not able to view the error messages in the browser, but only in
the shell.
Instead of using S.error(x) I tried S.error(+x). Now when I submit a
form I see the error messages but the message looks like this:
[code]
List(Full(entries_code) : Description must not be empty,
Full(entries_title) : Title must not be empty;,
Full(entries_author_email) : Invalid email address)
[/code]
So, the message are not displayed as expected and I am not able to
understand the reason for S.error( + x) to read something.
Could anyone give me an advice?
Thanks for your helps.
Ragards,
w.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Error messages are not displayed - 2.0-M1
What Lift version are you using?
If you are using an Ajax form lift:msgs showAll=true/ did not show
the messages associated with ID's ... messages coming from FieldError.
This is a defect I fixed about a week ago. Please use the latest lift
build.
If you just want to render all messages (regardles if they are
associated with ID's or not) in one place lift:msgs showAll=true/
should be fine. But typically for field related message you could use
lift:msg id=field_id/ which would render only messages associated
with field_id id. As a side note lift:msgs/ only render messages
that are not associated with any ID.
Br's,
Marius
On Feb 6, 3:51 pm, wibblecp wibbl...@gmail.com wrote:
hi Adam,
thank you. It is exactly what I done
def validateAndSave (): Unit = currentEntry.validate match {
case Nil = currentEntry.save ; S.notice(currentEntry.title +
SAVED!)
case x = { x map { (e:FieldError) = S.error(e.msg) } }
}
have a nice day.
wibble
On Feb 6, 2:35 pm, Adam Warski a...@warski.org wrote:
Hello,
are you submitting the form with ajax?
If so, see this thread:
http://groups.google.com/group/liftweb/browse_thread/thread/e25d86a24...
In short, check if doing:
xs.map {i = S.error(i.msg) };
instead of:
S.error(xs);
works.
Hi Jeppe,
lift:Msgs showAll=true does not work. Always the same result.
If the form does not contain errors the data are saved well and the
browser display S.notice(saved) correctly.
The S.error method returns a List[FieldError]. I receive a List with
the format of List(Full(tablename_field) : message)
this is a field of my database class:
[code]
object description extends MappedTextarea(this, 255) {
override def displayName = Description
override def validations = valMinLen(1, S.??(description must
not be empty)) _ :: super.validations
}
[/code]
thanks,
wibble
On Feb 6, 12:19 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
wibblecp wibbl...@gmail.com writes:
it does not work even in the case of a single error on the form.
the result is always a List(Full(entries_code) : Description must not
be empty)
Try adding showAll:
lift:Msgs showAll=true
But default, Msgs doesnøt show field-level errors
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
Adam Warskihttp://www.warski.orghttp://www.softwaremill.eu
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: LiftRules inconsistencies (including FactoryMaker grump)
Yeah it is not clear to me why not just using function like: LiftRules.stripComments: () = Boolean Maybe I missed previous talks, or just not remember it it doesn't look that API simplified or became more intuitive by adding FactoryMakers ... Br's, Marius On Feb 5, 5:35 pm, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to have a grumpy moan about FactoryMaker. Now, this must easily be the most complicated / confusing piece of scala code in Lift. Its totally non-trivial implementation and its levels of miss- direction (and total lack of examples) make it an utter nightmare to figure out what one needs to do to use it for pre-assigned vals in LiftRules. This brings me neatly onto my next point: LiftRules and its occasional use of FactoryMaker, partial functions and mutable vars. I appreciate that this is partially a legacy thing as many different people within the team add stuff to LiftRules, however I thought FactoryMaker was brought in to facilitate object mocking / testing right? Shouldn't it be the first-order choice for configuration? weather or not that is the case, why oh why are there no explanations in the comments for LiftRules where factory maker is used as to how to alter those configuration options? For example: LiftRules.stripComments.default.set(() = false) This is totally non-obvious - if we are going to use stuff like this, it really out to be in the comments. Stuff like this can seriously affect Lift's ease of use, and considering the current lack of documentation we need to be careful about what we are doing here. Sorry for the grump, i just felt this was warranted. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: CometActor.fixedRender always below render?
Technically you could override : def toJavaScript(session: LiftSession, displayAll: Boolean): JsCmd from CometActor, but you'd probably loose important things that Lift does for you there. You could call super but I don't think that it would be very helpful. Perhaps we should add an easy way to allow this ... Br's, Marius On Feb 3, 5:15 pm, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, It looks like the output from fixedRender is always placed below the one from render. Is there a way to change this? Heiko -- Heiko Seeberger Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: liftAjax jQuery 1.4.1 problem
Hmmm ... in Lift we do use JSON structures with functions (but not
with JSON mime type). For instance ScriptRenderer.scala defines a JSON
with functions. jlift.js also defines a JSON with functions.
But looking at your example app, you're using JSON mimetype in the
response and that JSON has a function which I don't think it is
correct. So why do you need the jsonCall stuff with AjaxContext.json ?
Br's,
Marius
On 3 feb., 22:08, David Pollak feeder.of.the.be...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:55 AM, Jonathan Hoffman jonhoff...@gmail.comwrote:
I was able to find the root cause. jQuery 1.4.1 does not consider
javascript objects that contain functions to be be valid JSON.
According the to JSON spec, a function is not valid JSON.
This is ok: {foo:bar}
This is bad: {foo:function(){alert('hello')}
jquery-1.4.1.js:491 -- parseJSON
jquery 1.3.2 simply eval'd strings to created json objects, so there was no
problem. I think it's kind of nice to be able to return JSON objects via
ajax calls with embedded functions, but please feel free to educate me if
you think that's a bad idea.
I think it's a nifty trick, but I'm not sure it's optimal.
Is it a Lift thing or your app that's returning the function as part of the
JSON response?
I'll also try to get some feedback from the jQuery forum.
Thanks,
Jon
On Feb 3, 2010, at 2:21 PM, Jonathan Hoffman wrote:
Hi,
There is a problem with making jsonCalls which return JSON with anonymous
functions. I've created a very simple reproducible example, but have not
been able to track down the root cause.
Take a look at jsonCallBug in:
http://github.com/hoffrocket/lift_1_1_sample/blob/master/src/main/sca...
The project should run in mvn or sbt.
Thanks,
Jon
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Snippet attribute pass through
Replace your bind with:
bind (ledger, content, time -% span{(new
java.util.Date).toString}/span)
ledger:id is not anymore preserved as after the was out this was
considered a not intended feature and got moved. -% should do what
you want.
Br's,
Marius
On Feb 1, 5:57 pm, ced docpom...@googlemail.com wrote:
I want to set a node attribute in the template markup exactly like it
is done in example 7.13 from the Lift Book. I'll paste it here:
// the markup
lift:Ledger.balance ledger:time ledger:id=myId/
/lift:Ledger.balance
// The snippet class
class Ledger { def balance (content : NodeSeq ) : NodeSeq = {
bind (ledger, content, time - span{(new
java.util.Date).toString}/span)
}
}
Unfortunately I can't get it to work. Is there something I have to set/
enable to get this feature working? I'm using Lift 1.1-M8
Thanks,
Chris
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Snippet attribute pass through
Well the book reflects Lift at that point in time. Since then there
were quite a few updates. I know Derek at some point tried to keep it
up to date but I'm not sure now.
This is not about fixing the book.
Br's,
Marius
On 1 feb., 18:39, Naftoli Gugenheim naftoli...@gmail.com wrote:
Anyone want to fix the book? :)
Anyway, once you're using -% you want it to be id, not ledger:id.
-
Mariusmarius.dan...@gmail.com wrote:
I'm eating letters as after the was out should be as after the the
book was out :D
On Feb 1, 6:03 pm, Marius marius.dan...@gmail.com wrote:
Replace your bind with:
bind (ledger, content, time -% span{(new
java.util.Date).toString}/span)
ledger:id is not anymore preserved as after the was out this was
considered a not intended feature and got moved. -% should do what
you want.
Br's,
Marius
On Feb 1, 5:57 pm, ced docpom...@googlemail.com wrote:
I want to set a node attribute in the template markup exactly like it
is done in example 7.13 from the Lift Book. I'll paste it here:
// the markup
lift:Ledger.balance ledger:time ledger:id=myId/
/lift:Ledger.balance
// The snippet class
class Ledger { def balance (content : NodeSeq ) : NodeSeq = {
bind (ledger, content, time - span{(new
java.util.Date).toString}/span)
}
}
Unfortunately I can't get it to work. Is there something I have to set/
enable to get this feature working? I'm using Lift 1.1-M8
Thanks,
Chris
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Question on Javascript calls
Yes Lift's JavaScript stuff is mostly used when returning Ajax response. You can also use it to serve fictive *.js files and instead of returning a js file content you can serve the request (using LiftRules.dispatch) and the actual JS returns is produced by composition of JsCmd-s. We actually do that when serving the primordial lift-ajax/comet script. You can also use them for js events just to do some client stuff without invoking ajax. This is pretty handy as where you compute your button content from a snippet you can easily attach JS behavior as well. Br's, Marius On Feb 1, 2:27 am, pere.vill...@gmail.com araco...@gmail.com wrote: HI all, first of all, I should present myself, as it's my first post in the group: I'm Pere Villega, a Java developer living in Dublin and learning Scala and Lift in my spare time. As a good newbie, I'll start with an obvious question: I've been reading the Lift book, and I got confused on the javascript section. It seems Lift allows you to create javascript code on the server side, but as far as I understand this code is only to be used when reacting to events that go to the server? Or I'm mistaken? So, to say it in another way, if I have a page that has javascript, the lift way is to keep in the template all the javascript that modifies the UI (like a button that hides a div but doesn't send any data to the server) and keep on the snippets the code that will eventually relate to calls to the server (like an onclick validation on submit or an ajax call). Is that correct? I know it might seem obvious, but I would hate to start doing it that way and then discover I could have saved effort using the lift calls... :) Best regards, Pere Villega -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 there way to set multipart in ajaxform?
I don't think it's possible to do files upload via Ajax. There are
workarounds but not directly with Ajax. If it would be possible Lift
would have expose it already. Please look into widgets project on the
upload widget. It does a fiel upload ajax-like including progress bar.
Br's,
Marius
On Jan 28, 8:05 am, wm min...@gmail.com wrote:
Hi,
I want to upload files in AJAX, is there a way to set the
multipart=true?
I checked the html code generated by the ajaxForm:
form id=F347910659087FDI
action=javascript://
onsubmit=liftAjax.lift_ajaxHandler(jQuery
('#'+quot;F347910659087FDIquot;).serialize(), null, null,
quot;javascriptquot;);return false;
input type=file name=F347910659080N24 /
...
There is no such option.
Then I checked in:
framework/lift-base/lift-webkit/src/main/scala/net/liftweb/http/
SHtml.scala
it seems none of the
def ajaxForm(...)
takes such parameter?
Is what I'm looking for possible at all? thanks.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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 logging improvements
+1 On Jan 27, 11:59 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, I was thinking about some improvements to Lift's logging code: 1) Make the slf4j logging configurable in the same way as log4j (ie with dev, prod logback files) 2) Add support for MDC to Lift's logging interface (and the log4j slf4j backends) 3) Add more logging to Lift :-) The last part may be a bit controversial, but I find logging statements immensely useful when trying to diagnose stuff that doesn't work or figure out how stuff works. If separate loggers are created for different areas (i.e mapper, comet, ajax, etc) it should be possible to turn the needed info on off without too much information overload. Performance wise it shouldn't matter much (famous last words :-) if logging is disabled. Thoughts? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Exception notification?
See LiftRules.exceptionHandler On Jan 29, 12:33 am, Yu-Shan Fung ambivale...@gmail.com wrote: Hi All, A bit of a shot in the dark, but is there an easy way to setup email notification on an lift app whenever an uncaught exception occurs? Seems like a common enough use-case, just wonder if there's a standard way to do it before I roll my own. Thanks! Yu-Shan. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: jQuery 1.4
This broke my app ... with flying colors :D But it's not really Lift or jquery's fault. I'm using jstree plugin http://www.jstree.com/ and it doesn't seem to work properly with jquery 1.4. No biggies as I reverted to jquery 1.3.2. but others may hit this as well. Br's, Marius On Jan 26, 9:03 pm, Jonathan Hoffman jonhoff...@gmail.com wrote: Hi, Has anyone done extensive lift testing withjQuery1.4.1? My very brief test seems to indicate that things still work as expected, but I'm not doing anything with comet. http://jquery14.com/day-01/jquery-14 Should lift 2.0 upgrade? - Jon -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Netty integration
I'd strongly encourage you to do it. I was planning to work on it but I never seem to find slots for it :( If you run into some problems especially related with provider API please let me know. Br's, Marius On Jan 27, 2:54 pm, nick n...@glynnreeves.plus.com wrote: I'm just about to try and do a Netty integration, which I might be able to contribute back. Searching the group I deduce that this is possible but hasn't been done yet. Before I start I thought I'd just post to check that someone else isn't doing this already. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: jQuery 1.4
Thanks Jon. On Jan 27, 5:19 pm, Jonathan Hoffman jonhoff...@gmail.com wrote: Hi Indrajit, I think you're right. I didn't notice at first, but there are documented breaking changes in jQuery 1.4 which are outlined here:http://jquery14.com/day-01/jquery-14#backwards Marius, there's also a backward compatibility plugin(see above link) that might address the jstree issues if you do want to use 1.4.1 - Jon On Jan 27, 2010, at 8:18 AM, Indrajit Raychaudhuri wrote: Hmm, I think this jQuery update should be sent as a separate announcement. As this change that can create create ripple in an application and qualifies as a 'potentially' breaking change. Cheers, Indrajit On 27/01/10 6:16 PM, Marius wrote: This broke my app ... with flying colors :D But it's not really Lift or jquery's fault. I'm using jstree plugin http://www.jstree.com/and it doesn't seem to work properly with jquery 1.4. No biggies as I reverted to jquery 1.3.2. but others may hit this as well. Br's, Marius On Jan 26, 9:03 pm, Jonathan Hoffmanjonhoff...@gmail.com wrote: Hi, Has anyone done extensive lift testing withjQuery1.4.1? My very brief test seems to indicate that things still work as expected, but I'm not doing anything with comet. http://jquery14.com/day-01/jquery-14 Should lift 2.0 upgrade? - Jon -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: New ticketing system
I wholeheartedly agree. I'd also wish we could use Derek's stuff but I heaven't heard of it in a while and I know Derek currently has some other stuff to do. I'm not sure if someone else took it over but no news yet. So unless someone has really good news about Derek's stuff Asssmbla sounds pretty good. So you got my vote. Br's, Marius On Jan 26, 7:46 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, We switched to GitHub's ticketing system a bunch of months ago and, well, it's not making the grade. It's slow. It's limited (no unclosing tickets, no attachments, weak discussion capaibilities). It doesn't allow easy planning/prioritization. I'd like to switch to something more powerful. Derek was working on LiftTicket. I'd like to use that, but don't know the state of the project. Alternatively, we could use Assembla's ticketing system. Does anyone have thoughts/input on the issue? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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 Jeppe to the Lift committers
Welcome Jeppe ! On Jan 25, 9:26 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Fri, Jan 22, 2010 at 5:25 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Please join me in welcoming Jeppe as a Lift Committer. He's been helping people on the Lift list and contributing his thoughts to the Lift community for a while... now it's time for him to contribute code to Lift. Hooorraaayyy! Thanks. It has been a great pleasure working with the Lift community for the past months. You rock! Hopefully, I'll be able to give something back now :-) Initially, I'll have a look athttp://github.com/dpp/liftweb/issues#issue/155since it will shave a few lines off my project. Afterwards, I need (in my dayjob) better form handling, so I'll probably see if there's a way to unify the Mapper/Record/Wizard/* stuff into something a little more composable. Another Idea I've been thinking about (mostly because it could be fun) is better handling of semi static resources (mostly css javascript) in order to minimize the number of requests while still getting the latest version /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: FIXME comet type Full(xxx) name Full(yyy) timeout
For some reason your comet does not respond in about 26 seconds with a rendering message (AnswerRender) and this is when the Comet snippet wants to render out stuff. Can you send a minimalistic app where you can reproduce this so we can try it ? Br's, Marius On Jan 26, 8:57 am, aw anth...@whitford.com wrote: Mega weird! Randomly I seem to be running into a problem with my Comet code. My xhtml doesn't render properly, and if I view source I see this: !--FIXME comet type Full(JournalClient) name Full(Other) timeout-- Uhm... What does this mean? What exactly is timing out? Any idea why it would be random? (Note that if I wait a few minutes, the page works fine. (No code changes!) This kind of stability (or lack thereof) is not going to win me points...) Help please! -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Can sessions do this?
On Jan 24, 9:29 pm, Nolan Darilek no...@thewordnerd.info wrote:
On 01/23/2010 11:32 AM, Marius wrote:
Well that just the standard session behavior but if you want
JSESSIONID in the URL yu should probbaly turn off cookies in Jetty (or
whatever container you have). Thus the URL's from the page would
be something like:
http://my.app;JSESSIONID=sdiofcxm?{params here}
That'd be perfect, and is one aspect of the whole user token thing. Is
it possible to disable this on an app-by-app basis? Can I put something
in Boot.scala or web.xml to disable cookie-based sessions just for this
app?
In Jetty 6 put in your WEB-INF/jetty-web.xml
Configure class=org.mortbay.jetty.webapp.WebAppContext
Get name=sessionHandler
Get name=sessionManager
Set name=usingCookies type=booleanfalse/Set
/Get
/Get
/Configure
LiftSession has by default an inactivity period of 30 minutes. However
you can configure the sessions expiration interval from /WEB-INF/
web.xml
And again, this is perfect. This is why I'm trying to (ab)use sessions
in this manner, they already encapsulate most of the behaviors I need,
and the less code I have to write myself, the better.
Rrgarding your initial 3 points:
1. Visiting the app without a session ID param shouldn't generate a
new
session. Basically, index.html will just be mostly static, providing
info on the service itself.
/*marius - It does by default. A request without a sessionid will
create a HTTP session*/
Right, I get this. So my question is, can I stipulate that visitors to
/index.html *don't* generate a session?
Not really. An HTTP session is always created by Lift when processing
stateful requests. But this not affect you. You could *mark* xmpp
session (or sessions that you're interested in ) with some SessionVar
or set some session property that you could set. But again a HTTP
session is not necessarily bound to an account.
The default index page is just a
blurb about the service. To create an account, the user has to poke it
via XMPP, and if the user doesn't do this then there's no sense creating
a session for them.
When this XMPP request is sent you can create some state into a
SessionVar. Otherwise the HTTP session will simply be an HTTP session
inside the container (and SessionMaster) ... and there is no harm in
that.
2. If the config command is sent via XMPP, the bot should first
search
all sessions for any matching the user's JID, destroying one if it
exists. It should then create another, passing the user back a URL to
the app with a jsessionid parameter. So I need to somehow associate
arbitrary properties with sessions and find one based on those. Note
that the sessions still need to be addressable via unique strings to
maintain some level of security.
/*marius - If you need to know the list of active Lift sessions you
can use SessionMaster.sessionWatchers. Lift would send your actor a
SessionWatcherInfo message containing a Map[String, LiftSession]
You can put properties on a session most recommendable using Lift's
SessionVar.
*/
And I can set and access these properties from outside of snippets or
the HTTP lifecycle?
Yes, for SessionVar's yes but you'd need to be in the right context.
For instance:
1. If you're inside a Comet actor you just use SessionVar
2. If you're somewhere outside the request lifecycle you'd need to do
something like:
S.initIfUninitted(session) {
/// do your stuff here
}
but you'd need to obtain the LiftSession reference somehow.
Here's pseudocode that may help illustrate some of what I'm trying to
accomplish. Note that I'm totally making up Lift APIs here just to get
the concepts across. This would be code that matches incoming XMPP
messages to commands, so this is not running in the web app itself:
message.getBody match {
...
case config =
val old = SessionPool.find(owner, message.getFrom) // Does user
have a session already?
if(old != None) old.get.destroy // User requests new session so
invalidate old to prevent hijack.
val session = session.new
You shouldn't be creating sessions manually. Session are *created* by
container and when this happens LiftSessions are also created
automatically.
session.setSessionVar(owner, new SessionVar(message.getFrom))
message.reply(Please visit ,session.getURL, to configure your
account.)
...
}
I'm studying LiftSession.scala and see SessionMaster.getSession. Can I
set otherId to the JID of the session's owner? So I could replace
SessionPool.find in the above code with:
SessionMaster.getSession(, Some(message.getFrom))
or am I misunderstanding?
or SessionMaster.getSession(message.getFrom, Empty) this will give you
the session by a known ID.
I'm also not clear on how to create a blank session so I have a URL to
hand back to the user. I know that this is normally done by the incoming
HTTP request, but in this instance I
