[Lift] Re: Serious widget action

[Marius]

Please see here
http://groups.google.com/group/liftweb/browse_thread/thread/5e4f5e424d33db40/32cfb6752954?lnk=gst&q=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  wrote:
> On Tue, Mar 9, 2010 at 8:45 PM, aw  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: London Lift talk

[Marius]

Really nice talk Richard. Great stuff !!!

On Mar 9, 9:05 pm, Richard Dallaway  wrote:
> On Sat, Feb 20, 2010 at 8:22 PM, andy  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: How to use lazy-load?

[Marius]

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  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  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  wrote:
>
> > > On Mon, Mar 8, 2010 at 5:42 PM, Marius  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 & ? ****

[Marius]

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"  wrote:
>  I want get the these strings (http://test.com/file.zip&12345678)
> from the
>  URL (http://localhost:8080/download.html?link=http://test.com/
> file.zip&12345678)
>
>  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?

[Marius]

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  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  wrote:
>
>
>
> > On Mon, Mar 8, 2010 at 5:42 PM, Marius  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 & ? ****

[Marius]

You need to do URL encoding first. Helpers.urlEcnode(str) does this.

On Mar 9, 3:47 pm, "Neil.Lv"  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.zip&123...
>
>   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

[Marius]

On Mar 9, 1:08 pm, Timothy Perrett  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  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  wrote:
> >> On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett  
> >>  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?

[Marius]

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  wrote:
> On Mon, Mar 8, 2010 at 5:42 PM, Marius  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: RequestVar copy /clone ?

[Marius]

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  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: More dynamic Lift

[Marius]

I'm having seconds thoughts about this. Development mode can mean
slightly different things depending on the nature of the application.
The things you enlisted are for me only PROS for not including this
feature.

Sorry but personally I don't see much value in this approach ... but
this doesn't mean other people wont. Yes JavaRebel is not perfect but
it does its job quite good and it is really helpful in most cases.

On Mar 9, 2:51 am, David Pollak  wrote:
> Folks,
>
> I spent today "cracking the code" on how to implement a more dynamic Lift
> development cycle.  Specifically, I figured out how to support (during
> development mode) having changes in compiled code reflected in the running
> application.  The change to your Lift app will be a change in how you do
> things in Boot.scala.  Basically, anything that could change between page
> loads will be wrapped as such in Boot:
>
> LiftRules.dynamicDevelopmentMode(List("com.liftcode.model",
> "com.liftcode.lib"))(() => {
>   LiftRules.dispatch.append {...}
>
>   LiftRules.setSiteMap()
>
> })
>
> The list is a list of packages to exclude from the dynamic reloading.
> Because schemification isn't going to happen on every page reload, it's best
> not to reload the models.
>
> The dynamic mode will impose the following limitations:
>
>    - Lift will only service one request at once in development mode
>    - Page loads in development mode will be 10x-50x slower than in
>    non-development mode
>    - Comet objects will not change once they've been instantiated
>    - There will cases where classes created in one classloader are not
>    recognized as the same class for casting and/or pattern matching purposes 
> if
>    the classes are created across calls
>    - There may be problems related to running out of PermGen space because
>    each page reload will cause all the applications classes to be reloaded...
>    and this may happen faster than the classes are GCed.
>
> With those limitations, do you guys thing the feature would be valuable?
> Should it be part of development mode or should there be another demarcation
> of the dynamic reload mode?
>
> 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: 2.0-M3 & JQuery 1.4

[Marius]

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.
 *
 * 
 * <lift:with-resource-id>
 *   <link ... />
 *   <script ... />
 * </lift:with-resource-id>
 * 
 */


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  wrote:
> I am interested in this too but I don't understand the
>  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 , 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] Re: How to use lazy-load?

[Marius]

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  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:
>
> 
>   Udvikling per måned
>   
>   
>     
>       Vis:
>       
>       Opdel efter:
>       
>     
>     
>       
>       
>     
>   
>   
> 
>
> 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: Javascript Dependencies

[Marius]

