Re: [Lift] More dynamic Lift
David Pollak feeder.of.the.be...@gmail.com writes: Folks, I spent today cracking the code on how to implement a more dynamic Lift development cycle. Awesome! 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 I think I can live with that - Page loads in development mode will be 10x-50x slower than in non-development mode Is this always or just when code has changed? If always, this may be a bit dramatic increase :-) - 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? As the one who probably initiated this, yes :-) I'm still unsure about how well it works in practice. Only time will tell. It looks like it doesn't need JRebel, which I think many consider really useful for doing rapid development. I wonder if page/loads etc can be improved if JRebel was used? I think the important part now is to get the ball rolling an try it out in real life. If the model is sound, the implementation can be improved Should it be part of development mode or should there be another demarcation of the dynamic reload mode? On first look, it seems if one doesn't use dynamicDevelopmentMode there are no drawbacks? If that's the case, I don't see the need for another demarcation. /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.
Re: [Lift] Re: More dynamic Lift
On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett timo...@getintheloop.eu wrote: I'm afraid I agree with Marius... I'm just not sure on the benefit here over JRebel? My main pain point was changes to Sitemap. JRebel doesn't help you here as it's fixed once Lift is booted... /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: More dynamic Lift
On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett timo...@getintheloop.eu wrote: BTW, with SBT, don't forget you can do: jetty-run (make changes to your code) prepare-webapp That will redeploy chnaged files / classses to the running jetty instance so development with SBT can still be slick without javarebel :-) But still this doesn't address the problem (I think?) of changing things in Boot. Maybe I code differently from everybody else, but when iterating new features, I always end up making lots of changes to Sitemap. And afaik everyone of those changes requires a restart For the rest I agree JRebel fits quite nicely (it does have it's problems as David points out) /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.
Re: [Lift] Re: field without mapper and Form validation
On Tue, Mar 9, 2010 at 3:17 PM, Francois fan...@gmail.com wrote: Le 09/03/2010 10:12, Francois a écrit : Hello guys, I'm often using forms without anything to do persistence and RDBMS related, but I would like to be able to use Fields (StringField, EmailField, my owns, etc), validation, error management, etc. without having everything to manage by hand. After searching more carefully on the mailing list archive, it seems that what I'm looking for is something like a mix of one-page wizard with Record/Mapper fields integration (or fields that are currently in Record/Mapper/Wizard may live in there own package and only manage the domain/client part ?) Relevant threads: - http://old.nabble.com/Multipage-wizards-td26504293.html (especially Jeppe answer) - http://old.nabble.com/Lift-Wizard-Fields-incompatible-with-lift-record-fields-tc27230782.html So, I'm going to see how wizards are working, Cool, let me know how it works. As you noted, I basically have the same needs, but haven't started to look into this yet :-) I saw the Lift example now includes a one page form (based on wizards): http://demo.liftweb.net/simple_screen /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.
Re: [Lift] Re: How to use lazy-load?
Marius marius.dan...@gmail.com writes: I opened defect 412 and this is now on the review board: http://reviewboard.liftweb.net/r/263/diff/#index_header Wow, that was fast :-) Thanks for looking into this! /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.
Re: [Lift] Lift-M2 One To Many and CRUDify
ojonam manojo10...@gmail.com writes: Hello all, I recently tested the wiki example of Book and Authors as an exercise, and extended them with CRUDify. On generation, however, the Author field in the Book create page says : Can't Change!, instead of giving me a select list of all the authors. My question is : Is this normal behavior ? If not, how do I go repairing this ? I assume author is a MappedForeignKey? If so, you need to override validSelectValues. Not sure why there isn't a default impl of this though, should be possible /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.
Re: [Lift] Re: Javascript Dependencies
Marius marius.dan...@gmail.com writes: On Mar 6, 9:14 pm, Peter Robinett pe...@bubblefoundry.com wrote: [...] Hmmm ... anything that is outputting (x)html. We have snippets, comet actors, LiftView-s. Any of these can called multiple times but IMHO registration should happen once. For snippets and comet we could a nested snippet such as: lift:MySnipet.work lift:dependencies script src=bla.js/ // you got the idea /lift:dependencies // specific tags /lift:MySnipet.work I think my use case is slightly different, but can still be handled with the above. Basically, I don't want the dependencies to show up in my markup, but be handled by higher level components (or snippets) In my markup, I'll have a high level snippet: lift:Chart.render stuff /lift:Chart.render The chart snippet will now, depending on a lot of factors, emit a number of dependencies (eg jquery, jqplot a pie chart render). But I think this should still work given the above. [...] 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 agree, lets see if this becomes a problem I think this would cover snippets and comet actors and it should also work for LiftView-s Thoughts ? Sounds good. But it seems to leave the dependency management to the user (e.g. in the above scenario, I would have to declare all 3 dependencies, not just the pie chart render, that will then include jqplot that will then include jquery) ?? This is not necessarily a bad thing. /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] How to use lazy-load?
Hi, I have a page with a somewhat lengthy first-time load. So I found lazy-load that looked handy, but it doesn't seem to work. This is my template: lift:surround with=wide at=content h2Udvikling per måned/h2 lift:lazy-load lift:performanceChart div class=span-5 Vis:br/ performance:mapReduce/br/ Opdel efter:br/ performance:groupBy/ /div div class=column span-19 last performance:chart/ div id=tableperformance:dataTable//div /div /lift:performanceChart /lift:lazy-load /lift:surround Nothing in the performanceChart snippet is rendered when wrapped with lazy-load (but I see from the logs that the snippet as being called) If I wait a while, I can see the comet actor shutdown: 15:29:55.096 [ool-2-thread-13] INFO lift - The CometActor net.liftweb.builtin.snippet.asyncrenderco...@131e8e72 Received Shutdown What am I missing? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Enable -Xcheckinit in 2.8 port?
Hi, Just found out why the Logging stuff doesn't work on the 2.8 branch. Details here: http://permalink.gmane.org/gmane.comp.lang.scala.user/24469 Is it somehow possible to enable the -Xcheckinit flag for the 2.8 branch? Don't know how common that issue is, but it may help trap some subtle errors. Don't know what the performance penalty is though. /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.
Re: [Lift] Re: How to use lazy-load?
On Mon, Mar 8, 2010 at 5:42 PM, Marius marius.dan...@gmail.com wrote: Can you please send me a minimalistic example ? .. The comet actor shutdown looks correct to me as after the lazy content is rendered that comet is not needed anymore. Not easily. When I get some time I'll see if I can reproduce it in a sample. Can you check with firebug if you get any asynchronous javascript back from the comet request? It looks a bit strange. The normal request (with not lazy load) is about 3s. With the lazy load the comet request is almost 60s before anything (not the correct content) is returned (timed out?) Hold on! I did some more digging :-) Since this was just a naive application of lazy-load around an existing snippet, it contained bind with a few ajaxSelects inside. It seems this is what caused the problems. If I remove the ajaxSelects it seems to work. Not sure if this is a supported scenario or not, but if not we should probably emit some notification when running in dev mode.or at least document what can be put inside lazy-load /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] @Req for PermRedirectResponse after a site redesign
Bob Folkerts rob...@folkertsfotografie.com writes: I am switching my wife's hosted photography site to Liftweb, largely as a reason to learn Lift. Part of the conversion is moving the old directory structure to a cleaner structure. I wanted to redirect all of the old URI's to the modern equivalent. I read Chapter 13 of the Lift book and got the following to work: LiftRules.dispatch.prepend{ case r @Req(Portraits::High-School::Seniors::_::Nil, _,_) = () =Full(PermRedirectResponse(/Galleries/HighSchoolSeniors, r)) } LiftRules.dispatch.prepend{ case r @Req(Portraits::High-School::Seniors::_::_::Nil, _,_) = () =Full(PermRedirectResponse(/Galleries/HighSchoolSeniors, r)) } LiftRules.dispatch.prepend{ case r @Req(Portraits::High- School::Seniors::_::_::_::Nil, _,_) = () =Full(PermRedirectResponse(/Galleries/HighSchoolSeniors, r)) } This gives me a beautiful 301 redirect, so the world is good. Google will transfer any page rank and any old links will work. But it seem like there should be a nicer way to do this for arbitrary depth. I know that doesn't make much sense for an API, but it would be nice for me if there was an equivalent of /Portraits/High-School/ ** for arbitrary depth matching. Does this work for you: LiftRules.dispatch.prepend{ case r @Req(Portraits::High-School::Seniors::_,_,_) = () =Full(PermRedirectResponse(/assets/list,r)) } /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.
Re: [Lift] Re: More dynamic Lift
On Tue, Mar 9, 2010 at 2:42 AM, harryh har...@gmail.com wrote: What's the advantage of this sort of setup over using JavaRebel? Sitemap and other things set in boot doesn't really change even if the class is reloaded by JRebel /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.
Re: [Lift] superficial first impressions from a rails junkie
cageface milese...@gmail.com writes: [lots of stuff about layout] I agree and as Marius wrote it's (the website at least) is a known issue and is being worked on. But it's moving slowly. I think the underlying problem here is that the Lift committers are mostly code geeks and not really into the visual aesthetics. Maybe this is a difference from the Rails community: I think a lot (not all of course) of Lift's users have a Java background which is usually not connected with great visual artwork. But many of the Rails guys (the few I've talked to at least), seems to come from design studios etc. where there's very much focus on design. So if someone in the Lift community has the skills to help out in this area that would be awesome :-) We can talk technical merits all day long, but at the end of the day I think first impressions matter for wider adoption. 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. I don't like maven either, but you're not forced into using maven. But since all tutorials use it you may get that impression. I have a blog post waiting for a simpler (albeit less powerful) way to get started. 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? HTML literals *in* the code? Marius already addressed this and I agree with him :-) 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... No one is forcing you to have a six level deep directory structure. The src/main/scala prefix is a maven convention. But I think it makes sense. In my latest projects I've dropped the usual java package conventions of com.company.project and now just use project. Works out nicely. [...] And at this point we give up and start quickly paging through the rest of the tutorial only to come to this: object priority extends MappedInt(this) { override def defaultValue = 5 override def validations = validPriority _ :: super.validations def validPriority(in: Int): List[FieldError] = if (in 0 in = 10) Nil else List(FieldError(this, bPriority must be 1-10/b)) override def _toForm = Full(select(ToDo.priorityList, Full(is.toString), f = set(f.toInt))) } and we suddenly find a new appreciation for :validates_numericality_of I don't know it, but you could probably write the equivalent validation function in Lift. Remember, Lift is still relatively young compared to Rails. It won't have all the bells whistles yet. and we also wonder why our model should be specifying it's representation in the form and we decide to go googling for whatever the Scala equivalent of Sinatra is. I don't know Sinatra but found this description: Sinatra is a very simple, yet powerful, Domain Specific Language (DSL) for defining RESTful HTTP actions, and then defining how the application is going to respond to them This sounds awfully close to the lift-webkit module. If you don't like the Lift ORM, don't use it. Writing a REST api with Lift is quite clean. You could probably google for some examples. I apologize if this seems flippant but I really think that a lot of people won't even push on this far, never mind having to do the homework of learning the basics of scala first. I know that docs and introductory materials aren't usually that much fun to work on and I can imagine that the framework itself is much more polished and sophisticated but as potential recruiting material I think this just isn't very good. As I wrote earlier, I think first impressions are important. Thanks for sharing. I can only say that I've found Lift a joy to use and very powerful at the lower layers. As you move up in the abstraction layers (think forms etc) it's not as polished yet, but it has a solid foundation to build on. /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.
Re: [Lift] superficial first impressions from a rails junkie
Timothy Perrett timo...@getintheloop.eu writes: Sorry Jeppe, but I disagree. On which part :-) Maybe the not really into the visual aesthetics. What I meant was not that we don't care, but more that we will rather spend time on coding. The issue to date has been getting someone to work on it for free... The recession has worked against us here because people have been hand-to-mouth work wise, and couldn't spare time that wasn't paid for. Look at it this way: Committers work on the code for free and I guess that's also the case for many other OSS projects. Yet some still manage to create visually pleasing websites introduction material. I can only (perhaps falsely?) attribute this to the difference in focus/skills of the team. I actually come from a marketing / design background, and have tried to move this aspect of Lift along, but its been problematic with designers not committing and so forth. Lift needs a rebrand / restyle, yes, however, its easier said than done. My point exactly. If someone on the Lift community feels strong enough about this (and has the skills) it would move forward in the same way as the code...alas it doesn't, so we need to force it by trying to hire/manage someone external. /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.
Re: [Lift] Customizing generated form elements without touching scala code
On Fri, Mar 5, 2010 at 1:07 PM, Julian Backes julianbac...@googlemail.com wrote: Hi, I'm trying to get my first form in Lift running and I'm having the following problem: I use for example SHtml.text(..) to create a text input element. Unfortunately, this element has no specific class or id such that I can customize it using CSS or whatever. I know that I can add some parameters to SHtml.text(..) which are passed to the generated form element but this means that I have style information in my scala code. And this is, in my opinion, very ugly. Not sure if you mean having the classname in scala code is ugly? If not you can pass a class as attribute.and style the class externally Is there a better solution? I could imagine something like e:myfield class=somecssclass/. Yes, if in your snippet you use -% instead of - to bind, attributes will be preserved. Or you can use FuncAttrBindParam to bind calculated values for attributes. /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.
Re: [Lift] email validation configuration
On Fri, Mar 5, 2010 at 2:21 PM, GA my_li...@me.com wrote: Hello guys, could you please let me know where I can find information about how to configure the email validation for the MegaProtoUser? I do not know how to tell Lift about our SMTP server, Authentication data, etc. I was searching in the wiki and this list but I could not find anything. Have a look at the Mailer object. Specifically, it reads either jndi or the property mail.smtp.host for the hostname. Not sure if handles authentication. /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.
Re: [Lift] Textmate bundle with codecompletion (beta)
Mads Hartmann Jensen mads...@gmail.com writes: Ok, This is the last time I'll bump this (I promise) - anyone using TextMate can follow the bundle on github. I improved the bundle and it's fairly usable now, check out a teaser video here: http://www.sidewayscoding.com/2010/03/textmate-lift-bundle-v02.html Cool! While I don't use TextMate you've inspired me see what's possible with Eclipse when 2.8 becomes usable with Lift (too much brokeness in the 2.7 plugin) /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.
Re: [Lift] Response Optimizations too aggressive
aw anth...@whitford.com writes: [...] !--[if IE 6] script type=text/javascript id=ie6fix ... / script ![endif]-- Firefox and Chrome will ignore these, which is perfect, and only IE will pay attention (and suffer the overhead). All was working fine in dev, then came time to roll out to production and I naturally specified -Drun.mode=production. Surprisingly, production mode has an optimization that strips HTML comments from the output. Generally, I think this is a great idea -- EXCEPT if we have IE specific comments responding to an IE browser. Is there a way to modify the optimization so that IE specific comments are retained? Alternatively, can I simply disable this optimization feature so that my IE users are OK? Ross already described how to disable this, but this seems like a genuine useful feature (to not remove some comments). Iircc, there are other scenarios (such as AdWords) where you would like to keep the some comments. Not sure how to handle this in a general way though. In this case You can also handle it server side: Req.isIE6 /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.
Re: [Lift] Re: Response Optimizations too aggressive
On Thu, Mar 4, 2010 at 8:47 AM, aw anth...@whitford.com wrote: On Mar 3, 10:56 pm, Ross Mellgren dri...@gmail.com wrote: There's a FactoryMaker in LiftRules that looks like it may do what you want -- try: LiftRules.stripComments.default = () = false -Ross This looks promising. Alas: error: reassignment to val (I'm not familiar with FactoryMaker.) I see that LiftRules.stripComments is a val, not a var... It's unclear to me how to override this. Ahh, think you have to do: LiftRules.stripComments.default.set(() = false) /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.
Re: [Lift] non snapshot version of lift for scala 2.8
On Thu, Mar 4, 2010 at 10:39 AM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Lukasz, We don't have non-SNAPSHOT version of Lift for scala 2.8 branch yet. You are encouraged to use 2.0-scala280-SNAPSHOT and report any issue that you encounter. Is there a status of the 2.8 branch somewhere on what works and what doesn't? (Ie. are some modules missing, known things that don't work) Or is everything ported and stuff that doesn't work is a defect? I would love to get to the 2.8 Eclipse plugin and I've just started a new Lift project where I can accept some bumps along the road, but I've held off until now because I wasn't really sure of the status /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.
Re: [Lift] non snapshot version of lift for scala 2.8
On Thu, Mar 4, 2010 at 12:27 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: On 04/03/10 3:26 PM, Jeppe Nejsum Madsen wrote: On Thu, Mar 4, 2010 at 10:39 AM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Lukasz, We don't have non-SNAPSHOT version of Lift for scala 2.8 branch yet. You are encouraged to use 2.0-scala280-SNAPSHOT and report any issue that you encounter. Is there a status of the 2.8 branch somewhere on what works and what doesn't? (Ie. are some modules missing, known things that don't work) Or is everything ported and stuff that doesn't work is a defect? The only module missing at the moment is lift-osgi and related ones because it is dependent on 2.8 port of scalamodules. Heiko said one is on its way as an Eclipse project (www.eclipse.org/proposals/scalamodules). The rest are either of: - defects - non-functional because of API change - sub-optimal design - combination of the above (look for the comment FIXME: 280 in the code-base) I would love to get to the 2.8 Eclipse plugin and I've just started a new Lift project where I can accept some bumps along the road, but I've held off until now because I wasn't really sure of the status If you can accept the bumps, you are welcome to give scala 2.8 port a shot. This would be great in fact. Cool! Thanks for the update, I think I'll try it... /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.
Re: [Lift] SQL error
On Thu, Mar 4, 2010 at 1:25 PM, Mads Hartmann mads...@gmail.com wrote: Hello everyone, I'm not sure if this is a lift problem or it's me. I'm trying to add the ability to upload images to a project - I'm using the code explained here: http://groups.google.com/group/liftweb/browse_thread/thread/b0509263e18c9a66/f36535bbe15273d6?lnk=gstq=image+upload#f36535bbe15273d6 I added two mapper classes: --- class ImageInfo extends LongKeyedMapper[ImageInfo] with IdPK { def getSingleton = ImageInfo object date extends MappedLong(this) { override def defaultValue = Helpers.millis } object mimeType extends MappedPoliteString(this, 64) object name extends MappedPoliteString(this, 256) { override def dbIndexed_? = true override def defaultValue = private def noSlashes(s: String) : List[FieldError] = if (s.contains(/)) List(FieldError(this, Text(Image name \ + s + \ may not contain \/\))) else Nil override def validations = valMinLen(1, Image name must not be empty) _ :: valUnique(Image name must be unique) _ :: noSlashes _ :: super.validations } object blob extends MappedLongForeignKey(this, ImageBlob) def deleteWithBlob { this.blob.obj match { case Full(x) = x.delete_! case _ = } this.delete_! } } - and -- class ImageBlob extends LongKeyedMapper[ImageBlob] with IdPK { def getSingleton = ImageBlob object image extends MappedBinary(this) } - The schemifier couldn't create the tables it gave to following error :: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'blob BIGINT UNSIGNED) ENGINE = InnoDB' at line 1 this is the sql statement it tried to execute CREATE TABLE imageinfo (name VARCHAR(256) , id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE KEY , date_c BIGINT , mimetype VARCHAR(64) , blob BIGINT UNSIGNED) ENGINE = InnoDB I looks like it tries to create a column named blob, afaiks blob is a reserved word in MySql http://dev.mysql.com/doc/refman/5.0/en/reserved-words.html You could try renaming the field. If this solves the problem, please file a ticket /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.
Re: [Lift] Re: SQL error
On Thu, Mar 4, 2010 at 1:49 PM, Mads Hartmann mads...@gmail.com wrote: Ah! That fixed it, thanks a lot Jeppe ;) I'm not sure what to say in the ticket though, the column-name blob was a bad choise made by me. Yes, but lift tries to be clever and changes the column name if it matches a reserved word (look at your date column, it got the _c appended). We should just add the name blob to the list of reserved words. Hey you're a comimtter, you can add it (after creating the ticket :-) /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.
Re: [Lift] Re: New logging code is in master
On Thu, Mar 4, 2010 at 6:12 PM, Stuart Roebuck stuart.roeb...@gmail.com wrote: Trying this on 2.8 with the 2.8 Lift Snapshot. The Logger trait seems to work fine though looking at the code I can't see how setup gets called. It should be called when the lazy val checkConfig is being initialized. The Loggable trait is throwing a null pointer exception. I'm using Log4J. Could you show (part of) the stacktrace? There's another glitch with the Logger specs in the 2.8 branch so I may get some time to look at this soon. Stuart. P.S. I don't want to mess with other people's wiki pages, but I wonder whether it is worth consolidating the pages: How To: Configure Logging and Logging in Lift. It's a community wiki. Feel free to edit :-) And you're right they should be consolidated. I actually thought I did a search before creating the new page...oh well. /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.
Re: [Lift] Re: conflicting slf4j versions when using M3 with smile
On Thu, Mar 4, 2010 at 8:35 PM, harryh har...@gmail.com wrote: OK, did that (like so in sbt): override def ivyXML = dependencies dependency org=net.lag name=smile rev=0.8.12 exclude module=slf4j-jdk14/ /dependency /dependencies I'm also getting this error when running my app from within sbt just javarebel (possibly this isn't a big issue, but the error is disconcerting): SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/Users/harryh/foursquare.web/ lib_managed/compile/slf4j-log4j12-1.5.11.jar!/org/slf4j/impl/ StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/Users/harryh/foursquare.web/target/ webapp/WEB-INF/lib/slf4j-log4j12-1.5.11.jar!/org/slf4j/impl/ StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. I don't know SBT.but is lib_managed/compile a SBT directory containing project dependencies or some internal SBT jars? If the former, it seems sbt puts both the jars from the compile dependencies as well as the jars in WEB-INF/lib on the classpath when running the application. This doesn't seem right (since when you deploy, only the jars in WEB-INF/lib are available).. /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.
Re: [Lift] Re: conflicting slf4j versions when using M3 with smile
On Thu, Mar 4, 2010 at 9:21 PM, harryh har...@gmail.com wrote: Hmm, slf4j-log4j12-1.5.11.jar ends up being in the classpath twice (from /Users/harryh/foursquare.web/lib_managed/compile and /Users/harryh/foursquare.web/target/webapp/WEB-INF/lib). A quick fix would be to apply exclusion of slf4j-log4j12 in lift-util declaration. This will prevent having slf4j-log4j12-1.5.11.jar under target/webapp/WEB-INF/lib. Then I don't get slf4j-log4j12 at all and I get exceptions: java.lang.NoClassDefFoundError: org/apache/log4j/Logger at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$ $_logger(Log.scala:207) at net.liftweb.util.LogBoot$$anonfun$6.apply(Log.scala:209) at net.liftweb.util.LogBoot$$anonfun$6.apply(Log.scala:209) at net.liftweb.util.Log$.rootLogger(Log.scala:85) at net.liftweb.util.Log$.warn(Log.scala:123) at net.liftweb.http.LiftServlet.service(LiftServlet.scala:89) Maybe this is a weird SBT problem? Maybe, see my previous reply. But note that SLF4j complained that two slf4j-log4j12 jars are in the classpath, Now you excluded one, but perhaps this also excluded the real log4j.jar (which contains the actual org/apache/log4j/Logger class). This could happen if the slf4j-log4j in lib_managed did not also include the log4j.jar You should be able to run the app by including the log4j dependency, but I don't think this is a real solution as slf4j-log4j12 will probably not be included in the war file if it's not WEB-INF/lib. I tend to think the underlying problem (two slf4j-log4j12 jars on the classpath) is in SBT, so maybe you should ask on the sbt list. /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.
Re: [Lift] JUnit test using Selenium RC
On Wed, Mar 3, 2010 at 10:30 AM, Tweek d.sztwio...@gmail.com wrote: Hi, I'm writting Selenium tests with Scala JUnit. The problem is when i try to put value in SHtml.ajaxText field. Selenium RC doesn't call my js function from this ajaxText. Not sure exactly what you mean by the above, but IIRC, the ajax request is not triggered by simply setting a value in a field but when you exit the field (onBlur). Also note that the fields usually get a unique id for each new page view. To get stable identifiers you should run in test mode (see the list for details) I'll be interested in your results as we probably have to do something similar soon :-) /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.
Re: [Lift] Re: JUnit test using Selenium RC
Ok, What happens if you, manually, type in new value in the field (only the text, don't press enter, dont click etc)?? My guess is nothing (unless you've added your own keyboard event handlers). And this is what your selenium test does. If so take a look here http://www.eviltester.com/index.php/2009/01/24/how-i-learned-to-love-seleniums-fireevent/ I think you need to add something like this to the test to trigger the ajax call: selSession.fireEvent(edit_field_1, blur); /Jeppe On Wed, Mar 3, 2010 at 12:48 PM, Tweek d.sztwio...@gmail.com wrote: okej, so: i've got code like this: var testStr : String = def set(s : String) : JsCmd ={ println(s) testStr = s JsRaw() } def render(ns : NodeSeq) : NodeSeq ={ bind(fields, ns, name - SHtml.ajaxText(testStr, (s : String) = setName(s) ) % (id - name), ... } and JUnit test with Selenium like this: class FirstSeleniumTest extends SeleneseTestCase { // �...@before override def setUp: Unit = { super.setUp(http://localhost:8080/;, *firefox) selenium.windowMaximize() } // �...@after override def tearDown: Unit = { selenium.close } // �...@test def testFirst = { selenium.open(/) selenium.waitForPageToLoad(3) selenium.`type`(name,new value) ... } } finally i'm running it from maven by: mvn test - Dtest=FirstSeleniumTest (jetty is running in other console) all of this is looking fine, selenium is working, new value is put in my ajaxText field, but the setName function is not call - i'm not get any log in console where jetty is running On 3 Mar, 10:40, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Wed, Mar 3, 2010 at 10:30 AM, Tweek d.sztwio...@gmail.com wrote: Hi, I'm writting Selenium tests with Scala JUnit. The problem is when i try to put value in SHtml.ajaxText field. Selenium RC doesn't call my js function from this ajaxText. Not sure exactly what you mean by the above, but IIRC, the ajax request is not triggered by simply setting a value in a field but when you exit the field (onBlur). Also note that the fields usually get a unique id for each new page view. To get stable identifiers you should run in test mode (see the list for details) I'll be interested in your results as we probably have to do something similar soon :-) /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.
Re: [Lift] minified js artifacts (was Re: Re-opened #363)
Indrajit Raychaudhuri indraj...@gmail.com writes: A quick followup on this minified js concern... [...] So the question is, should we: 1. Continue using yuicompressor (to compress js files at build time) and apply the strategy universally to all toserve/**/*.js OR 2. Include the minified version of the js artifacts and get rid of the build time compression trick While #1 has the clear advantage of having human-readable js files in the repository, it is critically dependent on build time compression. Exact opposite set of argument holds for #2. 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 :-) And since we are debating on this, the other option could be: 3. Keep both the form (un-minified and minified) available in resources/toserve and serve the un-minified form via gzip filter if user-agent has support for it (most does nowadays) or resort to minified form if user-agent doesn't. But gzip doesn't remove the need for minify. Gzipped minified jQuery is 40% smaller than gzipped jQuery: http://stackoverflow.com/questions/807119/gzip-versus-minify The behavior could be controlled via LiftRules even. Of course, this assumes that most production sites would be behind reverse proxies with proper cache control etc. and the overhead of gzip-ing is marginal. Bringing the decision (of minifying) in the framework realm also opens up the possibility of lazily creating one big js (synthetic or cached) and serving the entire stuff as one single response minified or otherwise depending on run.mode. Yes this would be the ideal and has been discussed on the list recently. /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.
Re: [Lift] minified js artifacts (was Re: Re-opened #363)
Indrajit Raychaudhuri indraj...@gmail.com writes: [...] My interest in the current context, is to have consistent behavior in the js artifacts bundled with Lift. To me (and Marius) #2 is also worth consideration. True that you'd have a compressed (IDE unfriendly) js in the codebase but you'd also be able to remove build-time dependency on yui compressor. (one less dependency, one less step etc.) But why is it a problem with the build-time dependency on yui compressor if it only concerns the building of the lift-*.jar? Or am I missing something? Ideally the lift jars should contain both, and the non-minified used in development. /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.
Re: [Lift] Snippets in subpackages?
David Pollak feeder.of.the.be...@gmail.com writes: [...] One of the things I do with page-specific snippets is call them out in SiteMap: Loc(..., Snippet(foo, snipetFunc)) That's actually a neat trick! I've been using this as well, but more in a CRUDify style way. I'm still trying to come up with some good ways to organize this in a modular fashion... /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.
Re: [Lift] Transactions with Mapper
ced docpom...@googlemail.com writes: When I use Mapper outside a request, say in an actor, how do I wrap it in a transaction? I know that I do a S.addAround(DB.buildLoanWrapper) to have transactions within a request. Can anyone provide a simple code snippet? You can use use :-) DB.use(DefaultConnectionIdenfifier) {connection = User.findAll } /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] Is CometActor the right tool for this job?
Hi, I haven't used Lift's comet support at all, but now it seems like a use case has popped up. I can do this with POA (Plain Ol Ajax), but, at least for me, it looks like CometActor might be a better fit. The use case is this: We need to show a page containing a chart and some tables with data. The user should be able to filter, group, select new axis values etc in the page and the chart/table should be updated. All the views use the same underlying data, which will take some time (5-10s) to pull up initially. Changing views after initial load will reuse the data. So I was thinking to have a CometActor that holds the data and can render the specified view. The UI will send view messages that tell how to slice the data. The benefits from the actor solution as I see it are: 1) Can load initial data asynchronously 2) Can hold on to the data while the user is on the page 3) Page update is asynchronously, so the UI is perceived as faster Are these assessments correct? Or is this overkill? A few questions: 1) I assume each page get their own instance of the actor so they can hold their own data. Is this correct? 2) When is a CometActor shutdown? Sometime after the user navigates away from page? 3) How do I get access to the CometActor instance on the page? I need to send a message to it from a function bound to e.g. an ajaxSelect /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.
Re: [Lift] reload application.properties
David Pollak feeder.of.the.be...@gmail.com writes: [...] What do you keep in your properties files that can change at runtime? Translated strings. You keep your translated strings in the files accessed by net.liftweb.util.Props? I haven't done any Lift localization, but I think that's the wrong place for them. Ahh I see we've been talking past each other then. I was talking about properties in the general sense (as read by e.g. S.?()), not about net.liftweb.util.Props which I agree is not important for dynamic reload. If the current implementation of the localization stuff isn't reloading the localization files on change during dev mode, that's a defect (or an enhancement) and deserves a ticket. Good to see we're on the same page after all. I'm pretty sure they're not being reloaded, but will double check and file a ticket if needed. [...] I'm not going to call Boot again, but I have a bunch of ideas of an efficient mechanism for recalculating stuff on a request-by-request basis in dev mode, but only once in production mode. But it will still require something that picks up the changed/reloaded class files from somewhere? I look forward to try it out. /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.
Re: [Lift] Maven projects generating with old Lift versions?
Nolan Darilek no...@thewordnerd.info writes: OK, I must be missing something. I copied this almost verbatem from the mini-guide on the Wiki, modified it and made it a shell script. Here's what I have: #!/bin/sh mvn archetype:generate -DarchetypeGroupId=net.liftweb \ -DarchetypeVersion=2.0-SNAPSHOT \ -DremoteRepositories=http://scala-tools.org/repo-snapshots \ -DgroupId=$1 \ -DartifactId=$2 When I run this, then select either blank or basic from the menu, I get what appears to be outdated code. Specifically, it wants to fetch Lift 0.8. What am I missing? It's been a while since I've generated a fresh project. This works: mvn archetype:generate \ -DarchetypeRepository=http://scala-tools.org/repo-snapshots \ -DremoteRepositories=http://scala-tools.org/repo-snapshots \ -DarchetypeGroupId=net.liftweb \ -DarchetypeArtifactId=lift-archetype-blank \ -DarchetypeVersion=1.1-SNAPSHOT \ -DgroupId=com.mypackage \ -DartifactId=myproject \ -Dversion=1.0-SNAPSHOT Have a look here: http://www.mail-archive.com/liftweb@googlegroups.com/msg15034.html /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.
Re: [Lift] Is CometActor the right tool for this job?
Thanks to all for the feedbackjust one remaining question below: On Tue, Mar 2, 2010 at 7:11 PM, David Pollak feeder.of.the.be...@gmail.com wrote: [...] Unless you're going to update the graph synchronously, the comet solution is not the best. A graph with ajax/json elements that update the graph and send back new data to chart would be my choice. Did you intend to write synchronously? I would think comet would be better suited for asynchronous updates, and curious what you had in mind otherwise... /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.
Re: [Lift] The role of LiftRules
Naftoli Gugenheim naftoli...@gmail.com writes: Would it be a bad idea to use java.util.Date for now, and if and when support is added for JodaTime, change it to a DateHolder (which would be added then)? Haven't looked in detail, but wouldn't this require two changes to client code? 1) One to use the new ConversionRules 2) One when DateHolder is introduced If so, I suggest we take the hit now to allow for a seamless (if such a thing exists :-) change to JodaTime /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.
Re: [Lift] Re: About the url rewrite (more thant one params and get 404 not found error)
Neil.Lv anim...@gmail.com writes: On Mar 1, 3:53 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: I'm not sure if this can be handled with the standard ParsePath, but it is fairly easy to write your own extractor that can handle more complex scenarios. Here's an example: object ParamsExtractor { def unapply(pp:ParsePath): Option[(Account, OrgUnit)] = { val result:Box[(Account, OrgUnit)] = if (pp.wholePath.startsWith(path) pp.wholePath.length == (path.length + 2)) { val res = Full((XX,YY)) debug(Decoded URL: %s=%s.format(pp,res)) res } else None result } } used like this: case RewriteRequest(ParamsExtractor(account,orgUnit) , _, _) = (RewriteResponse(path), Full(account, orgUnit)) I have some question about these code that i don't understand. The first one that contains the Map() in the RewriteResponse() . -- case RewriteRequest() = RewriteResponse() but the second one that doesn't contain the Map in the RewriteResponse(), what's the mean of the Full(account, orgUnit) in the ( RewriteResponse(path), Full(account, orgUnit) ) -- case RewriteRequest() = ( RewriteResponse(), Full() ) Ahh yes, the example was from a Loc rewrite, The principle is the same I guess, you should be able to do something like this: case RewriteRequest(ParamsExtractor(account,orgUnit) , _, _) = RewriteResponse(path, Map(account - account, orgUnit - orgUnit)) The important part is the extractor which takes care of parsing the request into meaningful values... /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.
Re: [Lift] New logging code is in master
On Mon, Mar 1, 2010 at 12:20 AM, David Pollak feeder.of.the.be...@gmail.com wrote: Excellent! We have the deprecations turned off in the pom.xml file by default... but gotta turn the deprecation warnings on post M3. Not sure what this means? Do the generated jars on scala-tools not contain deprecation info or does the compilation of Lift itself not show deprecation warnings? If the former, this would explain what I see. If the latter, I added args arg -deprecation /arg /args to my own pom and would expect this to show the warnings /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] snakify and abbreviations
Hi, Eager to use the new Mapper support for snake_case I discovered that the snakify method doesn' handle abbreviations well: StringHelpers.snakify(HTML) res5: java.lang.String = h_t_m_l StringHelpers.snakify(HTMLEditor) res6: java.lang.String = h_t_m_l_editor I would expect those to be html and html_editor respectively... What do people think? /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.
Re: [Lift] Re: Javascript Dependencies
Marius marius.dan...@gmail.com writes: [...] I'm not sure that doing this per snippet is the right approach. Maybe we differ in our thinking then :-) I'm thinking more in a component oriented approach where I would like to put a widget on a page. I'll just add the correct snippet tags to my page and don't want to worry about which js dependencies I need to include before the snippet works. The reason I'd put it LiftRules is that it CAN use a dependency tree per page ... after all, scripts are specified per page. Yeah, maybe some flexibility is needed and as usual it seems like a good idea to have the low level foundations in place first and build the higher level abstractions on top. If we have the function in LiftRules it should be possible to what I want by creating a smarter Req = Tree function. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Newbie Q: Lift suitable as webgui for java 6 app with embedded webserver and no database ?
mortench morte...@gmail.com writes: Hi All, [...] How suited would Lift be for this scenario or to be more precise: a) Is a lift web app as fast to startup as a normal jave jsp/servlet app ? Depends mostly on your own code. If you have an empty Boot, startup is 1s. b) Can lift be used without a database and can the relate code such as the OR mapped be omitted ? Yes c) Any special considerations needed when starting and stopping an embedded lift web app ? Dunno :-) d) What does lift require of the java web server ? I.e. can some of the more lightweight java web servers be used that might not support the full servlet/jsp specifications such as the embedded HTTP server in Java 6, Winstone, Grizzly etc.? ... What (light) java webservers are lift known to work with ? You need a recent servlet implementation. JSP is not needed. I'm using Jetty although not embedded, but Jetty seems like it should easily be embedded. During development, I launch a small Scala app that starts jetty (the RunWebApp class generated by the Lift archetype) e) What would the best way for the lift web app to communicate with the backend code of the java app ? By just calling into the existing java code (some integration/classloader issues here?) or more loosely by calling REST WS Api exposed by the Java code ? Not sure what you envision here, but REST and loosely coupled should work :-) f) I am using ANT and not maven to develop the java app. Will be able to make Lift work with ANT so I use the same build tool for everything? Yes, but you're probably on your own g) What version of lift should I use ? In particular does Lift 2.0 change anything for my scenario ? You should use the latest 2.0-SNAPSHOT or milestone (M3 is just around the corner) /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] MapperRules.nameToDisplayName?
Hi, In the interest of cutting boilerplate from mapped objects, I would like to get the display name from a property file. So I was thinking that it would be an idea to add a MapperRules.nameToDisplayName such as this var nameToDisplayName: ( Mapper[_], String) = (_,name) = name This would allow me to do things like nameToDisplayName = (m,name) = S.?(m.getClass.getName+.+name) 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.
Re: [Lift] Re: Javascript Dependencies
Marius marius.dan...@gmail.com writes: Yes we do have different perspectives. I'm saying for page X here these are the JS dependencies whether you seem to say here is a snippet, and it needs these dependencies Yes I'd still prefer my paradigm (not because of my ego) because it'd be easier to manage redundancies, it applies generically for snippets, comet actors etc. without having to induce other type of API. It is maybe coarse grained vs. your proposal that seems to me finner grained. I think the two can co-exist, although I haven't thought it through wrt comet actors etc. That was what I was hinting at in the previous mail. At the of the day (or before sending a response at least :-) a page needs to have a well-defined list of script files to include. So it makes sense to start with your paradigm and my paradigm should be able to be layered on top if one wishes... However I'd be happy to see an implementation of any of these proposals. Maybe other people would have better ideas so perhaps Peter and/oryou could dig could make this happen? I'll let Peter take the lead and help where ever I can :-) /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: newbie question : get lift to actually run (AbstractMethodError)
On Mon, Mar 1, 2010 at 4:35 PM, ojonam manojo10...@gmail.com wrote: - tried to create a lift blank app with 2.0-snapshot, adapting the archetype:generate command from the book as required Try to show the complete command. Or look in the ML for commands that work with 2.0-SNAPSHOT So I tried two things - type mvn archetype:generate and then follow the command prompts to fill up the different properties (this didn't work) type in the following command directly (it works) mvn archetype:generate -U -DarchetypeGroupId=net.liftweb - DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=1.0 - DremoteRepositories=http://scala-tools.org/repo-releases - DgroupId=demo.helloworld -DartifactId=helloworld -Dversion=2.0- SNAPSHOT You have the wrong archetype version repo. See here: http://wiki.github.com/dpp/liftweb/about-maven-mini-guide /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.
Re: [Lift] MapperRules.nameToDisplayName?
David Pollak feeder.of.the.be...@gmail.com writes: On Mon, Mar 1, 2010 at 8:27 AM, Jim Barrows jim.barr...@gmail.com wrote: On Mon, Mar 1, 2010 at 7:19 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: Hi, In the interest of cutting boilerplate from mapped objects, I would like to get the display name from a property file. So your replacing code boilerplate with property file boilerplate? The boilerplate has to go somewhere, and abstracting things like this out doesn't change that. On the other hand, if you have to l10n your app, then this works. What about turning it off by default, and turned on in Boot though. Also it should probably use the existing method by default, rolling to the property file if it's turned on and it's not provided. Yeah... I gotta say, the less stuff that winds up outside Scala by default, the better. Well, you probably have the luxury of not having to localize your apps. Unfortunately, I don't :-( But I'm interested if you know of better ways to handle i18n for things like displayName. /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.
Re: [Lift] MapperRules.nameToDisplayName?
Jim Barrows jim.barr...@gmail.com writes: On Mon, Mar 1, 2010 at 7:19 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: Hi, In the interest of cutting boilerplate from mapped objects, I would like to get the display name from a property file. So your replacing code boilerplate with property file boilerplate? The boilerplate has to go somewhere, and abstracting things like this out doesn't change that. Yes it does. Now I have to go through all my 100+ fields and add: override def displayName = S.?(getClass.getName+.+name) Same line in every field. That counts as boilerplate for me :-) On the other hand, if you have to l10n your app, then this works. Exactly. What about turning it off by default, and turned on in Boot though. Also it should probably use the existing method by default, rolling to the property file if it's turned on and it's not provided. That was pretty much what I suggested.except I don't want to force people to use displayNameFromPropertyFile. They could provide their own function that looked it up in a db, generated random names etc. /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.
Re: [Lift] reload application.properties
David Pollak feeder.of.the.be...@gmail.com writes: The Props.get stuff is frozen the first time its accessed. This is a philosophical issue for me. The properties should be fixed at start-up time. If there are things to vary, build an administrative interface or some other thingy (e.g., a separate HTTP listener) that allows you to manipulate the mutable configuration. And I agree very much in this philosophywhen we're talking production. I'm interested if you feel the same way about this during development? If so, stop reading as the rest will just be a rant, if not read on :-) I think the static nature of some of Lift's internals is one of the greatest productivity killers when it comes to rapidly start up with a new app where you quickly iterate different ideas (or even do many small changes in an existing app). 1) Change the menu structure? Restart server 2) Change the menu text? Restart server (yes I use properties for text and yes I need an app in different languages, see other thread :-) 3) Change something in a mapped field? Restart server 4) Change a field label? Restart server Using JRebel doesn't really help in these scenarios as the values are fixed at start-up. There are probably others, but these are the ones I can recall. Perhaps I'm being hit harder than others since 1) We need different languages and 2) You need to be logged in to see the app. Or perhaps I just don't develop in an efficient way who knows? It would be really nice for some of this to be picked up automatically when running in development mode. I still remember some time ago when I did a project in PHP. I don't like the PHP language very much, but you can't really beat the instant gratification of a code change: Just reload the page! I think some of these issues could be solved easily, some will require more work and some may be impossible. - Reloading properties if the file has changed should be easy. - Rebooting lift on the fly may not be easy, but perhaps some things could be made reloadable (sitemap?). If you then write a JRebel plugin (not a hard task) that triggers the reload when a class change is detected, you will be one step closer to RAD nirvana. I'm interested to hear if others have the same pain points as me (if not, I don't see this changing soon :-) and if there are some ideas how to remedy this (either by changing Lift or changing my development process :-) /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.
Re: [Lift] Less boilerplate in your specifications / tests
David Pollak feeder.of.the.be...@gmail.com writes: Eric, You're a Lift committer. Feel very encouraged to clean up the tests! But if you do, please have in mind that not all the niceties of Specs are supported very well by IDEs, which may be why some tests are as they are :-( Hopefully that will change when 2.8 comes out (at least for Eclipse it will. The current workaround for running specs is quite horrible) /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.
Re: [Lift] MapperRules.nameToDisplayName?
Jim Barrows jim.barr...@gmail.com writes: My point was that you've moved the boilerplate, not eliminated it. If what you suggest was in place you'd have to add 100+ properties in a file. I'm not sure if we're wandering out on a philosophical tangent here, but would genuinely like to hear if you have better solutions: Given that I have say 100 fields and need it translated to say 5 different languages. I need to have at least 500 words stored somewhere. If I don't want to use a word's position in the file as key, I'll need a key per word. I would also like one file per language since this allows independent translation. So now I have 5 files each with 100 lines containing two words. But AFAIKS, there's no repetition (except for the keys, which I think are unavoidable), so no boilerplate. Now I have to add the 100 overrides to actually look up the translated names. This is the only place I see boilerplate, and it could be easily removed :-) I agree 100% that if you don't need translation, properties are often the wrong approach, but when you do need it I've yet to see a better alternative (but would love to hear about it!) /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.
Re: [Lift] Running parallel site load balanced
John Pletka jple...@abraxis.com writes: I was tasked with designing a new web-based application that has the requirement of being able to run on multiple servers that could be 1) Load balanced without requiring sticky sessions and 2) Single nodes could be transparently shutdown or added without the users noticing I would like to use Lift if possible, but I'm a bit worried about it's state-full nature. Is it possible to use something like Cassandra or Memcached to hold the session data and have Lift grab that from a cookie instead of storing it all internally in memory? Short version: No. Longer version: It's not currently possible and probably hard (but not impossible) to do. But I think (but this is pure speculation) that a Lift session is rather heavy since it contains closures for all the callbacks that have been active within the last 10(?) minutes, the overhead of serializing the session state for each request (which you need for HA) would be substantial. I've looked around, but I have not found any good articles about how to scale Lift horizontally. Probably because it has not been done (without sticky sessions) /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.
Re: [Lift] Running parallel site load balanced
Ahh just saw David beat me to it with the other reply :-) John Pletka jple...@abraxis.com writes: It is a business application - lots of forms, reports, data lookups. I'm not too concerned about the performance on a single node - at any given time we'll probably have a max of 1000 requests a minute coming in which I've seen Lift handle easily. The biggest problem is we need near 100% up-time. But you can have near 100% uptime with sticky sessions. What you can't have is High Availability (HA), ie. users won't notice when a server breaks. That means having at least a second server in hot-standby mode (preferably parallel production), and some way to do upgrades without bringing the whole site offline. Doing rolling upgrades is never easy, even if you don't share state. You may have all this figured, but you need to account for different app versions running simultaneously, expanding/shrinking db upgrades etc. /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.
Re: [Lift] Re: [Lift committers] Lots to do by end of day on Sunday **Important for Committers**
Naftoli Gugenheim naftoli...@gmail.com writes: Would anyone be able to change my open tickets to after M3? I don't think I'l have a chance to deal with them before code slush. I'm not sure but I think they're 257, 258, 370, and 371. Thanks! Moved to M4 /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] New logging code is in master
The new logging code is now in master and should be fully usable. Therefore, the existing logging code has been deprecated. I've added a Wiki article here: http://wiki.github.com/dpp/liftweb/logging-in-lift /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] *** BREAKING CHANGE *** Issue 155: Mapper JSON
The changes mentioned here has been committed to master: http://groups.google.com/group/liftweb/browse_frm/thread/8db6bbb93c16e0f5/e9c3cdce2f011313?lnk=gstq=MappedField.name%2C+affects+Mappe#e9c3cdce2f011313 This means that MappedField.name is no longer lower cased, but preserves the case of the field. This in turn means the JSON representation of the mapped field will change. /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: New logging code is in master
On Sun, Feb 28, 2010 at 5:14 PM, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: The new logging code is now in master and should be fully usable. Therefore, the existing logging code has been deprecated. .although I don't seem to get any deprecation warnings when using eg Log.info Can somebody confirm if the deprecation works? /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.
Re: [Lift] About the url rewrite (more thant one params and get 404 not found error)
Neil.Lv anim...@gmail.com writes: Hi all, I have a silly question about the url rewrite in the lift. It has another two params in the url after the img. http://localhost:8080/show/img/version/id The url works fine. = http://localhost:8080/show/img = http://localhost:8080/show/img/v1/ = http://localhost:8080/show/img/v1/1 Get 404 error if the / string is not added at the end of the url (the id param isn't supplied) = http://localhost:8080/show/img/v1 So, how can i rewrite the url and set the sitemap can make this link ( http://localhost:8080/show/img/v1 ) works fine as ( http://localhost:8080/show/img/v1/ ) when the id is not supplied. Here is the code: ### case RewriteRequest( ParsePath(List(show, img, version, id), _, _,_), _, _) = RewriteResponse(List(show, img), Map(version - version, id - id) ) ### I'm not sure if this can be handled with the standard ParsePath, but it is fairly easy to write your own extractor that can handle more complex scenarios. Here's an example: object ParamsExtractor { def unapply(pp:ParsePath): Option[(Account, OrgUnit)] = { val result:Box[(Account, OrgUnit)] = if (pp.wholePath.startsWith(path) pp.wholePath.length == (path.length + 2)) { val res = Full((XX,YY)) debug(Decoded URL: %s=%s.format(pp,res)) res } else None result } } used like this: case RewriteRequest(ParamsExtractor(account,orgUnit) , _, _) = (RewriteResponse(path), Full(account, orgUnit)) /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] Maven help!
Hi, For the new logging code I need a setup that I can't really see how to achieve with Maven: 1) Both slf4j-log4j and logback-classic needs to be on the classpath when compiling 2) Only sf4j-log4j should be on the classpath when testing 3) None should be included in the generated pom dependencies Using scope=provided takes care of 1) 3) But both are still included in the classpath during test /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] Direct access to response.outputStream?
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? /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.
Re: [Lift] Re: Direct access to response.outputStream?
Marius marius.dan...@gmail.com writes: On Feb 26, 11:50 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, I need to create a response that downloads a file. The file is generated by a 3rd party api that takes an output stream as the target for the file. As the file can be rather large, I would like to stream this file directly to the client. I've looked at StreamingResponse, but this seem to require something akin to an input stream. As there a way to generate a response with direct access to the output stream? No. IMO this would bring serious problems related with committed response if people will start writing directly into servlet's response output stream. Normally, yes. But I think there are special cases that may warrant this and I tend to think this is one of them :-) 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. But unless I create a new thread, I'll still end up with the entire file in memory. Ie the call to the library's write method must return before the streaming response can be created and thus the file contents must be stored somewhere. 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. If I create a new thread I could probably use PipedOutputStream which does this already. But still the file contents will be copied twice: 1) From pipe output to pipe input, 2) from pipe input to response output 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. /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.
Re: [Lift] Re: Direct access to response.outputStream?
On Fri, Feb 26, 2010 at 12:06 PM, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: So the thread creation/scheduling and the two times file copying could be avoided by writing directly to the output stream. But I agree this would have to be special cased somehow. It's not an urgent issue atm, but I'll try to see if some clean solution can be implemented. An idea just struck :-) Could this be handled in much the same way as a redirect? Something like S.sendFile(application/pdf, myfilename.pdf, outputStream = mylibrary.write(outputStream)) this would throw an exception like ResponseShortcutException, lift would intercept it, write the appropriate headers and execute the passed function with the response outputstream as parameter. This would prohibit accidental output to response. Thoughts? /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.
Re: [Lift] Re: Maven help!
On Fri, Feb 26, 2010 at 1:35 PM, Steve Swing steve.sw...@gmail.com wrote: In addition to specifying the scope of test or compile does optionaltrue/optional help with what you want? Yes, I think optional can help with the third point. /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.
Re: [Lift] Re: Direct access to response.outputStream?
On Fri, Feb 26, 2010 at 1:53 PM, Marius marius.dan...@gmail.com wrote: On Feb 26, 1:29 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Fri, Feb 26, 2010 at 12:06 PM, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: So the thread creation/scheduling and the two times file copying could be avoided by writing directly to the output stream. But I agree this would have to be special cased somehow. It's not an urgent issue atm, but I'll try to see if some clean solution can be implemented. An idea just struck :-) Could this be handled in much the same way as a redirect? Something like S.sendFile(application/pdf, myfilename.pdf, outputStream = mylibrary.write(outputStream)) this would throw an exception like ResponseShortcutException, lift would intercept it, write the appropriate headers and execute the passed function with the response outputstream as parameter. This would prohibit accidental output to response. Thoughts? I would prefer something like : final case class OutputStreamingResponse(data: (OutputStream) = Unit, size: Long, headers: List[(String, String)], cookies: List[HTTPCookie], code: Int) extends BasicResponse { .. } hence remain consistent with Lift's response paradigm. We *COULD* provide the OutputStrem from the servlet response but that would be ok since we are in a LiftResponse and NOT inside the rendering pipeline. Agreed, a cleaner solution. And this could also be used outside of a stateful response. The size should probably be Box[Long] as it may be unknown. Should I create a ticket for this? /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.
Re: [Lift] Add lock() to MetaMapper
On Fri, Feb 26, 2010 at 2:10 PM, harryh har...@gmail.com wrote: Sent this to dpp the other day with the idea that it might be a useful addition to MetaMapper. Would others find this useful? (It's a tad PostgreSQL specific in its current form). object LockMode extends Enumeration { type LockMode = Value val AccessShare = Value(ACCESS SHARE) val RowShare = Value(ROW SHARE) val RowExclusive = Value(ROW EXCLUSIVE) val ShareUpdateExclusive = Value(SHARE UPDATE EXCLUSIVE) val Share = Value(SHARE) val ShareRowExclusive = Value(SHARE ROW EXCLUSIVE) val Exclusive = Value(EXCLUSIVE) val AccessExclusive = Value(ACCESS EXCLUSIVE) } import LockMode._ trait Lockable[T : Mapper[T]] extends MetaMapper[T] { self: T = def lock[T](mode: LockMode)(func: = T) = { DB.use(dbDefaultConnectionIdentifier) { conn = DB.statement(conn)(_.execute(LOCK TABLE +dbTableName+ IN +mode.toString+ MODE)) func } } } Looks cool. As you note, this should probably be abstracted for each DbProvider. /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] Matching on Mapper fields
Hi, I would expect the following code to print at most a single line: Vehicle.mappedFields.filter(_.dbIncludeInForm_?) foreach {f = f match { case Vehicle.customCategory = Log.info(Matched on field: +f.name) case _ = } } But what happens is that the following: 15:57:27.917 [tp-1441471922-0] INFO lift - Matched on field: organizationalUnit 15:57:27.918 [tp-1441471922-0] INFO lift - Matched on field: price 15:57:27.918 [tp-1441471922-0] INFO lift - Matched on field: tax 15:57:27.918 [tp-1441471922-0] INFO lift - Matched on field: customCategory 15:57:27.918 [tp-1441471922-0] INFO lift - Matched on field: vehicleType I think what happens is that the equals method of MappedField compares the value of the fields, which is 0 in the above cases. But this doesn't make much sense when it is really the meta fields that are being compared. Is it possible somehow to match on the fields, not the field values? /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.
Re: [Lift] Maven help!
Josh Suereth joshua.suer...@gmail.com writes: including something at compile-time and not test time is a rare thing for maven, which assumes tests also need dependencies used to compile. Of all the scopes you can specify for dependencies *all* of them end up on the testing classpath. (see http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html) I would recommend droping one of your requirements, or giving us some more information on exactly the nature of the problem, so we can better assist your maven usage! I kind of worked around them :-) I wanted to create helpers for both slf4j-log4j and logback-classic in the same project. But at runtime only one of them will actually be present. Having both causes slf4j to (correctly) complain about multiple bindings. Turned out it wasn't really slf4j-log4j I needed at compile time. Log4j will suffice. So only logback-classic will be included as an slf4j binding during tests.. /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.
Re: [Lift] Matching on Mapper fields
On Fri, Feb 26, 2010 at 5:31 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: case _ if f eq ... ? Yeah that works, but then it might be easier to just use an if(f eq ..) /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.
Re: [Lift] Javascript Dependencies
Peter Robinett pe...@bubblefoundry.com writes: Hi all, [...] // Usage in boot.scala val myJsScript = new JsScript(flot :: jquery.flot.selectable.js :: Nil) ResourceServer.allow(myJsScript.allowResource) // Usage in a normal snippet def mySnippet = { head { myJsScript.toHTML } /head div The rest of the snippet... /div } // Usage in a CometActor class myActor extends CometActor with JsScriptDependency { override def scripts = List(new JsScript(flot :: jquery.flot.selectable.js :: Nil)); } What do you think? It's a really quite basic but I think such an approach could work well for things like as lift-flot. It might be a start :-) I'm a little unsure if it supports the use case I would like to see: I'm using jqPlot (a flot-like lib) and would like to, in boot, just initialize the widget: jqPlot.init jqPlot comes with numerous plugins and this should be handled by the widget. Whether a plugin is loaded on a page depends on some higher level structure. Ie. if I wish to draw a pie chart, the pie chart plugin should be loaded. Looking back at this, it seems like this could work with the above In init: register all plugins In the specific charts, call toHtml on the plugins needed /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Logging, part 2
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.
Re: [Lift] Re: This is the style of SQL persistence that I like ...
On Thu, Feb 25, 2010 at 7:36 AM, aw anth...@whitford.com wrote: On Feb 24, 12:47 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: We're currently using Rails migrations and I've been thinking if putting migrations into the app is really the right approach? What happens if migrations fail? It's not easy for the app itself to rollback to the previous version :-) There is obviously a strong relationship between the code and the database, especially when you are adding columns/fields to tables/ classes, so I like managing the code and database together. But as much as I like the DSL approach of Scala-Migrations, I'm sticking with the richness of Liquibase: http://liquibase.org/ Ouch. Much too verbose to my liking :-) What are the features you use that is not available in e.g. Scala migrations? /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.
Re: [Lift] Re: Logging, part 2
On Thu, Feb 25, 2010 at 10:32 AM, Marius marius.dan...@gmail.com wrote: I'd opt in for something like: LiftRules.logger = Log4J Agree this fits the current idioms, but how should this be triggered? The new logging code is in lift-common so cannot call stuff in LiftRules. Note we're not talking about Loggers (objects that have warn info methods) but about configuring the logging system, which needs to be done before Loggers can be used. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Logging, part 2
On Thu, Feb 25, 2010 at 10:53 AM, Timothy Perrett timo...@getintheloop.eu wrote: +1 This fits with the idioms we already have. Although, so Lift doesn't carry a default dependency it would probably need to be: // default LiftRules.logger = NoLogger I'm not sure this is worth it. It's added complexity that adds little value. Ie. why wouldn't you want logging in your lift app? /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.
Re: [Lift] Re: Logging, part 2
On Thu, Feb 25, 2010 at 11:44 AM, Marius marius.dan...@gmail.com wrote: Then perhaps: LiftRules.initLogger(Log4J) I'll buy that :-) /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.
Re: [Lift] Logging, part 2
On Thu, Feb 25, 2010 at 5:35 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 25 February 2010 10:23, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: 2) Initialize the logging backend What needs to be initialized? Loading (dev|prod|default) property file that specifies appenders, log levels etc. Wouldn't auto initialization be nice? Yes, very! But the only way I can see this work is with dynamic classloading and I've heard this doesn't play with OSGi :-) But I'm open to suggestions /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.
Re: [Lift] Re: Logging, part 2
On Thu, Feb 25, 2010 at 7:48 PM, Ross Mellgren dri...@gmail.com wrote: My concern about putting this in LiftRules is that not all applications that could benefit from the new logging support will use webkit, since the logging is in common. Maybe a bridge method in LiftRules to put it in a convenient place, but I think the actual work should be exposed nearby the logging library. Yeah, I've been thinking a little more on this and I think we need a hook in lift-common that can be used for this. The default (in common) should be to do nothing. I liked Heiko's idea of auto-configuration so maybe the default hook (set somewhere before booting Lift) could be to try to autodiscover the logging backend and configure it appropriately. This has to be in lift util/webkit since we need access to the run.mode /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.
Re: [Lift] Signup validation
Adam Warski a...@warski.org writes: Hello, I'm integrating recaptcha into a Lift app that uses MegaProtoUser, and there's one small thing that I think can be improved. There is currently no good place to put the captcha-verifying code. After the signup form is submitted the user if validated using theUser.validate (ProtoUser.scala:386, testSignup method). However I can't put captcha validation into User.validate, as there won't be any captcha when e.g. editing a user. So I would propose adding a method to MetaMegaProtoUser, e.g.: protected def validateSignup(user: User) = user.validate which could be then overridden in concrete user classes. Can't you just override actionAfterSignup and don't call super if captcha check fails? /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.
Re: [Lift] Signup validation
On Wed, Feb 24, 2010 at 6:05 PM, Adam Warski a...@warski.org wrote: Hello, Can't you just override actionAfterSignup and don't call super if captcha check fails? But that already assumes that signup was successfull and in the end redirects to the homepage instead of going back to the singup form. Indeed. Missed the redirect. You can probably workaround by overriding validate on User and looking at the S.params to see if you should check for captchas. But agree that your proposal is cleaner :-) /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.
Re: [Lift] Hooking up custom login logic with ProtoUser's logUserIn and actionsAfterSignup
On Wed, Feb 24, 2010 at 7:21 PM, dave dpdear...@gmail.com wrote: Further investigation leads me to believe that each pathway is either working in a different session or that Lift just doesn't know about my application's session. S.inStatefulScope_? returns true from the Lift pathway and false from my own. I'll keep following this path, but, being a Lift newbie, any pointers or tips to speed me along would be appreciated. What is your own path way? Is it a browser request or a request from another servlet? If the latter, make sure you provide any session cookies/url parameters needed to correctly propagate the container session to lift. This of course is also needed if it's a browser request, but if it's a request within the same web app, this should be handled automatically /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.
Re: [Lift] [urgent] Master is fundamentally broken!!!!!!
On Wed, Feb 24, 2010 at 6:34 PM, Timothy Perrett timo...@getintheloop.eu wrote: Thanks for the follow up David. Probably this highlights some issues with our automated testing though... any ideas on how we could add something to the build cycle to verify stuff like this? The parsers particularly probably could do with some pretty rigours test cases as this is a classic example... on a related note, Heiko just found a strange character encoding bug with 2.8 and XML; having more test cases will help us keep consistency during the porting. Cheers, Tim It could be nice if it was possible to simulate browser request/response cycles. This would allow very high level tests to be made without the need of a running container/browser etc. This is no replacement for unit tests, but is more a lightweight integration test that exercises a big part of the Lift stack /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.
Re: [Lift] [urgent] Master is fundamentally broken!!!!!!
[...] But, this is the exception (both in terms of my behavior and in terms of the results.) It is an event that indicates that our current process works and those that circumvent that process (including me) should wear the cone of shame. Pictures?? :-) /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.
Re: [Lift] Re: This is the style of SQL persistence that I like ...
On Wed, Feb 24, 2010 at 9:38 PM, David Pollak feeder.of.the.be...@gmail.com wrote: I've pinged Max and he's open to integration with Lift... do I have any takers? On Wed, Feb 24, 2010 at 12:34 PM, Timothy Perrett timo...@getintheloop.eu wrote: Interesting - i've not explored that in 2.8... Personally, i've been wanting to get scala-migrations I'm not keen on the migrations view of the world. It's something that's not type-safe (there's nothing that verifies that your model objects have the same schema as the migrations). That's true. We're currently using Rails migrations and I've been thinking if putting migrations into the app is really the right approach? What happens if migrations fail? It's not easy for the app itself to rollback to the previous version :-) /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Problem with mapper exceptions and logging
Hi, It seems that when a mapper exception is thrown and logging is enabled (with DB.addLogFunc) the logging proxy itself throws an error: This is unfortunate since it can lead to different code paths if logging is enabled or not.is this unfixable or should I file a ticket? java.lang.reflect.UndeclaredThrowableException: null at $Proxy0.executeQuery(Unknown Source) at net.liftweb.mapper.PostgreSqlDriver$$anonfun$performInsertWithGenKeys$2.apply(Driver.scala:267) at net.liftweb.mapper.PostgreSqlDriver$$anonfun$performInsertWithGenKeys$2.apply(Driver.scala:265) at net.liftweb.mapper.DB$$anonfun$runPreparedStatement$2.apply(DB.scala:548) at net.liftweb.mapper.DB$$anonfun$runPreparedStatement$2.apply(DB.scala:547) at net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:247) at net.liftweb.util.Helpers$.calcTime(Helpers.scala:34) at net.liftweb.mapper.DB$.runPreparedStatement(DB.scala:546) at net.liftweb.mapper.DB$.prepareStatement(DB.scala:489) at net.liftweb.mapper.PostgreSqlDriver$.performInsertWithGenKeys(Driver.scala:264) at net.liftweb.mapper.DriverType.performInsert(Driver.scala:81) at net.liftweb.mapper.MetaMapper$$anonfun$15.apply(MetaMapper.scala:743) at net.liftweb.mapper.MetaMapper$$anonfun$15.apply(MetaMapper.scala:688) at net.liftweb.mapper.DB$$anonfun$use$1.apply(DB.scala:570) at net.liftweb.util.DynoVar$class.run(ThreadGlobal.scala:95) at net.liftweb.mapper.DB$currentConn$.run(DB.scala:557) at net.liftweb.mapper.DB$.use(DB.scala:567) at net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:687) Caused by: java.lang.reflect.InvocationTargetException: null at sun.reflect.GeneratedMethodAccessor164.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at net.liftweb.mapper.DBLog$LoggedStatementHandler.chain(LoggingStatementWrappers.scala:330) at net.liftweb.mapper.DBLog$LoggedPreparedStatementHandler$$anonfun$invoke$68.apply(LoggingStatementWrappers.scala:394) at net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:247) at net.liftweb.util.Helpers$.calcTime(Helpers.scala:34) at net.liftweb.mapper.DBLog$class.logStatement(LoggingStatementWrappers.scala:53) at net.liftweb.mapper.DBLog$LoggedStatementHandler.logStatement(LoggingStatementWrappers.scala:110) at net.liftweb.mapper.DBLog$LoggedPreparedStatementHandler.invoke(LoggingStatementWrappers.scala:393) ... 269 common frames omitted Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint contracts_unique at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:367) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:271) ... 279 common frames omitted -- 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.
Re: [Lift] LiftRules.jQueryVersion ... :(
+1 (and we might as well add 1.4.2 as well/instead :-) On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote: Guys, This has been added not so long ago, and I am aware that I should express my perspective on this back then as now it might be too late. IMHO LiftRules or other Lift parts except the JsArtifacts and maybe ResourceServer should not even be aware of the underlying JS framework thus the JQuery name in LiftRules is very unsound to me. Here is other proposal of keeping things decoupled: . We currently have JQueryArtifacts which holds the JQuery implementation. We add in the JsArtifacts this: trait JsArtifacts { ... def version } then case class JQueryArtifacts1_3_2 extends JQueryArtifacts { def version = 1.3.2-min } case class JQueryArtifacts1_4_1 extends JQueryArtifacts { def version = 1.4.1-min } Then to select one or another we use the existent mechanism: LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people can change this easily then in ResourceServer we can easily make the version selection. In this way LiftRules has no idea about JQuery, YUI etc and it doesn't need to. it is only about feeding different implementations of JsArtifact. Thoughts? Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group 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.
Re: [Lift] Re: Setting run mode for Lift applications
On Mon, Feb 22, 2010 at 8:48 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Folks, I really do not understand the value of setting the run mode statically via code in LiftRules. The run mode should be set externally, right? In order to use the same artifact (WAR) on a dev or a prod server. Heiko Agreed. This was more so that people could change how externally is defined, ie in a hosted env you can't change system properties. The default would still be the current lookup in system properties, but you could change this to look at servlet params, hostname, day of month etc :-) /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.
Re: [Lift] Re: Cached CSS (and Javascript?) issue
On Sun, Feb 21, 2010 at 9:49 AM, Marius marius.dan...@gmail.com wrote: Guys, I'm starting to have second thoughts about having css or js combine (concatenation of multiple files into a single response) on lift side. I'm starting to question that real benefits as in production sites in many cases the lift app has a http reverse proxy front end that can serve static content js/css etc. Thus combining multiple js/css with simple tools seems more practical. Thoughts? By simple tools I assume you mean at build time? How would this handle classpath resources? 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. 2) The absolute best performance no matter what. 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. 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] unCamelCase,camelCase capify
Hi, I'm finally returning to #155 (support for snake_case in Mapper) and found a few inconsistencies In StringHelpers we have capify commafy (which I don't really understand, but never mind :-) In ClassHelpers we have camelCase camelCaseMethod unCamelCase The methods in ClassHelpers are just string manipulation functions so I think they belong in StringHelpers. Also it seems the naming is a bit inconsistent, with -fying being my preference. So I propose the following ClassHelpers.unCamelCase - StringHelpers.snakify ClassHelpers.camelCase - StringHelpers.camelify ClassHelpers.camelCaseMethod - StringHelpers.camelifyMethod with due deprecation of old methods. capify seems to do almost the same as camelCase, but not quite so probably have to leave it. 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.
Re: [Lift] Re: Setting run mode for Lift applications
On Mon, Feb 22, 2010 at 7:13 PM, David Pollak feeder.of.the.be...@gmail.com wrote: I've closed Jeppe's ticket. Why? WebKit depends on util. Props (where the runmode is defined) is in util, so there would be a circular reference if LiftRules was used to calculate the runmode. Further, util can be used outside of the context of WebKit/Boot. We want to encourage that. Fair point. I keep forgetting about those other uses :-) /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.
Re: [Lift] Welcome John De Goes as a Lift committer
David Pollak feeder.of.the.be...@gmail.com writes: Folks, Please join me in welcoming John De Goes as a Lift committer. John burst onto the Lift scene a week or so ago with some excellent enhancements to the Lift-json stuff and the rest is history. Welcome John... looking forward to excellent contributions from you and your latest partner in crime, Kris Nuttycombe, a long-time Lift committer. Thanks, David Welcome John! /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.
Re: [Lift] Re: Tricky question regarding menus
Heiko Seeberger heiko.seeber...@googlemail.com writes: Hi, Sorry for being pushy, but this one is really urgent. Maybe I did not describe my issue properly, so I will give it another and simpler try: I want a menu to link to a subpage, i.e. have the same link as one of its child menus. But the menu shall also be active for every other active child menu. I have the same scenario and it works for me. In the parent menu I do this: Menu(Loc(parent, List(parent, index), Parent, Loc.EarlyResponse(() = Full(RedirectResponse(/subpage We're using our own menu snippet and I can't recall if this was one of the things we changed :-( /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.
Re: [Lift] Re: Setting run mode for Lift applications
On Sun, Feb 21, 2010 at 2:19 AM, Timothy Perrett timo...@getintheloop.eu wrote: The former is a lift idiom that we use for everything configurable... Lets look into doing that. Jeppe: Are you willing to investigate this / take the lead? Yes. I've created https://www.assembla.com/spaces/liftweb/tickets/362-make-runmode-configurable-in-liftrules /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.
Re: [Lift] Re: Setting run mode for Lift applications
aw anth...@whitford.com writes: On Feb 18, 9:14 am, Petr Pudlak petr@gmail.com wrote: Hi all, I've written my first application using Lift and now I'm deploying it into a production. I find it inconvenient that the run mode is specified as a JVM system property. First, sometimes JVM system properties are inaccessible, for example when deploying to a hosted servlet container. Second, it's impossible to run different lift applications with different run modes in a single servlet container. I have sympathy for your first point, but am suspicious about the second point. I generally don't recommend running applications in different modes/environments on a single servlet container because you run the risk that a destabilizing factor in Dev or QA could impact a Production system, for example. A dev servlet container instance that hosted just dev instances, for example, would make sense, but these would share the same run.mode. Generally, I believe that a *Java web application shouldn't be configured by JVM system properties*. I suggest that the run mode should be configured by a servlet context initialization parameter, called for example lift.run.mode. Or, for maximum flexibility, both alternatives should be provided. Servlet context initialization parameters break down because the servlet configuration is baked into the artifact, yet the goal is to run the same artifact across several environments. (Sure, there are things like the global web.xml, but if you can't access system properties, I don't see how you will change the global web.xml.) Any other ideas? Some servlet containers (eg Jetty, Tomcat) allow a context to override servlet context initialization parameters externally from the war... I'm not sure if this is too late in the boot cycle, but one simple solution would be to have a LiftRules.calculateRunMode /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.
Re: [Lift] Re: Has anyone gotten the uservoice javascript to work?
On Sat, Feb 20, 2010 at 7:36 PM, Marius marius.dan...@gmail.com wrote: In boot try setting LiftRules.useXhtmlMimeType = false; I've had the same issues and iircc it's an issue with the Uservoice script not being fully xhtml compliant even if the problem is marked as fixed... What exactly does one loose by putting useXhtmlMimeType in Boot? /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] Potential breaking change: MappedField.name, affects Mapper JSON
Hi, As part of fixing https://www.assembla.com/spaces/liftweb/tickets/155-lift-mapper-%28record%29-camelcase-to-snake_case-for-case-insensitive-databases , I would like to change the semantics of MappedField.name slightly: Currently, the name is always lowercased, ie: class SampleModel extends KeyedMapper[Long, SampleModel] { object id extends MappedLongIndex(this) object firstName extends MappedString(this, 32) object moose extends MappedNullableLong(this) object notNull extends MappedString(this, 32) } firstName.name == firstname notNull.name == notnull id.name==id I would like to have name preserve the case of the field such that: firstName.name == firstName notNull.name == notNull id.name==id Reasons: 1) More consistent. css styles, default column headers etc based on name now follows the actual field name 2) Easier to implement #155 :-) name is used when serializing a Mapped object as JSON. So the JSON representation will be changed (unless we lowercase the name only when creating JSON, but this goes against 1) Now: { $persisted:true, id:1, firstname:Elwood, moose:null, notnull: } After proposed change: { $persisted:true, id:1, firstName:Elwood, moose:null, notNull: } I would like to get a feel for the pain this will cause people /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.
Re: [Lift] Implementing You are here:
On Thu, Feb 18, 2010 at 3:33 PM, Julian Backes julianbac...@googlemail.com wrote: Hi, I want to implement something like You are here: Root - Somewhere 1 - Somewhere 1.1 which is displayed on all pages. Is it possible to use SiteMap to do that? Can someone give me a hint how to do that? Have a look at the Menu snippet. I think the li_path prefix can be used to make a breadcrumb... /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.
Re: [Lift]
On Wed, Feb 17, 2010 at 3:45 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, Since a week or so I get modified files even when I create a fresh clone of the repo. These are some js and css files from lift-widgets and stuff from installer and references. Anyone else experiencing the same? I guess it could be related to the core.autocrlf configuration for Git. Mine is set to input and I am working on a Mac. I had the same setup and experiences the same thing. I removed the autocrlf setting. From what I understand from the committers list, this should only be added when the repo is in a consistent state, ie. when Indrajit says go :-) /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.
Re: [Lift] setuid
On Wed, Feb 17, 2010 at 3:40 PM, trizk tsr...@gmail.com wrote: When i run mvn -e jetty:run in helloworld, it dies with java.lang.ClassNotFoundException: org.mortbay.setuid.SetUIDServer Has anyone had any success running the Jetty plugin as a non-root user for their Lift web applications? I realize that the Jetty forum would be a good venue for this question, however I am primarily interested in Lift and hope to be more active in this group in the future. Any insight would be greatly appreciated. Not sure what your background is, so this may be obvious to you, but just in case: Maven is primarily a build tool for compiling/testing/assembling etc your application. Not for running it in production. So assuming you want to run your application in production on a server: 1) Install Jetty on the server, preferably by your distro's package management. This should setup everything with the right permissions. 2) Compile the application on your workstation: mvn package. This creates a war file in the target directory 3) Move the war file to Jetty's app directory on the server, in my case /var/lib/jetty6/webapps 4) Restart jetty /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.
Re: [Lift] setuid
On Wed, Feb 17, 2010 at 4:07 PM, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Wed, Feb 17, 2010 at 3:40 PM, trizk tsr...@gmail.com wrote: Ok, just reread your post and saw you want to run Jetty on port 80. I've not tried this,I usually run a frontend (such as nginx) in front. Not sure how the different distros support this ootb. The point about Maven still applies though :-) /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.
Re: [Lift] Context path, proxies Lift
Ok, I think I got this working, at least in a local POC. Tim got the idea to use Jetty's virtual hosting as described here: http://docs.codehaus.org/display/JETTY/Virtual+hosts. This allows each app to be running in the root context within the virtual host. Nginx only sends HTTP/1.0 requests to a backend, but adding the Host: header seems to be interpreted by Jetty even when handling HTTP/1.0 requests. Not sure if this is mandated by the spec though. I still think this is a little more complicated than it has to be. I can see Wicket has had the same issues: http://cwiki.apache.org/WICKET/wicket-behind-a-front-end-proxy.html (See Why this doesn't always work) I think they solve it by either: 1) Always generate relative URLs, or 2) Be able to specify the context used for generated URLs (note this is different from the current LiftRules.calculateContextPath that is used for both incoming and outgoing requests) But it seems I got a solution now, so this is not super urgent (for me :-) Once again, thanks Tim! /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.
Re: [Lift] Context path, proxies Lift
Timothy Perrett timo...@getintheloop.eu writes: Yeah, tbh, i've always worked around the issue using relative urls... but I wasn't sure how much of an issue that was for you (in a big codebase, going around converting links is not something you want to have to do). The problem is not so much in my own code, but in the URIs that is generated by Lift in e.g RedirectReponse. Which is why I think this should be supported somehow. Glad that worked for you Me too :-) /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] Context path, proxies Lift
Hi, I want to setup a single nginx in front of two independent lift apps (see previous thread) but haven't succeeded. What I wan't is this: External url foo.com/index.html goes to jetty: localhost:8080/foo/index.html External url bar.com/index.html goes to jetty: localhost:8080/bar/index.html So, I'm trying to see if I can get the basic jetty setup going before throwing nginx in the mix. Here are my findings: With LiftRules.calculateContextPath = () = Empty: Deploying lift app foo in context foo works fine: ie localhost:8080/foo/index.html gives me the app and the app works with the localhost:8080/foo prefix Not surprisingly, setting LiftRules.calculateContextPath = () = Full(/foo) gives same result as above. Ok, Fine so far. But when nginx is added, a redirect to /index.html should not go to /foo/index.html but to /index.html So I tried: LiftRules.calculateContextPath = () = Full(/) But now, hitting localhost:8080/foo/index.html (simulating a request from nginx), I just get my raw index.html template without any Lift processing as if Lift has ignored the request. Am I misunderstanding the purpose of calculateContextPath? How can I make lift run in a non-root context but at the same time, when generating URLs, not prepend the context path? /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.