On Mar 8, 11:02 am, Peter Robinett  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:
> 
>   
>     
>     
>     
>    // you got the idea
>   
>   // specific tags
> 
>
> 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 =
>   
>     
>     
>     
>   
>
> 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  wrote:
>
>
>
> > On Mar 6, 9:14 pm, Peter Robinett  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:
>
> > 
> >   
> >     
> >    // you got the idea
> >   
> >   // specific tags
> > 
>
> > 
> >   
> >     
> >    /// you got the ides
> >   
> >   ...
> > 
>
> > 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
> > goodie

[Lift] Re: Js normalizations

[Marius]

You must be unique :)

On Mar 7, 10:21 pm, Naftoli Gugenheim  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.
>
> -----
>
> Marius 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  wrote:
>
>
>
>
>
> > Can it be changed with a deprecation phase?
>
> > -
>
> > Marius 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  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: Js normalizations

[Marius]

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  wrote:
> Can it be changed with a deprecation phase?
>
> -----
>
> Marius 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  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

[Marius]

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  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] Js normalizations

[Marius]

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: Problem with FocusOnLoad and passing attributes through bind

[Marius]

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  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();
  });



On 6 mar., 23:56, Luke  Nezda  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  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  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  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  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  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 dispatc

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

[Marius]

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

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

[Marius]

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

[Lift] Re: Javascript Dependencies

[Marius]

On Mar 6, 9:14 pm, Peter Robinett  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:



  

   // you got the idea
  
  // specific tags




  

   /// you got the ides
  
  ...



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
 with  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  wrote:
>
>
>
> > Marius  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: superficial first impressions from a rails junkie

[Marius]

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

[Lift] Re: Problem with FocusOnLoad and passing attributes through bind

[Marius]

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  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  wrote:
>
>
>
> > On 22 feb., 04:12, Luke  Nezda  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) = some 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:
>
> > > 
> > >   
> > >       
> > >       
> > >       
> > >       
> > >   
> > > 
>
> > > 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 
> > > (Option[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindParam 
> > > (net.liftweb.common.Box[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindPa
> > >  ram
> > >  (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 howev

[Lift] Re: 2.0-M3 & JQuery 1.4

[Marius]

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



// put your script tags here




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  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: superficial first impressions from a rails junkie

[Marius]

On 6 mar., 06:43, cageface  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._

[Lift] Re: superficial first impressions from a rails junkie

[Marius]

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  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: Problem with FocusOnLoad and passing attributes through bind

[Marius]

On 22 feb., 04:12, Luke  Nezda  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) = some 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:
>
> 
>   
>       
>       
>       
>       
>   
> 
>
> 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 
> (Option[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindParam 
> (net.liftweb.common.Box[scala.xml.Elem])net.liftweb.util.Helpers.FuncBindPa 
> ram
>  (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 () 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: Wow... Lift has some amazing stats

[Marius]

I'm sooo proud being a little part of it ;)

On 5 mar., 19:46, David Pollak  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
> developerscontributed new
> code to
>  Lift .
>
> 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  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: Customizing generated form elements without touching scala code

[Marius]

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



   



On Mar 5, 2:07 pm, Julian Backes  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 . 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: File Download

[Marius]

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  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  wrote:
>
>
>
> > Thanks Tim, that's exactly what I'm looking for!
>
> > On Feb 14, 11:27 am, Timothy Perrett  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)

[Marius]

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  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  wrote:
>
>
>
> > On 03/03/10 10:21 PM, Jeppe Nejsum Madsen wrote:
>
> > > Indrajit Raychaudhuri  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

[Marius]

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  wrote:
> Marius  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: Javascript Dependencies

[Marius]

On Mar 1, 1:50 pm, Jeppe Nejsum Madsen  wrote:
> Marius  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

[Marius]

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  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  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  wrote:
>
> > > Peter Robinett  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 = {
> > > >    
> > > >            { myJsScript.toHTML }
> > > >    
> > > >    
> > > >            The rest of the snippet...
> > > >    
> > > > }
>
> > > > // 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: How do I add sitemap.xml and robots.txt

[Marius]

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(
  
  
  
  
  
  )
}

 LiftRules.dispatch.prepend(dispatcher);

On Feb 28, 3:03 am, Bob Folkerts  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

[Marius]

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  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: How to execute JsCmd after submit

[Marius]

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  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:
>
> 
>   
>     
>       
>         
>                 
>                                     Age:  type="text"/>
>                                     Male:  type="text"/>
>                                      value="calculate"/>
>                             
>         
>         
>           
>           Life Expectancy: 50
>           
>         
>       
>     
>   
> 
>
> 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: Reasoning Behind Box

[Marius]

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  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 
> wrote:
>
>
>
> > On 26 February 2010 08:09, Naftoli Gugenheim  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: Direct access to response.outputStream?

[Marius]

On Feb 26, 3:05 pm, Jeppe Nejsum Madsen  wrote:
> On Fri, Feb 26, 2010 at 1:53 PM, Marius  wrote:
>
> > On Feb 26, 1:29 pm, Jeppe Nejsum Madsen  wrote:
> >> On Fri, Feb 26, 2010 at 12:06 PM, Jeppe Nejsum Madsen  
> >> 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.
>
> Agreed, a cleaner solution. And this could also be used outside of a
> stateful response.

Sure it can be stateless since at the end of the day it is just a
LiftResponse.

> The size should probably be Box[Long] as it may be
> unknown.
>
> Should I create a ticket for this?

Sure, but I'm not sure who/when will take care of this. We'll see.

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

[Marius]

On Feb 26, 1:29 pm, Jeppe Nejsum Madsen  wrote:
> On Fri, Feb 26, 2010 at 12:06 PM, Jeppe Nejsum Madsen  
> 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: Direct access to response.outputStream?

[Marius]

On Feb 26, 11:50 am, Jeppe Nejsum Madsen  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: The role of LiftRules

[Marius]

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  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: Logging, part 2

[Marius]

Why not? LiftRules is about configuring a lift app at startup.

On 25 feb., 16:56, Naftoli Gugenheim  wrote:
> Why should an initLogger method be in LiftRules?
>
> -
>
> Marius wrote:
>
> Then perhaps:
>
> LiftRules.initLogger(Log4J)
>
> On Feb 25, 12:16 pm, Jeppe Nejsum Madsen  wrote:
>
> > On Thu, Feb 25, 2010 at 10:32 AM, Marius  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] Re: bind(): suppress automatic attribute mixin

[Marius]

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  wrote:
> val xml = 
>
> with
>
> val processed = bind("t",xml, "node" -> )
>
> becomes
>
> 
>
> 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: Advice for maintaining application state

[Marius]

Why "SessionVars are almost always a bad idea IMHO" ?

On Feb 24, 9:54 pm, tiro  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: Logging, part 2

[Marius]

Then perhaps:

LiftRules.initLogger(Log4J)



On Feb 25, 12:16 pm, Jeppe Nejsum Madsen  wrote:
> On Thu, Feb 25, 2010 at 10:32 AM, Marius  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: Logging, part 2

[Marius]

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  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] *Minor breaking change* - issue #363

[Marius]

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] This is the style of SQL persistence that I like ...

[Marius]

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] Re: LiftRules.jQueryVersion ... :(

[Marius]

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  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  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  wrote:
> > >> (yeah forgive me :) ...)
>
> > >> On Feb 23, 10:18 am, Jeppe Nejsum Madsen  wrote:
>
> > >>> +1 (and we might as well add 1.4.2 as well/instead :-)
>
> > >>> On Tue, Feb 23, 2010 at 9:11 AM, Marius  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

[Marius]

On Feb 22, 8:12 pm, Jeppe Nejsum Madsen  wrote:
> On Sun, Feb 21, 2010 at 9:49 AM, Marius  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 ... :(

[Marius]

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  wrote:
> (yeah forgive me :) ...)
>
> On Feb 23, 10:18 am, Jeppe Nejsum Madsen  wrote:
>
>
>
> > +1 (and we might as well add 1.4.2 as well/instead :-)
>
> > On Tue, Feb 23, 2010 at 9:11 AM, Marius  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 ... :(

[Marius]

(yeah forgive me :) ...)

On Feb 23, 10:18 am, Jeppe Nejsum Madsen  wrote:
> +1 (and we might as well add 1.4.2 as well/instead :-)
>
>
>
> On Tue, Feb 23, 2010 at 9:11 AM, Marius  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] LiftRules.jQueryVersion ... :(

[Marius]

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: Cached CSS (and Javascript?) issue

[Marius]

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: First comet steps

[Marius]

On 21 feb., 03:18, Nolan Darilek  wrote:
> I wrote my first comet actor today. Pretty neat stuff, and it was less
> difficult and painful than I expected. :) I'm having a bit of an issue
> figuring out how to render exactly what I want, though.
>
> My comet actor tracks a series of data imports, and since the import
> statuses change pretty rapidly, it makes more sense to poll at regular
> intervals and redraw the entire table of imports or perhaps the
> individual row than it does to do something more complex--at least for
> now. What I want to do, though, is display the table but only if there
> are imports active. If there are none, just display a paragraph stating
> that none are currently in progress.
>
> My issue is that since import statuses are displayed in a table, and
> since there may be two or three, I seem to either be able to display an
> empty table or nothing at all. Here's my template:
>
> 
> 
> 
> NameCompleteTotalStatus
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


try this:

 

  
 
 
 NameCompleteTotalStatus
 
 
 
 
 
 
 
 

  

  
Some content here
  


 

In your comet you have:

def defaultPrefix: Box[String] = Full()

def render = {

  val table  = Helpers.template(defaultXml, "pre", "table") openOr
NodeSeq.Empty
  val noContent = Helpers.template(defaultXml, "pre", "nocontent")
openOr NodeSeq.Empty


  //Choose here which one you want to render. Also on these
fragments,  you can further apply bind.
}


>
> If I try putting the table into another template and having
> ImportMonitor return , I seem to get nothing. If I move the
>  into the , I get an entire table for each individual
> import.

from your Comet actor  render method you could probably return
 and achieve a similar effect as I exemplified.

>
> The only thing that occurs to me is to define the  in the code of
> my render method. Is this my only option? Or am I missing something obvious?

No, see above.

>
> Also, how are comet actors timed out? I notice that if I kill the
> Firefox tab, I still get my printlns from the actor on my console, and I
> don't see the debugging code around my unsubscription mechanism
> triggered. Should I be doing something else to get localShutdown
> triggering, or does that happen when the sessions are cleaned up?

Yes when the session terminates. Or you could send a ShutDown message
to your actor. You can also implement
lifeSpan method in your CometActor. It will define for how long your
comet actor will live.

> If
> shutdown methods are only run on session expiration, is there any other
> way to tell a master publishing actor that it doesn't have to do any
> work on the behalf of a listener that no longer pays attention?
>
> 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: London Lift talk

[Marius]

excellent !


On 21 feb., 00:03, "Okpala Ikenna N." 
wrote:
> Hi Marius,
>
> Yes skills matter are hosting the event and provide video recording
> services, the video is made available two days after the event.
>
> i would iadvice that you watch this
> space<http://skillsmatter.com/podcast/java-jee/lift-getting-started-with-sc...>
>
> Cheers,
>
> Okpala Ikenna N. Jr.
>
>
>
> On Sat, Feb 20, 2010 at 9:49 PM, Marius  wrote:
> > Neat ! ... will there be any video ?
>
> > Br's,
> > Marius
>
> > On 20 feb., 22:22, andy  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.

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

[Marius]

I think you need to URL encode it.

On 21 feb., 04:33, wm  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: London Lift talk

[Marius]

Neat ! ... will there be any video ?

Br's,
Marius

On 20 feb., 22:22, andy  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: Has anyone gotten the uservoice javascript to work?

[Marius]

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  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:
>
> 
> 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 ?
> "<a  rel="nofollow" href="https://"">https://"</a>; : "<a  rel="nofollow" href="http://"">http://"</a>;) +
> "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(); };
> 
>
> You add it at the end of the page, near the  tag.  I put tthe
> //
>
> 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: Comet issue for Lift-2.0-scala280-SNAPSHOT

[Marius]

Yeah AFAIK Scala 2.8 integration is not 100% done and fully tested.

Br's,
Marius

On Feb 19, 3:52 pm, tbje  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
>   2.8.0.Beta1
>   2.0-scala280-SNAPSHOT
> with
>   2.7.7
>   2.0-SNAPSHOT
> 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  wrote:
>
>
>
> > Can you also try with Scala 2.7.7 ?
>
> > On Feb 19, 2:26 pm, tbje  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",  > > onclick={ajaxInvoke(() => JsRaw("alert('hi')"))._2} value="Say hi" /
>
> > > >))
>
> > > This works as expected however:
> > > partialUpdate(SetHtml("field", a(() => JsRaw("alert('hi')"),
> > > Link)))
>
> > > 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

[Marius]

Can you also try with Scala 2.7.7 ?

On Feb 19, 2:26 pm, tbje  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",  onclick={ajaxInvoke(() => JsRaw("alert('hi')"))._2} value="Say hi" /
>
> >))
>
> This works as expected however:
> partialUpdate(SetHtml("field", a(() => JsRaw("alert('hi')"),
> Link)))
>
> 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

[Marius]

On Feb 16, 8:11 pm, soumik  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  wrote:
>
>
>
> > On Feb 16, 11:17 am, soumik  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  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  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  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  wrote:
>
> > > > > Hi Marius,
>
> > > > >  Thanks for your response. I'm sorry for mis-communicating my problem
> > >

[Lift] Re: Error processing SHtml functions withing nested NodeSeq/Scala code

[Marius]

On Feb 16, 11:17 am, soumik  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  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  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  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  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"
>
> > >       {dirName}
> > >          
> > >          {files.flatMap(f => {
> > >               if (f.isDirectory())
> > >               {
> > >                  Log.info("

[Lift] Re: Cached CSS (and Javascript?) issue

[Marius]

On Feb 16, 3:55 pm, Alex Black  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"
>
> > 
> >   
> >   
> > 
>
> > 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  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 expect

[Lift] Re: Error processing SHtml functions withing nested NodeSeq/Scala code

[Marius]

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  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"
>
>       {dirName}
>          
>          {files.flatMap(f => {
>               if (f.isDirectory())
>               {
>                  Log.info("Directory: " + f.toString)
>                  listFilesInDir(f.toString)
>               }
>               else
>               {
>                  Log.info("Regular file: " + f.getName)
>                  
>                   {SHtml.link("", () => showFile1,
> Text(f.getName)) }                   //This is the line causing the
> issue
>                  
>               }
>            }
>          )}
>          
>    }
>
>    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: ", 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  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  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  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  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

[Lift] Re: Lift Record

[Marius]

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  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: Error processing SHtml functions withing nested NodeSeq/Scala code

[Marius]

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  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"
>
>       {dirName}
>          
>          {files.flatMap(f => {
>               if (f.isDirectory())
>               {
>                  Log.info("Directory: " + f.toString)
>                  listFilesInDir(f.toString)
>                  
>               }
>               else
>               {
>                  Log.info("Regular file: " + f.getName)
>                  
>                   {SHtml.link("", () => playFile1,
> Text("Something")) }                 /* Problem in this line */
>                  
>               }
>            }
>          )}
>          
> ---
> 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: New logging code

[Marius]

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

[Marius]

That is an option, thanks.

On 14 feb., 04:45, Naftoli Gugenheim  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
> 
>
> > > > thus Lift could generate:
>
> > > > 
>
> > > > 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.

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

[Marius]

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  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
>
> }
>
> 
> Please click here 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: JsCmds disabled inputs do not submit information

[Marius]

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  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: Cached CSS (and Javascript?) issue

[Marius]

On 13 feb., 18:44, Timothy Perrett  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"



  
  


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  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: Cached CSS (and Javascript?) issue

[Marius]

On 12 feb., 23:04, Alex Black  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

[Marius]

On 12 feb., 22:56, Alex Black  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  wrote:
>
>
>
> > Oh yes I did and I hate it. Ironically I was about to propose a
> > solution for this.
>
> > instead of
>
> > 
>
> > do something like:
>
> > 
>
> > this would render:
>
> > 
>
> > 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  would do the same.
>
> > Br's,
> > Marius
>
> > On 12 feb., 19:25, Alex Black  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

[Marius]

On 12 feb., 21:31, Jeppe Nejsum Madsen  wrote:
> On Fri, Feb 12, 2010 at 8:20 PM, Marius  wrote:
> > Jeppe probably we can combine the two proposals.
>
> Yes, that would be natural
>
> > Perhaps something like:
>
> > 
>
> > thus Lift could generate:
>
> > 
>
> > 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: Cached CSS (and Javascript?) issue

[Marius]

I opened 
http://www.assembla.com/spaces/liftweb/tickets/346-Solve-CSS-JS-unwanted-caching

Br's,
Marius

On 12 feb., 21:20, Marius  wrote:
> Jeppe probably we can combine the two proposals. Perhaps something
> like:
>
> 
>
> thus Lift could generate:
>
> 
>
> 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  wrote:
>
>
>
> > On Fri, Feb 12, 2010 at 7:28 PM, Marius  wrote:
> > > Oh yes I did and I hate it. Ironically I was about to propose a
> > > solution for this.
>
> > > instead of
>
> > > 
>
> > > do something like:
>
> > > 
>
> > > this would render:
>
> > > 
>
> > > 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  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

[Marius]

Jeppe probably we can combine the two proposals. Perhaps something
like:



thus Lift could generate:



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  wrote:
> On Fri, Feb 12, 2010 at 7:28 PM, Marius  wrote:
> > Oh yes I did and I hate it. Ironically I was about to propose a
> > solution for this.
>
> > instead of
>
> > 
>
> > do something like:
>
> > 
>
> > this would render:
>
> > 
>
> > 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  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

[Marius]

Tim please see my proposal above :)

On 12 feb., 21:12, Timothy Perrett  wrote:
> This is pretty much what rails does. Straight from github:
>
>  href="/stylesheets/bundle_common.css?7371c81fbc6b010a32fb11b42a0fc322c3c578 
> 63" media="screen" rel="stylesheet" type="text/css" />
>  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:
>
> 
>
> Thoughts?
>
> Cheers, Tim
>
> On 12 Feb 2010, at 18:53, Jeppe Nejsum Madsen wrote:
>
>
>
> > On Fri, Feb 12, 2010 at 7:28 PM, Marius  wrote:
> >> Oh yes I did and I hate it. Ironically I was about to propose a
> >> solution for this.
>
> >> instead of
>
> >> 
>
> >> do something like:
>
> >> 
>
> >> this would render:
>
> >> 
>
> >> 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  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

[Marius]

Oh yes I did and I hate it. Ironically I was about to propose a
solution for this.

instead of



do something like:



this would render:



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  would do the same.

Br's,
Marius

On 12 feb., 19:25, Alex Black  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: Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields

[Marius]

Excellent work Ross !

On Feb 12, 6:49 am, Ross Mellgren  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: Logging changes

[Marius]

Not sure about Jeppe but this sounds really good to me.

Br's,
Marius

On Feb 12, 6:56 am, David Pollak 
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: Welcome javier Goday to the Lift committers

[Marius]

WELCOME !

On 9 feb., 18:09, David Pollak  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: Netty integration

[Marius]

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  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: how to combine sequence of JsCmd in SHtml.ajaxCall?

[Marius]

     (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  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
>   }
>
>  
>
> 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: HTTP Reason Phrase

[Marius]

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

[Lift] Re: Forcing Authentication not working

[Marius]

Please open a defect here http://www.assembla.com/spaces/liftweb/tickets

Br's,
Marius

On Feb 7, 10:44 pm, aw  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

[Marius]

What Lift version are you using?

If you are using an Ajax form  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  
should be fine. But typically for field related message you could use
 which would render only messages associated
with "field_id" id. As a side note  only render messages
that are not associated with any ID.

Br's,
Marius

On Feb 6, 3:51 pm, wibblecp  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  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,
> > >  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  wrote:
> > >> wibblecp  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:
>
> > >> 
>
> > >> 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: Error messages are not displayed - 2.0-M1

[Marius]

Are you using in your html page  ?

Br's,
Marius

On Feb 6, 10:45 am, wibblecp  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: LiftRules inconsistencies (including FactoryMaker grump)

[Marius]

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  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: liftAjax jQuery 1.4.1 problem

[Marius]

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  wrote:
> On Wed, Feb 3, 2010 at 11:55 AM, Jonathan Hoffman wrote:
>
> > 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: CometActor.fixedRender always below render?

[Marius]

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 
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: Snippet attribute pass through

[Marius]

Yes, sorry for not being more explicit about -%> preserving
attributes.

Br's,
Marius

On 1 feb., 18:39, ced  wrote:
> Thanks for the fast response, Darius.
>
> I tried it out and it seem that the "-%>" operator puts the attributes
> through untouched, so one has to write 
> instead of the former prefixed version 
> >.
>
> Cheers,
> Chris
>
> On 1 Feb., 17:06, Marius  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  wrote:
>
> > > Replace your bind with:
>
> > > bind ("ledger", content, "time" -%> {(new
> > > java.util.Date).toString})
>
> > > 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  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
> > > >  
> > > > 
>
> > > > // The snippet class
> > > > class Ledger { def balance (content : NodeSeq ) : NodeSeq = {
> > > > bind ("ledger", content, "time" -> {(new
> > > > java.util.Date).toString})
>
> > > > }
> > > > }
>
> > > > 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

[Marius]

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  wrote:
> Anyone want to fix the book? :)
> Anyway, once you're using -%> you want it to be id, not ledger:id.
>
> -----
>
> Marius 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  wrote:
>
>
>
>
>
> > Replace your bind with:
>
> > bind ("ledger", content, "time" -%> {(new
> > java.util.Date).toString})
>
> > 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  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
> > >  
> > > 
>
> > > // The snippet class
> > > class Ledger { def balance (content : NodeSeq ) : NodeSeq = {
> > > bind ("ledger", content, "time" -> {(new
> > > java.util.Date).toString})
>
> > > }
> > > }
>
> > > 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: Snippet attribute pass through

[Marius]

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  wrote:
> Replace your bind with:
>
> bind ("ledger", content, "time" -%> {(new
> java.util.Date).toString})
>
> 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  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
> >  
> > 
>
> > // The snippet class
> > class Ledger { def balance (content : NodeSeq ) : NodeSeq = {
> > bind ("ledger", content, "time" -> {(new
> > java.util.Date).toString})
>
> > }
> > }
>
> > 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

[Marius]

Replace your bind with:

bind ("ledger", content, "time" -%> {(new
java.util.Date).toString})

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  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
>  
> 
>
> // The snippet class
> class Ledger { def balance (content : NodeSeq ) : NodeSeq = {
> bind ("ledger", content, "time" -> {(new
> java.util.Date).toString})
>
> }
> }
>
> 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: Question on Javascript calls

[Marius]

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" 
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: Passing attributes to bound elements

[Marius]

This was considered later on a defect, and not a feature. To preserve
markup attributes in your bind use -%> instead of ->

Br's,
Marius

On Jan 29, 12:38 am, Adam Warski  wrote:
> When trying to use datepicker on a form, I found a post (by Derek 
> Chen-Becker) from august which says:
>
> "OK, the key there is the entrydate id. If you look at
> src/main/webapp/index.html, you'll see the markup in the "Add Entry" form:
>
>            
>
> That e:id attribute gets merged so that the resulting element has the
> attribute id="entrydate" set (likewise for maxlength). This is a convenient
> way of setting attributes on templates that will be bound in your snippets. "
>
> And I wanted to use this way of setting attributes on elements, but it 
> doesn't seem to work - no attributes get rendered on the resulting element. 
> Is this still supported? (the only difference from the example is that I 
> don't use "e:id" but my own prefix which I then bind to in my snippet)
>
> --
> 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: Exception notification?

[Marius]

See LiftRules.exceptionHandler

On Jan 29, 12:33 am, Yu-Shan Fung  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: Lift logging improvements

[Marius]

+1

On Jan 27, 11:59 pm, Jeppe Nejsum Madsen  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.