Re: [Lift] Serious widget action
Personally, I would say forget ExtJS, compared to Cappuccino its streets behind: http://cappuccino.org/ Easily the most exciting UI framework out there right now Cheers, Tim On 10 Mar 2010, at 03:45, aw wrote: It is time for me to add some serious widgets to my lift app. So far, I am most enamored by ExtJS. Another alternative could possibly be ZK. Does anybody have any experience with these frameworks? Can you comment on why integrating them with Scala/Lift would be a bad idea (or not work)? I searched for some historical posts on ExtJS and discovered some threads about it's license and how it impacts inclusion in the lift framework. Would a commercial license prohibit it from being a lift- widget submodule candidate? Does anybody have a better suggestion that you think can compete with ExtJS? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Serious widget action
The only possible thing that one could do would need two aspects: 1. The lift side to produce particular JSON 2. The capp side to consume said JSON Without a full package, there aren't really any integration points as we have already got comet working with capp so the only thing remaining is overall user implementation experience. Cheers, Tim On 10 Mar 2010, at 09:40, Mads Hartmann Jensen wrote: +1 for cappuccino Played around with it a while back - it's pretty amazing. What kind of intergration are we talking about? I wouldn't mind taking a look at intergrating cappuccino. On 10/03/2010, at 10.37, Indrajit Raychaudhuri wrote: ExtCore is MIT Licensed and a candidate for JSArtifacts impl [1]. I started dabbling with an implementation of ExtCoreArtifacts sometime back, but didn't have enough bandwidth to carry it forward. In case somebody is willing to run with this, there is a ticket for this already [2] Non ExtCore are GPLed and doesn't mix conveniently. Although there are some exceptions, I am not sure how practically that works license wise [3]. Cheers, Indrajit [1] http://www.extjs.com/products/extcore/ [2] http://www.assembla.com/spaces/liftweb/tickets/132 [3] http://www.extjs.com/products/floss-exception.php On Wed, Mar 10, 2010 at 1:55 PM, Marius marius.dan...@gmail.com wrote: Please see here http://groups.google.com/group/liftweb/browse_thread/thread/5e4f5e424d33db40/32cfb6752954?lnk=gstq=ExtJs#32cfb6752954 I'd strongly encourage you to integrate ExtJs with Lift and potentially other frameworks. Depending on JS library licence we'd be happy to have integrations with other JS frameworks. JsArtifacts should provide you the necessary abstractions for such integrations but if you run into problems, please let us know. On Mar 10, 8:27 am, Jim Barrows jim.barr...@gmail.com wrote: On Tue, Mar 9, 2010 at 8:45 PM, aw anth...@whitford.com wrote: It is time for me to add some serious widgets to my lift app. So far, I am most enamored by ExtJS. Another alternative could possibly be ZK. Does anybody have any experience with these frameworks? Can you comment on why integrating them with Scala/Lift would be a bad idea (or not work)? I searched for some historical posts on ExtJS and discovered some threads about it's license and how it impacts inclusion in the lift framework. Would a commercial license prohibit it from being a lift- widget submodule candidate? Does anybody have a better suggestion that you think can compete with ExtJS? I'm using ExtJS in anger at 0rk. 3.1.1 is nice. 3.0.0 is weird. Some odd bugs being reported. We're also getting some weird interactions with some other js libraries ( I won't mention it, it's not available anymore, and if it was it just leave you scarred) and CSS. However, that's the other libraries fault more then ExtJS's. If you want something that looks and feels as close to a desktop app as you can get.. ExtJS can do the job well. With Lift providing the JSON, it would be hard to go wrong. That said.. ExtJS is not an easy beast to learn. It's even worse to try and L10N it easily. I would not try and use just pieces of it, it's really not designed to do that. It seems to me to be an all or nothing approach. That's not say you can't use it piecemeal, I think you lose a lot of flexibility (especially in layout) that way. I wouldn't use it if left to my own devices though, unless I had a requirement for a desktop app on the web. It's serious overkill. -- James A Barrows -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Serious widget action
If you've already decided on ExtJS, why don't you just go use it? Dirk from Ext was originally going to do ExtJS integration, but he has disappeared into the ether never to be seen again. You could always start an integration module on github and go from there... Cheers, Tim On Mar 10, 3:29 pm, aw anth...@whitford.com wrote: On Mar 10, 1:15 am, Timothy Perrett timo...@getintheloop.eu wrote: Personally, I would say forget ExtJS, compared to Cappuccino its streets behind: http://cappuccino.org/ Easily the most exciting UI framework out there right now Perhaps I should add that I need sophisticated grids: http://www.extjs.com/deploy/dev/examples/#sample-3 A bunch of options like JQuery UI, YUI, and from what I see from Cappuccino don't seam to come close to the kind of widget sophistication that I am seeing in ExtJS. Hence, ExtJS is my front runner. (Flex is ultimately competition, but I don't like dealing with Flash.) I have a sprinkling of JQuery usage in my app already, and my initial thought was to simply use the JQuery adapter for ExtJS. Alternatively, I could probably just rewrite my JQuery code in ExtJS -- assuming then I would take the route to provide a jsArtifact for ExtJS. My real concern is factors like security and leveraging things like SHtml.link -- I don't want an oil and water scenario. I still need to deep dive into ExtJS, but wanted to float the idea in case someone was aware of a red flag before I wasted too much time. It doesn't sound like anybody is using ZK [1], eh? [1]http://zkoss.org/ -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
I'm afraid I agree with Marius... I'm just not sure on the benefit
here over JRebel?
Cheers, Tim
Sent from my iPhone
On 9 Mar 2010, at 08:05, Marius marius.dan...@gmail.com wrote:
I'm having seconds thoughts about this. Development mode can mean
slightly different things depending on the nature of the application.
The things you enlisted are for me only PROS for not including this
feature.
Sorry but personally I don't see much value in this approach ... but
this doesn't mean other people wont. Yes JavaRebel is not perfect but
it does its job quite good and it is really helpful in most cases.
On Mar 9, 2:51 am, David Pollak feeder.of.the.be...@gmail.com wrote:
Folks,
I spent today cracking the code on how to implement a more
dynamic Lift
development cycle. Specifically, I figured out how to support
(during
development mode) having changes in compiled code reflected in the
running
application. The change to your Lift app will be a change in how
you do
things in Boot.scala. Basically, anything that could change
between page
loads will be wrapped as such in Boot:
LiftRules.dynamicDevelopmentMode(List(com.liftcode.model,
com.liftcode.lib))(() = {
LiftRules.dispatch.append {...}
LiftRules.setSiteMap()
})
The list is a list of packages to exclude from the dynamic reloading.
Because schemification isn't going to happen on every page reload,
it's best
not to reload the models.
The dynamic mode will impose the following limitations:
- Lift will only service one request at once in development mode
- Page loads in development mode will be 10x-50x slower than in
non-development mode
- Comet objects will not change once they've been instantiated
- There will cases where classes created in one classloader are
not
recognized as the same class for casting and/or pattern matching
purposes if
the classes are created across calls
- There may be problems related to running out of PermGen space
because
each page reload will cause all the applications classes to be
reloaded...
and this may happen faster than the classes are GCed.
With those limitations, do you guys thing the feature would be
valuable?
Should it be part of development mode or should there be another
demarcation
of the dynamic reload mode?
Thanks,
David
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google
Groups Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com
.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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
BTW, with SBT, don't forget you can do: jetty-run (make changes to your code) prepare-webapp That will redeploy chnaged files / classses to the running jetty instance so development with SBT can still be slick without javarebel :-) Lift is really elegant - some how, this approach feels pretty ugly. I haven't looked at it, but no doubt it's using some classloader trickery? Cheers, Tim Sent from my iPhone On 9 Mar 2010, at 10:45, Lukasz Kuczera kuk...@gmail.com wrote: But on the other hand it happens not too often. I'm personally very very happy with current productiveness using Lift + Jetty + JRebel. But what happens when Zeroturnaround will turn back to Scala ? It is quite possible that Scala will go mainstream. It might be viable solution then. Simple solution would be putting Menu building just before page rendering in development mode. But i can live perfectly without that as well (using JRebel). On Mar 9, 9:37 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett timo...@getintheloop.eu wrote: I'm afraid I agree with Marius... I'm just not sure on the benefit here over JRebel? My main pain point was changes to Sitemap. JRebel doesn't help you here as it's fixed once Lift is booted... /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group 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: More dynamic Lift
No it doesn't work for sitemap... as thats loaded at boot only ;-) My point was that it can still be a good experience without JR for our users. Interesting what you were saying about your dev style... i'm usually the other way around and implement sitemap last as I see it as a concrete setting of my content. Cheers, Tim On 9 Mar 2010, at 11:20, Jeppe Nejsum Madsen wrote: 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
Wow, I wish I had 5 machines ;-) lol. Thats an interesting outlook and an explanatory rationale. Can you explain the implementation? Perhaps I can be persuaded. Right now, i'm not convinced about hampering development mode in this way. Cheers, Tim On 9 Mar 2010, at 17:13, David Pollak wrote: So, based on our recent discussion about onboarding, some discussions Jeppe and I have been having, and my non-JRebel-friendly development style, I thought that there might be a way to address all of these issues at once. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Converting a null String to an empty String
how about: def stringTest(x: String): String = Box !! x openOr Cheers, Tim On 9 Mar 2010, at 17:30, Heiko Seeberger wrote: On 9 March 2010 16:48, David Pollak feeder.of.the.be...@gmail.com wrote: Can you be a little more specific? Sure ;-) I am looking for a method like this: def stringNullTest(s: String): String = if (s != null) s else Of course I could roll my own, but if it is already around (e.g. in StringHelpers) I would use it from there. Heiko Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Converting a null String to an empty String
haha!! thanks Heiko... perhaps for my next trick i'll tap out a response using only my nose ;-) Cheers, Tim On 9 Mar 2010, at 18:56, Heiko Seeberger wrote: Looks great, especially for a one-handed-writer ;-) -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: File Download
Is your dispatch defined it boot? It doesnt sound like it is...
Cheers, tim
On 9 Mar 2010, at 21:45, DavidV wrote:
Any thoughts on this? Still trying to get it to work.
Thanks
On Mar 5, 2:56 pm, DavidV david.v.villa...@gmail.com wrote:
I have recreated a number of StreamingResponse methods from both the
Loop link above and the Lift book and I still can't seem to get the
desired effect. I have been able to get a PlainTextResponse to work
by using LiftRules.dispatch in the Boot, like so:
LiftRules.dispatch.prepend {
case Req((analysis :: inprocess :: Nil), _, _) =
() = Full(PlainTextResponse(test))
}
However, I am unable to get any sort of streaming response to work in
the particular snippet which contains the data I would like to use.
Here are some of the methods I've tried:
def textResponse: Box[LiftResponse] = {
println(TEXT RESPONSE)
val ab = text would go here
Full(PlainTextResponse(ab,
(Content-Type - text/plain) :: Nil, 200
))
}
def streamingResponseFile: Box[LiftResponse] = {
println(STREAMING RESPONSE FILE)
val file: File = new File(
C:\\Source\\trunk\\eclipse\\testLift\\src\\main\\webapp\\images\
\ultra.png
)
val length = file.length
val fileInput = new java.io.FileInputStream(file)
Full(StreamingResponse(fileInput,
() = { fileInput.close },
length,
(Content-Type - image/png) :: Nil,
Nil,
200)
)
}
Do I have to make a LiftRules.dispatch function in the Boot in
addition to the StreamingResponse in my snippet?
I am trying to download plain text, but it is variable and dependent
on some parameters and other variables in the particular Snippet
class. Would I have to pass that data into the boot method in order
to get the desired response? I would prefer to handle it entirely in
the snippet itself.
Finally, I'm not really sure how exactly to handle the
Full(StreamingResponse) once I have created it in order to actually
download the data and save it to the client computer. Although I
assume the browser will handle this one I've formatted the Response
correctly and actually have it working.
Thanks again,
David
On Mar 4, 11:13 am, Marius marius.dan...@gmail.com wrote:
If you want todownloadthrough Lift than yes you can use
StreamingResponse, or simply any other LiftResponse (depending on your
mime-type) and use LiftRules.dispatch mechanism. But you could also
let the container to serve thefile. By default Lift is trying to
serve .html, .xhtml, .htm, .xml etc.. You can write your own rules by
setting
LiftRules.liftRequest = {
case req = true // Pattern match whatever you like and return a
Boolean
}
If Lift cannot find a resource for some reason and you want the
container (or subsequent filters) to handle that you can set
LiftRules.passNotFoundToChain = true
On 4 mar., 17:09, DavidV david.v.villa...@gmail.com wrote:
I am also looking todownloadafilefrom the server that is hosting
my Lift web app. There is a very useful fileUpload method in the
SHtml class and I was wondering if there may be something similar for
afiledownload? I was unable to find anything, and searching for
Lift or Scala Liftdownload on Google returns nothing but pages to
downloadthe libraries, plugins or source code. I suppose I could use
the StreamingResponse, but I am already saving thefileI need to the
server and it would be nice to be able todownloadit to any client
computer with the typical Browse button, similar to the upload,
Thanks,
David
On Feb 14, 3:58 pm, Gang wangga...@gmail.com wrote:
Thanks Tim, that's exactly what I'm looking for!
On Feb 14, 11:27 am, Timothy Perrett timo...@getintheloop.eu wrote:
See:
http://blog.getintheloop.eu/2009/3/19/understanding-lift-s-streamingr...
Construct the CSV in memory and just then stuff it into a streaming
response as a byte array.
Cheers, Tim
On 14 Feb 2010, at 16:18, Gang wrote:
Hi,
I have a question and it may not be a pure Lift one. But since I'm
working on a Lift app and this group is the most responsive one I have
seen, might just try it here.
I need todownloaddata from database in CSV format. What is the best
approach within Lift framework? Do I have to write the data on the
server somewhere and then provide user with a link? I have tried to
google scala, lift,filedownload..., but could not come up with
what I'm looking for. Maybe I didn't use the right key words in
search? Thanks in advance!
Brs
Gang
--
You received this message because you are subscribed to the Google
Groups Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.-Hidequotedtext-
- Show quoted text -
--
You received
Re: [Lift] lift-blog - lift based blogging app
http://www.acidbits.org/lift-blog/ gives a 404 error? Cheers, Tim On 8 Mar 2010, at 12:51, Lukasz Kuczera wrote: Hi Folks. I've spawned very simple blog app on lift. This is alpha version and code base is not clean (i'm quite new to scala and lift). You can pull it from github: git://github.com/kukems/lift-blog.git And there is even demo ;) http://www.acidbits.org/lift-blog/ I need your assistance in choosing name for project and licence type. I want it open source, but dunno current most fancy licence on the street. I've you want to join and help me improving drop me an email and i'll give you commit access. If you want to use it just pull out from github customize with taste and deploy on your favorite app server. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Activity
We are currently on version 2.0-M3. Its stable, and production ready... we keep our snapshots very stable and you shouldnt get any problems using it. Cheers, Tim On 7 Mar 2010, at 03:10, Martin wrote: I notice the last production quality release was over a year ago; I do notice there have been much more frequent updates to say the wiki and the work on the 1.1 milestones. It just seems strange that a minor release on such a young project would taking such a long time. This is a completely naive view of what is going on, and this is why i post this query because I want to be disproven so I can feel comfortable suggesting the use of this framework for the long term. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: superficial first impressions from a rails junkie
Business wise, rails / php etc are not even on the same scale as lift. Rails / PHP etc are cheap, easy ways to deploy *sites*. Lift is for building serious *web applications*. there is a distinct difference... and yes, for these reasons no doubt the higher cost of deployment will scare some people off, but personally, im not too worried about that as its not the kind of people we want. That is not to say those people aren't smart and pragmatic, rather, its a case of horses for courses... and Lift quite possibly isn't the weapon of choice for an agency just banging out dynamic sites. If however, you want to build a proper web application, you'll quickly out-grow rails and friends. This is where Lift shines. The issue is not a technological, its a business one - Lift will ultimately be cheaper to maintain, less error-prone, cheaper to scale and a bunch of other good stuff. None of this stuff matters to the person who wants £5.99 hosting, so Lift is totally the wrong tool for them. Your making the mistake of assuming that we want mass-market share. That is not to say we don't want to grow, but it has to be the right type of growth... for the right reasons, and in the right areas. Cheers, Tim On 7 Mar 2010, at 02:09, cageface wrote: I think you're making a common programmer's mistake of assuming the people that value aesthetics aren't capable of making deeper distinctions. The working web programmer that wants to move beyond Rails/Django/PHP has a ton of options right now and is much more likely to pick something that looks polished and ready to use and not like yet another impractical academic exercise. If your intent is to scare people like that away you're probably succeeding but that also means that people like that aren't trying Lift out on little test sites, then bigger sites, then selling it to management and adding to your list of success stories. Who knows, maybe your strategy of growing Lift top-down with the eggheads will pay off. TBH it sounds disturbingly reminiscent of the kind of ivory tower arguments I've heard functional programming apologists make for many years now. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
Firstly, Lift is not Rails. It really bugs me when people are like oh, well rails does XYZ. Its apples and oranges in many respects - especially when you consider the ages of the respective projects... Lift is much, much younger than Rails. Moreover, Lift is a very advanced framework -more so than its competitors- and we are working on distilling the experience for people who new to the ecosystem. We have invested a massive amount of time in Lift over the past 3 years, and yes, we have prioritised features in production systems over the introductory experience for newbies. Personally, I think this will make us more mature when Lift reaches critical mass so in this way its no bad thing... I am currently writing a 500 page book on Lift, and I hope it will fill the vast documentation gap that currently exists in the community. We know its a problem, but don't be naive enough to think that we don't know its a problem - the Lift team has some of the finest engineers and researchers around and a number of us have come from doing all manner of other frameworks and so forth... we understand the issues and rest assured they are being addressed. I am currently collaborating with Mark @ SBT on a processor system that will give us a more flexible getting started system than even Rails or Django. By all means, come here with questions and you will find this group to be very responsive and helpful, but do not come here and automatically assume that you can illuminate to us the errors in our project marketing or experience. Cheers, Tim PS: Who uses PDF?... easily one of the funniest things i've read this year. PDF is the format for electronic document communication. Hundreds of millions of dollars a year are spent on PDF-based technology. On 6 Mar 2010, at 04:43, cageface wrote: Like many other web developers, I abandoned some heavyweight Java web frameworks about 6 years ago for Rails and have been working pretty much exclusively in Rails ever since. However, I've always had a secret lust for functional languages so when I heard about Scala and Lift I decided to take a closer look. My first impression of the community from studying this list and many other blogs, articles etc is that it's a group of smart, dedicated folks that have generously dedicated a lot of time and energy to making Lift a first-class alternative to the more conventional options. However, my first brush with the framework itself has so far left a very different impression. I think one of the reasons Rails caught on so quickly in the beginning was that it was marketed brilliantly. DHH made Rails look so simple, stylish and intuitive that anybody drowning in the bulk and complexity of Java web dev at the time couldn't help but take notice. Lift, in contrast, and particularly for anybody with a prior history in Java, seems very daunting and rough. The following impressions are very much superficial first impressions and may really have no deeper substance than that but I think first impressions count for a lot in this sphere. First, the liftweb.net site is nice. It's a clean, elegant, contemporary design. So far so good. Let's click on getting started. What's this? PDF? Who uses PDF? Nevermind, let's look at the HTML. Gack! This looks like an academic LaTEX conversion from the 90s. Layout and formatting are next to non-existent. This doesn't look like the intro for a simple, ready-to-use tool. Oh well, pushing past the wall of text intro we discover that we need Maven. Alarms are starting to go off in the heads of many Java refugees that remember Maven as the nadir of the XML-situp overabstracted agony that was pre-Rails Java web dev. I imagine many people have signed off by this point. We go download maven and press on to the first actual command we can run, which is an impressively cryptic 8-line mvn invocation that seems to take about 10 minutes to download every single apache and codehaus jar file. When this finally winds down we start the server and take a look at our homely start page and bounce back to the docs. XHTML. Hmmm. Didn't everybody give up on that a few years ago? HTML literals *in* the code? All the snippets we're going to be editing live six levels deep in the project directory structure? This will be fun with emacs/ vim... By this point our enthusiasm is seriously waning but our dreams of an expressive but statically typed platform keep us going on to the next section anyway. We begin with another mvn invocation that mysteriously fails. After futzing with it for a bit and googling around we discover that there are spaces following each of the \ line continuations so we copy and paste the whole thing into a file, clean it up, and invoke it via sh. After this finishes we create the first model, which actually looks pretty reasonable, similar to a Django model with a little more boilerplate but nothing too intimidating. We discover to our chagrin
[Lift] Re: superficial first impressions from a rails junkie
Okay... sorry... but this is a gratuitous swipe. Ugly == Not Easy to Use. Nope. Sorry. I don't buy this. Maven commands that wont copy and paste correctly == Not Easy To Use. Im not sure it is difficult to copy and paste: mvn archetype:generate -DarchetypeCatalog=http://scala-tools.org/ Its one line... easy. Im not saying maven does not suck, but this is one the wiki home page people... I don't see a how to use SBT or how to make Maven suck less page in the wiki, can I write one? The wiki is completely open. Yes. yet the examples and the lift book (and to a certain extent the design of lift itself) encourage putting markup in snippet code. Show people how to do it the right way. Disagree. The archetypes use bind these days so im not sure how we are promoting use of HTML literals. Personally, I always always use bind. Cheeers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Wow... Lift has some amazing stats
w00t!! Go team - maybe one of these years we'll have a team meet ;-) Cheers, Tim On 5 Mar 2010, at 17:46, David Pollak wrote: Folks, I just looked at Lift's stats on ohloh. ( http://www.ohloh.net/p/liftweb ) A couple of key items: Very large, active development team Over the past twelve months, 33 developers contributed new code to Lift. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 45 developers have contributed. Increasing year-over-year development activity Over the last twelve months, Lift has seen a substantial increase in activity. This is probably good sign that interest in this project is rising, and that the open source community has embraced this project. Ohloh makes this determination by comparing total number of commits made by all developers during the most recent twelve months with the same figure for the twelve months before that. The number of developers and total lines of code are not considered. So, a big thanks to the community for driving Lift and another big thanks to the Lift committers for adding so much to Lift! Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] BSON support in lift-json
Probably a sub-ordinate module would be preferable... one that builds on the lift-json stuff and doesn't pollute the normal JSON usage. Joni, what are your thoughts? Cheers, Tim On 5 Mar 2010, at 17:59, Tim Nelson wrote: I finally had the opportunity to look into the couchdb code and I must say it is rather impressive. I would like to utilize the code in JSONRecord.scala in scamongo [1]. However, MongoDB uses a variation of JSON they call BSON, which they actually just published a spec [2] for, due to interest outside of MongoDB. Basically, it adds support for date, ObjectId [3], binary data, regular expressions, and code (JavaScript) data types. My question is, what would it take to add support to lift-json for these other data types? Is this even feasible? Thanks, Tim [1] http://github.com/eltimn/scamongo [2] http://bsonspec.org/ [3] http://www.mongodb.org/display/DOCS/Object+IDs -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Wow... Lift has some amazing stats
Me too Marius... what the team has achieved is absolutely amazing. Without a shadow of a doubt being part of this amazing team has changed my life and im very, very proud to be a part of it. Long may it continue :-) Cheers, Tim On 5 Mar 2010, at 18:15, Marius wrote: I'm sooo proud being a little part of it ;) On 5 mar., 19:46, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, I just looked at Lift's stats on ohloh. (http://www.ohloh.net/p/liftweb) A couple of key items: Very large, active development team Over the past twelve months, 33 developershttp://www.ohloh.net/p/liftweb/contributorscontributed new code to Lift http://www.ohloh.net/p/liftweb. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 45 developers have contributed. Increasing year-over-year development activity Over the last twelve months, Lift http://www.ohloh.net/p/liftweb has seen a substantial increase in activity. This is probably good sign that interest in this project is rising, and that the open source community has embraced this project. Ohloh makes this determination by comparing total number of commits made by all developers during the most recent twelve months with the same figure for the twelve months before that. The number of developers and total lines of code are not considered. So, a big thanks to the community for driving Lift and another big thanks to the Lift committers for adding so much to Lift! Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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 security vulnerability
Agreed - it works fine even with double byte characters... Cheers, Tim On 5 Mar 2010, at 18:41, David Pollak wrote: I don't know what you mean by pasting binary characters -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: LiftRules.rewrite, 404 error
Why do you have // in the URL?
Cheers, Tim
On 4 Mar 2010, at 13:34, Gang wrote:
Could somebody answer my question? If it's too stupid a question to
answer, please let me know that too. It just seems to me that unless
I add a link to SiteMap, the links(a tag) in my page just return
404. And I tried following URL rewrite without adding link to
SiteMap, still 404 error.
Thanks
On Feb 28, 6:20 pm, Gang wangga...@gmail.com wrote:
All,
I have this rewrite returning 404 error. Here are what I did:
URL: ../app-context-path//images/CBDU-1098-BCV?F1115261516749FQD=_
Template: src/main/webapp/viewImages.html
LiftRules.rewrite.append( {
case RewriteRequest(ParsePath(images :: sku :: Nil, _, _,_),
_, _) =
RewriteResponse(viewImages :: Nil, Map(imageId -
sku))
} )
Are there any other settings I need to set? I have looked around but
couldn't find any other than the basics listed above. Thanks in
advance!
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: Response Optimizations too aggressive
This really needs to go on the wiki! gold!
Cheers, Tim
On 4 Mar 2010, at 17:50, David Pollak wrote:
On Thu, Mar 4, 2010 at 9:27 AM, aw anth...@whitford.com wrote:
On Mar 4, 6:56 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
How about
LiftRules.stripComments.default.set( () = !Req.isIE)
etc.?
This is where Lift's FactoryMaker shines. You can modify the behavior of
stripComments on a request-by-request basis. You can have a snippet called
from your default template that tests the request and does:
LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)
But, as you point out, that means that CometActors will not get the right
settings... so you can set the rule on a session-by-session basis:
LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)
If that's not enough, you could also do the following in Boot.scala:
object shouldStripComments extends SessionVar(S.request.map(!_.isIE) openOr
false)
S.addAround(List(new LoanWrapper {
def apply[T](f: = T): T =
LiftRules.stripComments.doWith(shouldStripComments.is)(f)
}))
The above code wraps each request with access to the shouldStripComments
Session Variable.
The above vomit of different options is more for the benefit of those that
are confused by FactoryMaker and why it seems so complex... it's because it
offers a ton of different flexibility.
Thanks,
David
Well, this doesn't quite work because I need a Req class instance, not
just the static object.
Also, to me, this determination is really at the Session level rather
than the Request level as I don't expect it to change. But of course
I don't have a Session.isIE field... What about Comet responses? I
have no Request in that scenario, but is it using the same code to
produce the xhtml?
I see that the Factory trait has a session-specific Maker and a
request-specific Maker, but it is unclear to me how I can get that
context. I require more guidance.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: Response Optimizations too aggressive
Personally, I don't like this API. nearly everyone has problems with it as its totally not obvious. Perhaps i'll add some more comments to the definition. Cheers, Tim On 4 Mar 2010, at 08:50, aw wrote: OK, I have disabled the stripping of comments: LiftRules.stripComments.default.set( () = false ) It seems to work for me. On Mar 4, 12:36 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: aw anth...@whitford.com writes: !--[if IE 6] script type=text/javascript id=ie6fix ... / script ![endif]-- 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 Obviously, it would be great to make the stripComments variable session specific where I could leverage something like isIE. I do see that FactoryMaker seems to have a session and request specific vending concept, so this looks promising. I think the code that actually does the comment stripping is in LiftMerge, so I'm thinking that that would need to be enriched too. Ideally, I would like to see comments that are not IE specific to be stripped. (I am unfamiliar with AdWords and how they use comments.) Sound like a ticket? Thanks everybody for the quick help! -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Transactions with Mapper
Probally worth sticking this on the wiki
Cheers, Tim
Sent from my iPhone
On 2 Mar 2010, at 14:37, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
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
.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: The role of LiftRules
That reminds me - we need to clean up the FactoryMaker API Cheers, Tim Sent from my iPhone On 26 Feb 2010, at 09:05, Marius marius.dan...@gmail.com wrote: Well you summarized pretty well what I feel about this. Essentially the way I see it startup configuration things could exists in other classes/objects but should be accessible through LiftRules. A little off-topic ... I'm not at all a FactoryMaker-s fan :p Br's, Marius On Feb 26, 5:01 am, Naftoli Gugenheim naftoli...@gmail.com wrote: Hi, I'd like to get some opinions on the following. You may want to readhttp://reviewboard.liftweb.net/r/158/. I have on Review Board a patch for some date-and-time parsing and formatting configuration. I put the settings inside a singleton object called ConversionRules. The question is, where do these configurations belong? Marius feels that LiftRules is the place where people look for all Lift-related configuration. So that the LiftRules code shouldn't become too monstrous, it makes sense to put the code in ConversionRules and have a val in LiftRules pointing to ConversionRules. My opinion is that LiftRules is, at least for the most part, http- (lift-webkit) related, and should be that way. I would actually prefer to ConversionRules in lift-util, but it relies on Factory which is in webkit. Preferably Factory could be moved to lift-util and ConversionRules with it. Now I suppose pointing LiftRules to ConversionRules is possible even if the latter is moved to lift-util, so I guess it really boils down to whether it would be beneficial for ConversionRules to be presented as side by side with LiftRules, or as a member of it. (If the latter, I suppose ConversionRules could be made private[liftweb] so there's only one path to it...) Thoughts? Thanks! -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en . -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Documenting the source code / supplementing the API docs
Stuart, You can still contribute to the wiki and of your findings or musings - that is totally open. Cheers, Tim On Feb 26, 9:59 am, Stuart Roebuck stuart.roeb...@gmail.com wrote: I've spoken to David off- list and unfortunately I am not comfortable signing the particular IP assignment contract I was sent as it appears to me (but not to David) to be ambiguous in whether it covers what I commit or also any other code I am working on in connection with Lift (e.g. the code of my business). I have offered to alter the wording but David has made it clear that he will not move on the wording of this and, as a lawyer, that it he knows what he is talking about better than I do. Having previously contributed to Apache Ant, Apache Cocoon and Apache James as well as making various minor contributions and bug fixes to other open source projects I have never had a problem in the past with the wording of such agreements with open source projects and would happily of signed the type of agreement currently used by Apache. (http://www.apache.org/licenses/icla.pdf) Unfortunately it looks like my attempt to contribute some documentation is at a dead end! Looking at the contract it is also clear that no other existing commiter may take my code or documentation and commit it, so thank you Ross for your offer, but it looks like that will not be possible. As I have said to David - I really don't think that it should be so hard to accept contributions to this project. Stuart. As this contract is the one signed by all other commiters to the project, I am On Feb 23, 3:22 am, David Pollak feeder.of.the.be...@gmail.com wrote: The easiest thing is if Stuart signs an IP assignment, becomes a full-fledged committer and thus we keep the IP clean. Stuart, if you're interested in learning more, please contact me off-list. In terms of the documentation standards, I'm okay with anything that the rest of you-all want. I'm neither the best producer or consumer of docs, so my voice is a small one on this issue, other than to give hearty thanks to those who write documentation. On Mon, Feb 22, 2010 at 1:05 PM, Stuart Roebuck stuart.roeb...@gmail.comwrote: Great... okay, I’d better do some writing :-) In the absence of a decision I’ll try to minimise special coding in comments but use Scaladoc 2 standard if necessary rather than HTML as that makes it future proof but still readable for both. Stuart On 22 Feb 2010, at 17:32, Ross Mellgren wrote: I will do this, and give feed back if it ever becomes too much load. -Ross On Feb 22, 2010, at 12:05 PM, Timothy Perrett wrote: We are interested in the contribution of course... I think the issue is mostly about how we take patches for this. Someone on the team would need to own this and merge your documentation changes into the master (provided DPP has no objections to this - seeing as its documentation I doubt he has) Any takers from the team? Cheers, Tim On 22 Feb 2010, at 16:14, Stuart Roebuck wrote: Sorry for the slow response—was away for a family weekend! I have limited knowledge of Lift internals… However, my view is that it is often easier to document code when you don't know it well than when you do, because you soon loose interest in documenting things that are obvious to you. What I hope to do is document the things that I need to know as I go along on the basis that many of these things will also be important to others. It's an agile rather than systematic approach if you see what I mean. I have no ego issues here. It's just a small way of giving to the community in a win-win kind of way. If my contributions don't seem helpful to anyone else then folk can say and I'm not going to disappear in a torrent of abuse :-) Similarly, I'm not proposing some big project here. I'm talking about a drip-drip of updates as I spot things that need documenting—I've got plenty other stuff on my plate right now as I'm launching a company based on a Lift based product in mid-year. Enough said… How do we resolve the documentation standard issue? (Scala 2.8 Scaladoc2 or prior) David? Stuart. On Feb 19, 4:11 pm, Timothy Perrett timo...@getintheloop.eu wrote: This could work - although, some parts of lift are very non-trivial and require good knowledge of lift internals. Do you have such knowledge or are you just hoping to contribute where you can with helpful information? Both are good, just trying to establish what you had in mind. Lift-util probably has the best docs at the moment, so if we could emulate that it would be good. Cheers, Tim On 19 Feb 2010, at 15:56, Ross Mellgren wrote: If you can get an established standard on what the content and format should be, I can work with you reviewing the patches and applying them. But, need
Re: [Lift] Re: Logging, part 2
+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 Or something... Cheers, Tim On 25 Feb 2010, at 09:32, Marius wrote: I'd opt in for something like: LiftRules.logger = Log4J or LiftRule.logger = MyOwnLogger Br's, Marius On Feb 25, 11:23 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, I'm about to start sprinkling the new logging code over some of Lift's internals. But first, the logging backend needs configuring. When the dust has settled and the new logging code is fully implemented, this needs to happen in a client app: 1) Choose a logging backend and add the dependency (ie slf4j-log4j or logback-classic) 2) Initialize the logging backend For step 2) I was thinking of some simple helpers that configures the logging backend using lift's properties: Log4j.configure Logback.configure Very simple, so I don't think there is a need to specify a setup function in either LogBoot or LiftRules. But opinions wanted! The current logging code will be deprecated and until removed, the following will happen: 1) slf4j-log4j will be added as dependency to lift-util 2) The current LogBoot.loggerSetup will call Log4j.configure Thoughts? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] [urgent] Master is fundamentally broken!!!!!!
Guys,
I see DPP made a bunch of commits last night. Something in there has
fundamentally broken the markup parser. Yesterday I deploy an
application to production and today I go to update a small bit of copy
that marketing want changed and i'm finding that my application is
broken
With LiftRules.useXhtmlMimeType = false in Boot, I see the following:
script type=text/javascript
// lt;![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page = quot;F1075228527421HHAquot;;
// ]]gt;
/script
This is obviously problematic and all my javascript in my application
is now doing this. Sorry to be grizzly about this, but its totally
untenable for me to be building apps that work one day and are broken
the next... I tried reverting to 2.0-M2, but that was giving me errors
about not being able to boot SessionMaster. If we are changing stuff
in the core of Lift, we need a good number of eyes (that is, people
who are ACTIVE committers) on the changes in review board otherwise
stuff like this happens (certainly, I don't remember getting review
requests for any of these changes that are now causing me
problems...)
I have to get this fixed today otherwise im going to be seriously
flamed.
A very unhappy Tim.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Master is fundamentally broken!!!!!!
Scratch that, it just does this all the time - irrelevant of the mime
type.
Reproduce this by making a blank lift app and looking at the source.
Cheers, Tim
On Feb 24, 11:14 am, Timothy Perrett timo...@getintheloop.eu wrote:
Guys,
I see DPP made a bunch of commits last night. Something in there has
fundamentally broken the markup parser. Yesterday I deploy an
application to production and today I go to update a small bit of copy
that marketing want changed and i'm finding that my application is
broken
With LiftRules.useXhtmlMimeType = false in Boot, I see the following:
script type=text/javascript
// lt;![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page = quot;F1075228527421HHAquot;;
// ]]gt;
/script
This is obviously problematic and all my javascript in my application
is now doing this. Sorry to be grizzly about this, but its totally
untenable for me to be building apps that work one day and are broken
the next... I tried reverting to 2.0-M2, but that was giving me errors
about not being able to boot SessionMaster. If we are changing stuff
in the core of Lift, we need a good number of eyes (that is, people
who are ACTIVE committers) on the changes in review board otherwise
stuff like this happens (certainly, I don't remember getting review
requests for any of these changes that are now causing me
problems...)
I have to get this fixed today otherwise im going to be seriously
flamed.
A very unhappy Tim.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Master is fundamentally broken!!!!!!
I can verify that the issue causing this is:
703a728af05fddda0f8c5e302cce21a9dc065b54
Can we please back this change out as this is affecting ALL lift
applications
Cheers, Tim
On Feb 24, 1:09 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Scratch that, it just does this all the time - irrelevant of the mime
type.
Reproduce this by making a blank lift app and looking at the source.
Cheers, Tim
On Feb 24, 11:14 am, Timothy Perrett timo...@getintheloop.eu wrote:
Guys,
I see DPP made a bunch of commits last night. Something in there has
fundamentally broken the markup parser. Yesterday I deploy an
application to production and today I go to update a small bit of copy
that marketing want changed and i'm finding that my application is
broken
With LiftRules.useXhtmlMimeType = false in Boot, I see the following:
script type=text/javascript
// lt;![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page = quot;F1075228527421HHAquot;;
// ]]gt;
/script
This is obviously problematic and all my javascript in my application
is now doing this. Sorry to be grizzly about this, but its totally
untenable for me to be building apps that work one day and are broken
the next... I tried reverting to 2.0-M2, but that was giving me errors
about not being able to boot SessionMaster. If we are changing stuff
in the core of Lift, we need a good number of eyes (that is, people
who are ACTIVE committers) on the changes in review board otherwise
stuff like this happens (certainly, I don't remember getting review
requests for any of these changes that are now causing me
problems...)
I have to get this fixed today otherwise im going to be seriously
flamed.
A very unhappy Tim.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Master is fundamentally broken!!!!!!
Yeah I already fixed it locally to work around the issue; thanks for
pushing. Was going to do it anyway after lunch.
Do you know who reviewed this? I can't find any reference to it
Sent from my iPhone
On 24 Feb 2010, at 13:51, Indrajit Raychaudhuri indraj...@gmail.com
wrote:
Done in master. Wait for Hudson to respin.
Committers, sorry for direct commit to master and breaking the rule
but Tim's need was urgent.
Have done quick smoke test locally.
- Indrajit
On 24/02/10 6:56 PM, Timothy Perrett wrote:
I can verify that the issue causing this is:
703a728af05fddda0f8c5e302cce21a9dc065b54
Can we please back this change out as this is affecting ALL lift
applications
Cheers, Tim
On Feb 24, 1:09 pm, Timothy Perretttimo...@getintheloop.eu wrote:
Scratch that, it just does this all the time - irrelevant of the
mime
type.
Reproduce this by making a blank lift app and looking at the source.
Cheers, Tim
On Feb 24, 11:14 am, Timothy Perretttimo...@getintheloop.eu
wrote:
Guys,
I see DPP made a bunch of commits last night. Something in there
has
fundamentally broken the markup parser. Yesterday I deploy an
application to production and today I go to update a small bit of
copy
that marketing want changed and i'm finding that my application is
broken
With LiftRules.useXhtmlMimeType = false in Boot, I see the
following:
script type=text/javascript
//lt;![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page =quot;F1075228527421HHAquot;;
// ]]gt;
/script
This is obviously problematic and all my javascript in my
application
is now doing this. Sorry to be grizzly about this, but its totally
untenable for me to be building apps that work one day and are
broken
the next... I tried reverting to 2.0-M2, but that was giving me
errors
about not being able to boot SessionMaster. If we are changing
stuff
in the core of Lift, we need a good number of eyes (that is, people
who are ACTIVE committers) on the changes in review board otherwise
stuff like this happens (certainly, I don't remember getting review
requests for any of these changes that are now causing me
problems...)
I have to get this fixed today otherwise im going to be seriously
flamed.
A very unhappy Tim.
--
You received this message because you are subscribed to the Google
Groups Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com
.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: Master is fundamentally broken!!!!!!
To clarify, im wondering who reviewed this on RB and gave it a ship
it? A simple test would have shown it to be broken ;-)
Cheers, Tim
PS: thanks Indrajit for your concern :-)
On Feb 24, 1:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Yeah I already fixed it locally to work around the issue; thanks for
pushing. Was going to do it anyway after lunch.
Do you know who reviewed this? I can't find any reference to it
Sent from my iPhone
On 24 Feb 2010, at 13:51, Indrajit Raychaudhuri indraj...@gmail.com
wrote:
Done in master. Wait for Hudson to respin.
Committers, sorry for direct commit to master and breaking the rule
but Tim's need was urgent.
Have done quick smoke test locally.
- Indrajit
On 24/02/10 6:56 PM, Timothy Perrett wrote:
I can verify that the issue causing this is:
703a728af05fddda0f8c5e302cce21a9dc065b54
Can we please back this change out as this is affecting ALL lift
applications
Cheers, Tim
On Feb 24, 1:09 pm, Timothy Perretttimo...@getintheloop.eu wrote:
Scratch that, it just does this all the time - irrelevant of the
mime
type.
Reproduce this by making a blank lift app and looking at the source.
Cheers, Tim
On Feb 24, 11:14 am, Timothy Perretttimo...@getintheloop.eu
wrote:
Guys,
I see DPP made a bunch of commits last night. Something in there
has
fundamentally broken the markup parser. Yesterday I deploy an
application to production and today I go to update a small bit of
copy
that marketing want changed and i'm finding that my application is
broken
With LiftRules.useXhtmlMimeType = false in Boot, I see the
following:
script type=text/javascript
//lt;![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page =quot;F1075228527421HHAquot;;
// ]]gt;
/script
This is obviously problematic and all my javascript in my
application
is now doing this. Sorry to be grizzly about this, but its totally
untenable for me to be building apps that work one day and are
broken
the next... I tried reverting to 2.0-M2, but that was giving me
errors
about not being able to boot SessionMaster. If we are changing
stuff
in the core of Lift, we need a good number of eyes (that is, people
who are ACTIVE committers) on the changes in review board otherwise
stuff like this happens (certainly, I don't remember getting review
requests for any of these changes that are now causing me
problems...)
I have to get this fixed today otherwise im going to be seriously
flamed.
A very unhappy Tim.
--
You received this message because you are subscribed to the Google
Groups Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en
.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [urgent] Master is fundamentally broken!!!!!!
Good point Ross - I always forget about Nexus :-)
Im much less grumpy now everything is good again. Appreciate I spammed
the list a little earlier, so sorry about that. Hopefully a brief post-
mortem will help us identify any failings in our process if they are
present. Accidents happen, I know that, and review board isnt full-
proof by any means... rather, perhaps we can just review the processes
we have in place and make sure that we are all adhering to them in a
team effort to avoid these kinds of things happening in the future.
Cheers, Tim
On Feb 24, 3:07 pm, Ross Mellgren dri...@gmail.com wrote:
Tim, you can also pin to certain snapshot dates I believe (-SNAPSHOT versions
are actually -MMDDHHMMSS), if something in the future breaks you.
-Ross
On Feb 24, 2010, at 6:14 AM, Timothy Perrett wrote:
Guys,
I see DPP made a bunch of commits last night. Something in there has
fundamentally broken the markup parser. Yesterday I deploy an
application to production and today I go to update a small bit of copy
that marketing want changed and i'm finding that my application is
broken
With LiftRules.useXhtmlMimeType = false in Boot, I see the following:
script type=text/javascript
// lt;![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page = quot;F1075228527421HHAquot;;
// ]]gt;
/script
This is obviously problematic and all my javascript in my application
is now doing this. Sorry to be grizzly about this, but its totally
untenable for me to be building apps that work one day and are broken
the next... I tried reverting to 2.0-M2, but that was giving me errors
about not being able to boot SessionMaster. If we are changing stuff
in the core of Lift, we need a good number of eyes (that is, people
who are ACTIVE committers) on the changes in review board otherwise
stuff like this happens (certainly, I don't remember getting review
requests for any of these changes that are now causing me
problems...)
I have to get this fixed today otherwise im going to be seriously
flamed.
A very unhappy Tim.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] [urgent] Master is fundamentally broken!!!!!!
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
On 24 Feb 2010, at 17:05, David Pollak wrote:
Tim,
Sorry. I was chasing a use case where control characters can still make it
into the XML output. Turns out that the Scala compiler converts
b{expression}/b into an Atom, not into a Text() element. Because of
this, it was possible for control characters to sneak into output.
I went around our review board rules after testing the fix on a simple app
(one, it turns out that didn't include a script.)
I will be more careful with stuff that could break all things in the future.
Thanks,
David
PS -- Thanks Indrajit for reversing the commit.
On Wed, Feb 24, 2010 at 3:14 AM, Timothy Perrett timo...@getintheloop.eu
wrote:
Guys,
I see DPP made a bunch of commits last night. Something in there has
fundamentally broken the markup parser. Yesterday I deploy an
application to production and today I go to update a small bit of copy
that marketing want changed and i'm finding that my application is
broken
With LiftRules.useXhtmlMimeType = false in Boot, I see the following:
script type=text/javascript
// lt;![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page = quot;F1075228527421HHAquot;;
// ]]gt;
/script
This is obviously problematic and all my javascript in my application
is now doing this. Sorry to be grizzly about this, but its totally
untenable for me to be building apps that work one day and are broken
the next... I tried reverting to 2.0-M2, but that was giving me errors
about not being able to boot SessionMaster. If we are changing stuff
in the core of Lift, we need a good number of eyes (that is, people
who are ACTIVE committers) on the changes in review board otherwise
stuff like this happens (certainly, I don't remember getting review
requests for any of these changes that are now causing me
problems...)
I have to get this fixed today otherwise im going to be seriously
flamed.
A very unhappy Tim.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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] [urgent] Master is fundamentally broken!!!!!!
Right - I just want to add to what David wrote below: To clarify, yes, I moaned and bitched about this today because it was causing me immediate hassle and heat from other people in my workplace. However, Lift on the whole is vastly more stable than any codebase i've ever worked with (commercial or otherwise) - for that very reason I deploy from master without issue. 98% of the time, having this issue fixed in under 12 hours would be more than perfect, it was just the case in this instance that I needed it done like yesterday ;-) In no way should people read this thread and think that Lift is unstable. Its not. Period. Lift has an awesome community and is a rockin' product. Cheers, Tim On 24 Feb 2010, at 18:51, David Pollak wrote: Just to be clear, the Lift team has a particularly stellar record of keeping the master development branch stable. In the instant case, the master branch was unstable for about 10 hours. The last time the master branch was not stable was more than 60 days ago and the instability in that case also lasted for 12 hours. I deploy most of my projects against master... as apparently does Tim. I have not participated in a project, commercial or open source, where the main development branch (call it master, head, edge, etc.) has been as stable as it is in Lift. So, I don't think we need additional QA. I think the existing processes work just fine. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] This is the style of SQL persistence that I like ...
Agreed - its nice. The var's are a little unsettling though... shame there is not a way to make it more immutable. Cheers, Tim On 24 Feb 2010, at 17:35, David Pollak wrote: Yeah. It's good stuff. Would love to see it integrated with Mapper/Record (so it's not looking at var fields, but looking at the more complex objects that represent fields). On Wed, Feb 24, 2010 at 9:33 AM, Marius marius.dan...@gmail.com wrote: Maybe most of you have seen it: http://max-l.github.com/Squeryl/ Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] [urgent] Master is fundamentally broken!!!!!!
The mental image of you wearing a traffic cone on your head is a pleasing one David :-D Cheers, Tim On 24 Feb 2010, at 20:20, David Pollak wrote: and those that circumvent that process (including me) should wear the cone of shame. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: This is the style of SQL persistence that I like ...
Interesting - i've not explored that in 2.8... Personally, i've been wanting to get scala-migrations integrated into the lift dev process for ages... this SQL project might be a great bed- fellow for it. 2.8 is becoming more attractive by the day... Cheers, Tim On Feb 24, 8:29 pm, Jim Barrows jim.barr...@gmail.com wrote: On Wed, Feb 24, 2010 at 1:27 PM, Timothy Perrett timo...@getintheloop.euwrote: Agreed - its nice. The var's are a little unsettling though... shame there is not a way to make it more immutable. Wouldn't the new copy functionality of case classes in 2.8 take care of that? I've been drooling over this and the migrations project combined since marius posted this. Very cool stuff. Cheers, Tim On 24 Feb 2010, at 17:35, David Pollak wrote: Yeah. It's good stuff. Would love to see it integrated with Mapper/Record (so it's not looking at var fields, but looking at the more complex objects that represent fields). On Wed, Feb 24, 2010 at 9:33 AM, Marius marius.dan...@gmail.com wrote: Maybe most of you have seen it: http://max-l.github.com/Squeryl/ Br's, Marius -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- James A Barrows -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: This is the style of SQL persistence that I like ...
Whilst I totally take that argument, more often than not I find migrations can be a useful aid. Cheers, Tim On 24 Feb 2010, at 20:47, Jeppe Nejsum Madsen wrote: 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 :-) -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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!!!!!!
Ross, if the coding doesn't work out for you, turn to marketing... The cone of process: that my friend, is genius. Thou who broke master must where thy cone on ye head until master be corrected! Cheers, Tim On 24 Feb 2010, at 22:32, Ross Mellgren wrote: Wow, that is amazing. Now we know what the cone of (process) shame looks like! -Ross On Feb 24, 2010, at 3:36 PM, David Pollak wrote: On Wed, Feb 24, 2010 at 12:29 PM, Timothy Perrett timo...@getintheloop.eu wrote: The mental image of you wearing a traffic cone on your head is a pleasing one David :-D http://twitter.com/dpp/status/9591471689 Cheers, Tim On 24 Feb 2010, at 20:20, David Pollak wrote: and those that circumvent that process (including me) should wear the cone of shame. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: LiftRules.jQueryVersion ... :(
No, sounds good Marius... go for it.
Cheers, Tim
On 23 Feb 2010, at 11:00, Marius wrote:
I opened this ticket:
http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryversion-should-not-be-there-
I realize that this would bring a slight breaking change but I believe
it is worth it.
Folks please speak up if you think otherwise.
Br's,
Marius
On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
(yeah forgive me :) ...)
On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
+1 (and we might as well add 1.4.2 as well/instead :-)
On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
Guys,
This has been added not so long ago, and I am aware that I should
express my perspective on this back then as now it might be too late.
IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
ResourceServer should not even be aware of the underlying JS framework
thus the JQuery name in LiftRules is very unsound to me.
Here is other proposal of keeping things decoupled:
.
We currently have JQueryArtifacts which holds the JQuery
implementation.
We add in the JsArtifacts this:
trait JsArtifacts {
...
def version
}
then
case class JQueryArtifacts1_3_2 extends JQueryArtifacts {
def version = 1.3.2-min
}
case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
def version = 1.4.1-min
}
Then to select one or another we use the existent mechanism:
LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
can change this easily
then in ResourceServer we can easily make the version selection.
In this way LiftRules has no idea about JQuery, YUI etc and it
doesn't need to. it is only about feeding different implementations of
JsArtifact.
Thoughts?
Br's,
Marius
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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] What is LDAP doing in modules?
Hey all, I see the LDAP has finally been committed... what is it doing in modules? Its a read / write to LDAP based on record... shouldn't it be in persistence? Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: What is LDAP doing in modules?
Oh yeah, you are right Ross! Doh... in that case, might have to do some refactoring on that module to give it a more functional style. Cheers, Tim On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote: There's no record code in there -- it uses mapper in fact. I think this is just for auth. -Ross On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote: Hey all, I see the LDAP has finally been committed... what is it doing in modules? Its a read / write to LDAP based on record... shouldn't it be in persistence? Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: What is LDAP doing in modules?
Dick, that is exactly what I want also... I was expected the dude who added it to lift to tidy it up and make it more abstract before adding it to the project. I would suggest have a base LDAP module (perhaps record based) and remove the mapper stuff. Cheers, Tim On Feb 23, 8:01 pm, Dick Hirsch hirsch.d...@gmail.com wrote: Any chance that the LDAP functionality will be independent of MetaMegaProtoUser and MegaProtoUser? Or maybe some sort of guidance (how-to?) on how to use it without these classes. We've (Apache ESME) have been waiting for a while for LDAP to be supported in Lift but we don't use MegaProtoUser. Thanks D. On Feb 23, 8:15 pm, Ross Mellgren dri...@gmail.com wrote: There's no record code in there -- it uses mapper in fact. I think this is just for auth. -Ross On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote: Hey all, I see the LDAP has finally been committed... what is it doing in modules? Its a read / write to LDAP based on record... shouldn't it be in persistence? Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: What is LDAP doing in modules?
Seems like the current lift-ldap ought to be gutted and turned into a pure LDAP wrapper for scala. Then we can add a record abstraction and any other abstractions people want. Cheers, Tim On Feb 23, 8:07 pm, Ross Mellgren dri...@gmail.com wrote: It might turn out that we'll need an actual LDAP record backend at work, so I may write one in the future ;-) -Ross On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote: Oh yeah, you are right Ross! Doh... in that case, might have to do some refactoring on that module to give it a more functional style. Cheers, Tim On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote: There's no record code in there -- it uses mapper in fact. I think this is just for auth. -Ross On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote: Hey all, I see the LDAP has finally been committed... what is it doing in modules? Its a read / write to LDAP based on record... shouldn't it be in persistence? Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: What is LDAP doing in modules?
Ross my good man, did you just volunteer? :-D +1 on the MegaUberRobotTronFromOuterSpace. There is also a fair amount of Java-ish code in there; it would be nice if that went away sometime too :-) Cheers, Tim On 23 Feb 2010, at 20:32, Ross Mellgren wrote: Perhaps eventually (or if someone right now has a strong use), but maybe in the short term it should be just mildly split up a bit so that it can be used separate of MetaMegaTron? I'm sure there are plenty of people who just need authentication and have no intent of using more sophisticated LDAP integration. -Ross On Feb 23, 2010, at 3:14 PM, Timothy Perrett wrote: Seems like the current lift-ldap ought to be gutted and turned into a pure LDAP wrapper for scala. Then we can add a record abstraction and any other abstractions people want. Cheers, Tim On Feb 23, 8:07 pm, Ross Mellgren dri...@gmail.com wrote: It might turn out that we'll need an actual LDAP record backend at work, so I may write one in the future ;-) -Ross On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote: Oh yeah, you are right Ross! Doh... in that case, might have to do some refactoring on that module to give it a more functional style. Cheers, Tim On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote: There's no record code in there -- it uses mapper in fact. I think this is just for auth. -Ross On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote: Hey all, I see the LDAP has finally been committed... what is it doing in modules? Its a read / write to LDAP based on record... shouldn't it be in persistence? Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: What is LDAP doing in modules?
haha yeah, well I was originally planning on writing a record backend in my book for LDAP, but thought we already had one... so maybe i'll do it in a month or two ;-) Cheers, Tim On 23 Feb 2010, at 20:46, Ross Mellgren wrote: Hah maybe if I have some extra moments I'll look at it. I'm preparing for a short trip this weekend so my spare time this week is short. If you didn't have a book to write I'd make you do it! ;-) -Ross On Feb 23, 2010, at 3:40 PM, Timothy Perrett wrote: Ross my good man, did you just volunteer? :-D +1 on the MegaUberRobotTronFromOuterSpace. There is also a fair amount of Java-ish code in there; it would be nice if that went away sometime too :-) Cheers, Tim On 23 Feb 2010, at 20:32, Ross Mellgren wrote: Perhaps eventually (or if someone right now has a strong use), but maybe in the short term it should be just mildly split up a bit so that it can be used separate of MetaMegaTron? I'm sure there are plenty of people who just need authentication and have no intent of using more sophisticated LDAP integration. -Ross On Feb 23, 2010, at 3:14 PM, Timothy Perrett wrote: Seems like the current lift-ldap ought to be gutted and turned into a pure LDAP wrapper for scala. Then we can add a record abstraction and any other abstractions people want. Cheers, Tim On Feb 23, 8:07 pm, Ross Mellgren dri...@gmail.com wrote: It might turn out that we'll need an actual LDAP record backend at work, so I may write one in the future ;-) -Ross On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote: Oh yeah, you are right Ross! Doh... in that case, might have to do some refactoring on that module to give it a more functional style. Cheers, Tim On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote: There's no record code in there -- it uses mapper in fact. I think this is just for auth. -Ross On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote: Hey all, I see the LDAP has finally been committed... what is it doing in modules? Its a read / write to LDAP based on record... shouldn't it be in persistence? Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: LiftRules.jQueryVersion ... :(
Fair enough Marius - I just didn't remember seeing it is all and wanted to
check we were following the process for all the changes made to Lift. You know
im a stickler for process ;-)
Your proposed solution sounds good though - I agree JsArtifacts is certainly
under explored; like a lot of parts of Lift.
Cheers, Tim
On 23 Feb 2010, at 21:21, Marius wrote:
Personally I think Jon followed the correct process. I do remember
discussions on this list and on review board. JsArtifacts is somehow
under-explored ... I carry a good part of the blame as I should have
pointed the perspective towards JsArtifacts.
Anyways the proposed fix for #363 is on the review board now.
Essentially the JsArtifacts implementation owns the path rewriting
rules now for its own domain.
Br's,
Marius
On 23 feb., 22:04, Timothy Perrett timo...@getintheloop.eu wrote:
Jon, did it go through a discussion on the mailing list? I dont
remember seeing it? (and I cant find it in the archives if it was)
Anything like this really needs discussion on the mailing list as its
fundamental to the Lift story and we need to maintain a consistent
API.
Cheers, Tim
On Feb 23, 7:48 pm, Jonathan Hoffman jonhoff...@gmail.com wrote:
I originally added LiftRules.jQueryVersion, but I agree that this is a much
better solution.
thanks,
- Jon
On Feb 23, 2010, at 6:00 AM, Marius wrote:
I opened this
ticket:http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryve...
I realize that this would bring a slight breaking change but I believe
it is worth it.
Folks please speak up if you think otherwise.
Br's,
Marius
On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
(yeah forgive me :) ...)
On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
+1 (and we might as well add 1.4.2 as well/instead :-)
On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
Guys,
This has been added not so long ago, and I am aware that I should
express my perspective on this back then as now it might be too late.
IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
ResourceServer should not even be aware of the underlying JS framework
thus the JQuery name in LiftRules is very unsound to me.
Here is other proposal of keeping things decoupled:
.
We currently have JQueryArtifacts which holds the JQuery
implementation.
We add in the JsArtifacts this:
trait JsArtifacts {
...
def version
}
then
case class JQueryArtifacts1_3_2 extends JQueryArtifacts {
def version = 1.3.2-min
}
case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
def version = 1.4.1-min
}
Then to select one or another we use the existent mechanism:
LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
can change this easily
then in ResourceServer we can easily make the version selection.
In this way LiftRules has no idea about JQuery, YUI etc and it
doesn't need to. it is only about feeding different implementations of
JsArtifact.
Thoughts?
Br's,
Marius
--
You received this message because you are subscribed to the Google
Groups Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: Documenting the source code / supplementing the API docs
We are interested in the contribution of course... I think the issue is mostly about how we take patches for this. Someone on the team would need to own this and merge your documentation changes into the master (provided DPP has no objections to this - seeing as its documentation I doubt he has) Any takers from the team? Cheers, Tim On 22 Feb 2010, at 16:14, Stuart Roebuck wrote: Sorry for the slow response—was away for a family weekend! I have limited knowledge of Lift internals… However, my view is that it is often easier to document code when you don't know it well than when you do, because you soon loose interest in documenting things that are obvious to you. What I hope to do is document the things that I need to know as I go along on the basis that many of these things will also be important to others. It's an agile rather than systematic approach if you see what I mean. I have no ego issues here. It's just a small way of giving to the community in a win-win kind of way. If my contributions don't seem helpful to anyone else then folk can say and I'm not going to disappear in a torrent of abuse :-) Similarly, I'm not proposing some big project here. I'm talking about a drip-drip of updates as I spot things that need documenting—I've got plenty other stuff on my plate right now as I'm launching a company based on a Lift based product in mid-year. Enough said… How do we resolve the documentation standard issue? (Scala 2.8 Scaladoc2 or prior) David? Stuart. On Feb 19, 4:11 pm, Timothy Perrett timo...@getintheloop.eu wrote: This could work - although, some parts of lift are very non-trivial and require good knowledge of lift internals. Do you have such knowledge or are you just hoping to contribute where you can with helpful information? Both are good, just trying to establish what you had in mind. Lift-util probably has the best docs at the moment, so if we could emulate that it would be good. Cheers, Tim On 19 Feb 2010, at 15:56, Ross Mellgren wrote: If you can get an established standard on what the content and format should be, I can work with you reviewing the patches and applying them. But, need to get a concordance from the list on the content first. -Ross On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote: I've had a bit of a break from Lift and coming back I find myself annoyed that I didn't write some notes last time and am having to go back to searching through the various bits of documentation to figure things out. Anyway, after much thought I decided that the best way to write my notes would be to supplement the API docs (ie. the Scaladoc documentation in the code base). so that I can view context sensitive help in my IDE of choice and others can benefit from my labours! So, question 1… The current API docs are very light on documentation and sometime ago I noticed some notice about removing documentation from the code base. Is there some policy about not having documentation in the code or any thought on whether it should adhere to the Scaladoc 2 syntax? Question 2… This is only really going to work if the process of submitting the documentation is reasonably straightforward so… What's the easiest possible way of submitting documentation changes to the code base? (if indeed this is something the core team would welcome). I was thinking of perhaps emailing git patch files to someone in the core team who can verify that the comments are right before checking them in. Any thoughts? If there is a reasonably explainable approach, it could be added as a Wiki page to encourage wider participation. Best, Stuart. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group
Re: [Lift] Re: London Lift talk
The problem is that im based in the westcountry... so its more getting there in the first instance if im not in the city for work. Cheers, Tim On 22 Feb 2010, at 17:04, Richard Dallaway wrote: There'll be a trip to the pub after, if that's any use as an incentive to come along :-) -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
Whilst we are talking about Props, I wouldn't mind seeing a level of abstraction on Props so that it can load stuff from things other than .props files. For instance, Im using configgy more and more these days as its much more preferable to properties files for app configuration. Anyone got any thoughts on this? Cheers, Tim On 22 Feb 2010, at 18:34, Jeppe Nejsum Madsen wrote: 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
Sorry David, do you mean you don't like configgy because it can change configurations at runtime? It can only do that if you specifically tell it to. Without registered observers, changes to the .conf file are ignored. Certainly, thats the way it works within all my applications that i've used configgy to date. Cheers, Tim On 22 Feb 2010, at 18:51, David Pollak wrote: On Mon, Feb 22, 2010 at 10:42 AM, Timothy Perrett timo...@getintheloop.eu wrote: Whilst we are talking about Props, I wouldn't mind seeing a level of abstraction on Props so that it can load stuff from things other than .props files. For instance, Im using configgy more and more these days as its much more preferable to properties files for app configuration. Anyone got any thoughts on this? I'd love to see a more flexible file format for properties as well as support for merging a secret set of properties (e.g., ones that contain passwords that you don't want to put into source control) during property file parsing. The thing I'm not keen on with Configgy is the ability to change configurations during runtime. Cheers, Tim On 22 Feb 2010, at 18:34, Jeppe Nejsum Madsen wrote: 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] anybody used OPA?
This is related to Lift how? It appears to be a framework itself... Cheers, Tim On 22 Feb 2010, at 19:51, Raoul Duke wrote: http://mlstate.com -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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 tool survey
Mads, What is your timeline? I have something cooking with the boys over at SBT if your interested... we have laid the ground work and made modifications to SBT itself but it requires an implementation on the Lift side (of which we have I fairly good plan for) Interested? Ping me off list and lets chat. Cheers, Tim On 22 Feb 2010, at 21:52, Mads Hartmann wrote: Hello everyone Coming from other web-frameworks or just in general what are the tools you miss the most when working on your lift project? I'm trying to create the foundation for a Google of Summer Code project and would really like to work on tooling for lift, so if you would take the time to help me out by answering the question, I would truly appreciate it :) Thanks, Mads Hartmann Jensen -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Versions: Netbeans, Scala and Lift
For the OP, Read: Binary incompatible and totally inoperable between even micro releases. Cheers, Tim On 21 Feb 2010, at 21:51, Ross Mellgren wrote: Keep in mind that Scala is extremely version sensitive and not backward compatible. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: London Lift talk
Man, I really must try and drag my ass along to this... Video would be good though as its more than likely i'll miss it due to work Cheers, Tim On 20 Feb 2010, at 21:49, Marius wrote: Neat ! ... will there be any video ? Br's, Marius On 20 feb., 22:22, andy andy1...@gmail.com wrote: Hi all The London Scala User Group (LSUG) will be presenting a talk by Richard Dallaway on 'Getting started with Lift' at SkillsMatter on the March 8th 2010 at 6:30. This will be a general talk on the basic of Lift, what can be achieved and how you can perform common web tasks. For details of this talk can be found at:http://www.meetup.com/london-scala/calendar/12468165/ and to sign up:http://skillsmatter.com/event/java-jee/getting-started-with-lift All are welcome, and there will be a visit to the pub afterwards. andy -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
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? Cheers, Tim On 20 Feb 2010, at 17:47, Petr Pudlak wrote: If I understand it correctly, you suggest to have a function-type field that could be set in the Boot class and which would be called to calculate the run mode. That would be nice, a developer would be able to choose whatever means (s)he would prefer. Another possibility would be to add another method to the Boot class, which would calculate the run mode. It would be less nice than the previous solution, but it could be called before the 'boot' method, if that would be required. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Documenting the source code / supplementing the API docs
This could work - although, some parts of lift are very non-trivial and require good knowledge of lift internals. Do you have such knowledge or are you just hoping to contribute where you can with helpful information? Both are good, just trying to establish what you had in mind. Lift-util probably has the best docs at the moment, so if we could emulate that it would be good. Cheers, Tim On 19 Feb 2010, at 15:56, Ross Mellgren wrote: If you can get an established standard on what the content and format should be, I can work with you reviewing the patches and applying them. But, need to get a concordance from the list on the content first. -Ross On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote: I've had a bit of a break from Lift and coming back I find myself annoyed that I didn't write some notes last time and am having to go back to searching through the various bits of documentation to figure things out. Anyway, after much thought I decided that the best way to write my notes would be to supplement the API docs (ie. the Scaladoc documentation in the code base). so that I can view context sensitive help in my IDE of choice and others can benefit from my labours! So, question 1… The current API docs are very light on documentation and sometime ago I noticed some notice about removing documentation from the code base. Is there some policy about not having documentation in the code or any thought on whether it should adhere to the Scaladoc 2 syntax? Question 2… This is only really going to work if the process of submitting the documentation is reasonably straightforward so… What's the easiest possible way of submitting documentation changes to the code base? (if indeed this is something the core team would welcome). I was thinking of perhaps emailing git patch files to someone in the core team who can verify that the comments are right before checking them in. Any thoughts? If there is a reasonably explainable approach, it could be added as a Wiki page to encourage wider participation. Best, Stuart. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Another convert
Someone ought to tell them that they have their quotes wrong... Odersky did not say that, Galpin did. Martin actually said: The interest and excitement about Scala continues to grow. It's great to see Lift reaching the 1.0 milestone as this is a proof point for the maturity of Scala as a software platform. Cheers, Tim On 18 Feb 2010, at 13:25, czerwonka wrote: Just an fyi for the group... http://www.andyczerwonka.com/platform Another convert added to the list... -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Implementing You are here:
Jeppe, you forgot to mention that the OP needs to implement their sitemap ;) Cheers, Tim On 18 Feb 2010, at 14:38, Jeppe Nejsum Madsen wrote: 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Another convert
Yes the quotes are accurate, just the attributed author is not right. You need to change them please. On the lift site it works like: author quote I think you must have read it as the other way around Cheers, Tim On 18 Feb 2010, at 15:02, czerwonka wrote: I got the quotes from the Lift site. http://liftweb.net/quotes.html Shall I change them? On Feb 18, 7:41 am, Timothy Perrett timo...@getintheloop.eu wrote: Someone ought to tell them that they have their quotes wrong... Odersky did not say that, Galpin did. Martin actually said: The interest and excitement about Scala continues to grow. It's great to see Lift reaching the 1.0 milestone as this is a proof point for the maturity of Scala as a software platform. Cheers, Tim On 18 Feb 2010, at 13:25, czerwonka wrote: Just an fyi for the group... http://www.andyczerwonka.com/platform Another convert added to the list... -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
I would recommend using Nginx or similar up front and using a reverse proxy setup - it is the most optiomal solution as Nginx can handle a vast number more connections than Jetty so it makes scaling your app easier on a single machine. Cheers, Tim On 17 Feb 2010, at 15:11, Jeppe Nejsum Madsen wrote: 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] [urgent] Broken lift-record
Guys,
Something strange is happening in Lift Record now - I have production
work that for some reason is now not behaving the way it should. The
custom record implementation that I have relies on knowing the field
name, and for some reason, it appears to not be being set:
(where Visitor is an example implementation of my Record):
scala new Visitor().email(dfsfdsf).fields.map(_.name)
TRACE - Set the value of 'null' with 'dfsfdsf' and marked as dirty.
(true)
I added some tracing and I see that the def name is always null
now... this is a major problem for me. My field apply method looks
like:
override def apply(in: FieldValueType): OwnerType = if
(owner.meta.mutable_?){
set(in)
dirty_?(true)
Log.trace(Set the value of '+name+' with '+in.toString+' and
marked as dirty. (+dirty_?.toString+))
owner
} else {
owner.meta.createWithMutableField(owner, this, Box.!!(in))
}
Im really not sure what has broken this, but i've not changed my code
other than adding the legacy check to accommodate ross' latest
changes.
I URGENTLY need a fix for this - we have production code relying on
this.
Cheers, Tim
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [urgent] Broken lift-record
Not a generic one - to reproduce it you would need my custom record
implementation and access to internal work servers (neither of which I
can give out).
I have just realised however that the name field is present and
correct when the field value is set:
field.setFromString
So it appears that its just a problem with set(param) ?
Cheers, Tim
On Feb 17, 5:46 pm, Ross Mellgren dri...@gmail.com wrote:
I'm starting to look at this. Do you have a repro case?
-Ross
On Feb 17, 2010, at 12:41 PM, Timothy Perrett wrote:
Guys,
Something strange is happening in Lift Record now - I have production
work that for some reason is now not behaving the way it should. The
custom record implementation that I have relies on knowing the field
name, and for some reason, it appears to not be being set:
(where Visitor is an example implementation of my Record):
scala new Visitor().email(dfsfdsf).fields.map(_.name)
TRACE - Set the value of 'null' with 'dfsfdsf' and marked as dirty.
(true)
I added some tracing and I see that the def name is always null
now... this is a major problem for me. My field apply method looks
like:
override def apply(in: FieldValueType): OwnerType = if
(owner.meta.mutable_?){
set(in)
dirty_?(true)
Log.trace(Set the value of '+name+' with '+in.toString+' and
marked as dirty. (+dirty_?.toString+))
owner
} else {
owner.meta.createWithMutableField(owner, this, Box.!!(in))
}
Im really not sure what has broken this, but i've not changed my code
other than adding the legacy check to accommodate ross' latest
changes.
I URGENTLY need a fix for this - we have production code relying on
this.
Cheers, Tim
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [urgent] Broken lift-record
The field in question is a subtype of:
sealed abstract class TextADORField[OwnerType : Record[OwnerType]]
(rec: OwnerType)
extends ADORField[OwnerType, String](rec){
def setFromString(s: String): Box[String] = {
dirty_?(true)
Full(set(s))
}
def setFromAny(in: Any): Box[String] = {
dirty_?(true)
in match {
case seq: Seq[_] if !seq.isEmpty = seq.map(setFromAny)(0)
case (s: String) :: _ = Full(set(s))
case null = Full(set(null))
case s: String = Full(set(s))
case Some(s: String) = Full(set(s))
case Full(s: String) = Full(set(s))
case None | Empty | Failure(_, _, _) = Full(set(null))
case o = Full(this.set(o.toString))
}
}
def defaultValue =
}
As you say, they should both go to setBox... Although, look at this:
scala Visitor.createRecord.fields.map(_.name)
res25: List[String] = List(email, last_name, first_name)
scala new Visitor().fields.map(_.name)
res27: List[String] = List(null, null, null)
That never used to be the case, you used to be able to call new and
still get the introspection any ideas?
Cheers, Tim
On Feb 17, 5:52 pm, Ross Mellgren dri...@gmail.com wrote:
Name should be set by introspect during the record initialization, so I'm not
sure why it would matter. Also, setFromString and set should both degenerate
to setBox, which should do the actual work. Can you show your setFromString
implementation? Are you overriding anything other than setFromAny and
setFromString in the set department?
-Ross
On Feb 17, 2010, at 12:51 PM, Timothy Perrett wrote:
Not a generic one - to reproduce it you would need my custom record
implementation and access to internal work servers (neither of which I
can give out).
I have just realised however that the name field is present and
correct when the field value is set:
field.setFromString
So it appears that its just a problem with set(param) ?
Cheers, Tim
On Feb 17, 5:46 pm, Ross Mellgren dri...@gmail.com wrote:
I'm starting to look at this. Do you have a repro case?
-Ross
On Feb 17, 2010, at 12:41 PM, Timothy Perrett wrote:
Guys,
Something strange is happening in Lift Record now - I have production
work that for some reason is now not behaving the way it should. The
custom record implementation that I have relies on knowing the field
name, and for some reason, it appears to not be being set:
(where Visitor is an example implementation of my Record):
scala new Visitor().email(dfsfdsf).fields.map(_.name)
TRACE - Set the value of 'null' with 'dfsfdsf' and marked as dirty.
(true)
I added some tracing and I see that the def name is always null
now... this is a major problem for me. My field apply method looks
like:
override def apply(in: FieldValueType): OwnerType = if
(owner.meta.mutable_?){
set(in)
dirty_?(true)
Log.trace(Set the value of '+name+' with '+in.toString+' and
marked as dirty. (+dirty_?.toString+))
owner
} else {
owner.meta.createWithMutableField(owner, this, Box.!!(in))
}
Im really not sure what has broken this, but i've not changed my code
other than adding the legacy check to accommodate ross' latest
changes.
I URGENTLY need a fix for this - we have production code relying on
this.
Cheers, Tim
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [urgent] Broken lift-record
It was a problem with the record initialisation code and the
introspect method not being handled correctly. Fixed in:
37a59389bf65d4c558ff906427d52fb6fae5d912
Thanks to Ross for the help :-)
Cheers, Tim
On Feb 17, 6:11 pm, Ross Mellgren dri...@gmail.com wrote:
It is definitely the new. I thought that it was always this way because I
observed it (I thought) before I made those changes. I just reproduced your
exact case:
val rec1 = MyMetaRecord.createRecord
val res1 = rec1.foo(zippy).fields.map(_.name)
val rec2 = new MyRecord()
val res2 = rec2.foo(zippy).fields.map(_.name)
div{ String.valueOf(res1) }/div ++ div{ String.valueOf(res2)
}/div
Result is:
List(foo)
List(null)
So createRecord is doing the introspection. I'll start by reverting out my
change to record and see if that makes the problem go away, to narrow it down.
Do you have IM? We could cycle faster.
-Ross
On Feb 17, 2010, at 1:02 PM, Timothy Perrett wrote:
The field in question is a subtype of:
sealed abstract class TextADORField[OwnerType : Record[OwnerType]]
(rec: OwnerType)
extends ADORField[OwnerType, String](rec){
def setFromString(s: String): Box[String] = {
dirty_?(true)
Full(set(s))
}
def setFromAny(in: Any): Box[String] = {
dirty_?(true)
in match {
case seq: Seq[_] if !seq.isEmpty = seq.map(setFromAny)(0)
case (s: String) :: _ = Full(set(s))
case null = Full(set(null))
case s: String = Full(set(s))
case Some(s: String) = Full(set(s))
case Full(s: String) = Full(set(s))
case None | Empty | Failure(_, _, _) = Full(set(null))
case o = Full(this.set(o.toString))
}
}
def defaultValue =
}
As you say, they should both go to setBox... Although, look at this:
scala Visitor.createRecord.fields.map(_.name)
res25: List[String] = List(email, last_name, first_name)
scala new Visitor().fields.map(_.name)
res27: List[String] = List(null, null, null)
That never used to be the case, you used to be able to call new and
still get the introspection any ideas?
Cheers, Tim
On Feb 17, 5:52 pm, Ross Mellgren dri...@gmail.com wrote:
Name should be set by introspect during the record initialization, so I'm
not sure why it would matter. Also, setFromString and set should both
degenerate to setBox, which should do the actual work. Can you show your
setFromString implementation? Are you overriding anything other than
setFromAny and setFromString in the set department?
-Ross
On Feb 17, 2010, at 12:51 PM, Timothy Perrett wrote:
Not a generic one - to reproduce it you would need my custom record
implementation and access to internal work servers (neither of which I
can give out).
I have just realised however that the name field is present and
correct when the field value is set:
field.setFromString
So it appears that its just a problem with set(param) ?
Cheers, Tim
On Feb 17, 5:46 pm, Ross Mellgren dri...@gmail.com wrote:
I'm starting to look at this. Do you have a repro case?
-Ross
On Feb 17, 2010, at 12:41 PM, Timothy Perrett wrote:
Guys,
Something strange is happening in Lift Record now - I have production
work that for some reason is now not behaving the way it should. The
custom record implementation that I have relies on knowing the field
name, and for some reason, it appears to not be being set:
(where Visitor is an example implementation of my Record):
scala new Visitor().email(dfsfdsf).fields.map(_.name)
TRACE - Set the value of 'null' with 'dfsfdsf' and marked as dirty.
(true)
I added some tracing and I see that the def name is always null
now... this is a major problem for me. My field apply method looks
like:
override def apply(in: FieldValueType): OwnerType = if
(owner.meta.mutable_?){
set(in)
dirty_?(true)
Log.trace(Set the value of '+name+' with '+in.toString+' and
marked as dirty. (+dirty_?.toString+))
owner
} else {
owner.meta.createWithMutableField(owner, this, Box.!!(in))
}
Im really not sure what has broken this, but i've not changed my code
other than adding the legacy check to accommodate ross' latest
changes.
I URGENTLY need a fix for this - we have production code relying on
this.
Cheers, Tim
--
You received this message because you are subscribed to the Google
Groups Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
Re: [Lift] Context path, proxies Lift
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). Glad that worked for you Cheers, Tim On 17 Feb 2010, at 19:43, Jeppe Nejsum Madsen wrote: 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
Contact me privatly with your IM adress and lets chat about it Jeppe - I'm doing something similar with helicon (windows proxy) and it's working fine. I'm traveling now but will be about later Cheers, Tim Sent from my iPhone On 16 Feb 2010, at 10:01, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: 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 . -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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
Seeing as I don't know what the solution is yet, no. Lol. I'd rather just have a 15 min conversation than waste time with a million emails ( I'm very busy right now ) Will get jeppe to post working solution when one exists... Cheers, Tim Sent from my iPhone On 16 Feb 2010, at 15:15, Ross Mellgren dri...@gmail.com wrote: Any chance you could have this discussion on-list to increase the general knowledge about it? -Ross On Feb 16, 2010, at 8:50 AM, Timothy Perrett wrote: Contact me privatly with your IM adress and lets chat about it Jeppe - I'm doing something similar with helicon (windows proxy) and it's working fine. I'm traveling now but will be about later Cheers, Tim Sent from my iPhone On 16 Feb 2010, at 10:01, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: 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 . -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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 . -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: thread [Image upload and serving example]
Yes, it's the age. It's stops people dragging up mega old threads and i would imagine it's something archive related in google groups Cheers, Tim Sent from my iPhone On 16 Feb 2010, at 14:46, Luke Nezda lne...@gmail.com wrote: Thanks Ross! This was helpful. - Luke p.s. Anyone know why the following thread: http://groups.google.com/group/liftweb/browse_thread/thread/b0509263e18c9a66/f36535bbe15273d6 only has Reply to author links and no Reply links? Is it its age ? (e.g., last year) Just trying to avoid another inadvertent email to author rather than the list. On Feb 15, 5:16 pm, Ross Mellgren dri...@gmail.com wrote: I have a mild derivative of this code in another test repo I built for someone else: http://github.com/Dridus/test-image Maybe that'll help. -Ross On Feb 15, 2010, at 5:19 PM, David Pollak wrote: On Mon, Feb 15, 2010 at 5:54 AM, Luke Nezda lne...@gmail.com wrote: Hello - I attempted to reply to the thread with subject Image upload and serving example initiated by David Pollack on Nov. 30, 2009 via the Google Groups UI and inadvertently sent mail directly to David because there was only a Reply to author link, no plain Reply link -- oops. (He politely replied Please post all questions to the list.) Please forgive my ignorance, but why didn't that thread have Reply links after each message ? (I see other threads do) Anyway, my real question: Is the code referenced in that original thread --http://github.com/dpp/imagine/ -- code still floating around somewhere ? Sorry... I did a purge of my un-used GitHub projects and my hard drive a week or so back and deleted it. Sorry. :-( Thanks, - Luke -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group athttp://groups.google.com/ group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group athttp://groups.google.com/ group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en . -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Lift Record
Debasish just posted this: http://debasishg.blogspot.com/2010/02/why-i-dont-like-activerecord-for-domain.html Interesting feedback especially regarding the current design of Record... Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Nginx, Jetty multiple contexts
In boot: LiftRules.calculateContextPath = () = Full(/yourcontext) Im not using NGINX for that particular application as we use windows at work, so I cant share a config file. However, if you post what you have i'll try to wield my NGINX jedi skillz! Cheers, Tim On 15 Feb 2010, at 11:03, Jeppe Nejsum Madsen wrote: On Mon, Feb 15, 2010 at 12:40 AM, Timothy Perrett timo...@getintheloop.eu wrote: The context header stuff was removed because it was tottlay broke ;-) Check LiftRules for the context calculator - you should be able to dynamically set it from whatever value you want. I'll post an example tomorrow if you need one. Would be nice, both from the lift side and Nginx if that's what you're using. /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] Nginx, Jetty multiple contexts
What's with the ERB markup?
BTW, im confused about why you don't handle this host selection thing in the
lift code and just read the host name? What is the use case here? A mobile site
or something similar?
Also, now seeing that you want to work on a request by request basis, im not
sure that its going to work for you (or be safe) to dynamically use context
switching in the way I had suggested as its generally something you do at boot
time.
Can you work back and explain the use case?
Cheers, Tim
On 15 Feb 2010, at 15:00, Jeppe Nejsum Madsen wrote:
On Mon, Feb 15, 2010 at 12:29 PM, Timothy Perrett
timo...@getintheloop.eu wrote:
In boot:
LiftRules.calculateContextPath = () = Full(/yourcontext)
Oh, that was easy :-) I'll try it out late today
Im not using NGINX for that particular application as we use windows at
work, so I cant share a config file.
However, if you post what you have i'll try to wield my NGINX jedi skillz!
This is what I currently have that is app specific, the idea being
that context == %= @node[:hostname] %
server {
listen 80;
server_name %= @node[:hostname] %;
access_log %= @node[:nginx_log_dir] %/ %= @node[:hostname] %.access.log;
location / {
proxy_pass http://127.0.0.1:8080/%= @node[:hostname] %/;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 700;
proxy_connect_timeout 120;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
/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] Lift Record
Sounds like a good plan Ross - have you any specific suggestions about how best to untangle things? Marius - your thoughts as the own of Record? Cheers, Tim On 15 Feb 2010, at 15:03, Ross Mellgren wrote: FWIW, I agree mostly completely, and when I was writing the integration I didn't like the fact that I couldn't make one model object usable for both Couch and an RDBMS (for example). I guess it could be made to support more than one if the persistence-specific stuff was untangled from MetaRecord/Record subclasses and made into mixable traits? -Ross On Feb 15, 2010, at 4:34 AM, Timothy Perrett wrote: Debasish just posted this: http://debasishg.blogspot.com/2010/02/why-i-dont-like-activerecord-for-domain.html Interesting feedback especially regarding the current design of Record... Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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 do I build reusable modules for lift?
Generally, the module can look after its own concerns (for instance lift rules dispatching). However, the main wire up must be completed by the consumer rather than any classpath magic. Yes, LiftRules does support multiple add to package calls. I would put the addToPackage call in your module, and have a surrounding init method that just gets called in your consuming boot.scala meaning that your consuming code only has: MyHelpfulModule.init in its Boot.boot method - nice and tidy. Cheers, Tim On 14 Feb 2010, at 11:21, Jonathan Ferguson wrote: I was more concerned with the package structure being different between the common module and the projects consuming it. The snippets for the common module would be in, say com.mycompany.common.snippet where as the projects consuming the common module would likely have the package structure com.mycompany.nextbigthing.snippet Does LiftRules support multiple addToPackage call? Is there a nice way to have the common module look after it's own interaction with LiftRules or should the consumer of the module look after it? Jono On 14 February 2010 21:13, ngocdaothanh ngocdaoth...@gmail.com wrote: I think you could install your modules into Maven's repository, then use them from projects as dependencies. On Feb 14, 6:32 pm, Jonathan Ferguson j...@spiralarm.com wrote: Sorry for a bit of a vague Sunday night question. We now have several lift projects floating round that have common snippets and potentially model objects, which would be nice to reuse without cut paste. Is there documentation on how to do this or best practices? Cheers Jono -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Page transition using location.replace
Why? What would be a good reason for doing this...? On 14 Feb 2010, at 08:06, aw wrote: Is there a way to do a page transition using location.replace? In some cases, I am interested in not having the back button function. I think I am looking for an SHtml.link variation that leverages location.replace. Perhaps an S.redirectTo variation too. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] File Download
See: http://blog.getintheloop.eu/2009/3/19/understanding-lift-s-streamingresponse Construct the CSV in memory and just then stuff it into a streaming response as a byte array. Cheers, Tim On 14 Feb 2010, at 16:18, Gang wrote: Hi, I have a question and it may not be a pure Lift one. But since I'm working on a Lift app and this group is the most responsive one I have seen, might just try it here. I need to download data from database in CSV format. What is the best approach within Lift framework? Do I have to write the data on the server somewhere and then provide user with a link? I have tried to google scala, lift, file download..., but could not come up with what I'm looking for. Maybe I didn't use the right key words in search? Thanks in advance! Brs Gang -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group 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] Improvements to Lift-Json
I dont mean to be overly pedantic, but that would be a fork - not a branch ;-) Cheers, Tim On 14 Feb 2010, at 17:19, John A. De Goes wrote: You can find the branch here: http://github.com/jdegoes/liftweb -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Page transition using location.replace
Im confused with how lift is stopping you providing this within your application? It seems like you could do what you wanted with client side javascript? Cheers, Tim On 14 Feb 2010, at 17:16, aw wrote: Because I don't like how my back button can return me back to a state that is no longer true. In my particular use-case, I am drilling into an item and either want to do an action or cancel. Completing an Action, or hitting Cancel, will put me back on the viewItem page, after possibly executing an action. I really don't like the Back button functioning in this case because if the user hits the back button, then the user can resubmit the action. Sometimes, that could be dangerous or confusing. On Feb 14, 4:14 am, Timothy Perrett timo...@getintheloop.eu wrote: Why? What would be a good reason for doing this...? On 14 Feb 2010, at 08:06, aw wrote: Is there a way to do a page transition using location.replace? In some cases, I am interested in not having the back button function. I think I am looking for an SHtml.link variation that leverages location.replace. Perhaps an S.redirectTo variation too. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Nginx, Jetty multiple contexts
The context header stuff was removed because it was tottlay broke ;-) Check LiftRules for the context calculator - you should be able to dynamically set it from whatever value you want. I'll post an example tomorrow if you need one. Cheers, Tim Sent from my iPhone On 14 Feb 2010, at 22:38, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, I'm trying to host several lift apps on a single server using jetty (one context per app) and nginx in front. I want to have www.domain1.com goes to lift app localhost/domain1 www.domain2.com goes to lift app localhost/domain2 It seems like what happens is that nginx correctly forwards requests, but when lift generates links, at adds the context name. Based on some Googling, I added the X-Lift-ContextPath header, but this didn't seem to help. Any examples of such a setup? /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] Re: very excited about 2.0
B - sounds like creative license on the part of the writer It really bugs me when stuff like that goes on; also dont like constantly having lift compared with rails lol! Cheers, Tim On 13 Feb 2010, at 17:17, David Pollak wrote: On Sat, Feb 13, 2010 at 9:11 AM, Zach Cox zcox...@gmail.com wrote: I'm also really excited to learn what many of Scala’s benefits, including a development model that looks like Ruby on Rails means exactly. I read through the change reports but nothing looked Rails-y to me. The announcement on scala-lang.org (http://www.scala-lang.org/ node/5236) also mentions this but doesn't elaborate: The new version of Lift also supports a more Ruby on Rails style development model that will appeal to many. This sounds really interesting - can someone in-the-know provide some more details on this? I have no clue how this got into the article. Thanks, Zach On Feb 11, 2:05 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Timothy Perrett timo...@getintheloop.eu writes: Its not everything, but it'll give you a general idea: http://scala-tools.org/mvnsites-snapshots/liftweb/changes-report.html And don't forget to checkout the changes for 1.1 as 1.1 was renamed to2.0along the way :-) /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, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: JsCmds disabled inputs do not submit information
Correct - they don't. Sent from my iPhone On 14 Feb 2010, at 00:24, ngocdaothanh ngocdaoth...@gmail.com wrote: I think it is the browsers that don't send values of disabled inputs. On Feb 14, 2:46 am, Marius marius.dan...@gmail.com wrote: I don't think right now that this is a Lift problem. Do you experience this on all browsers? If so can you put together a minimalistic app that reproduces the behavior and send it to us? Br's, Marius On 13 feb., 19:28, Strom strommo...@gmail.com wrote: It seems that when I disable form inputs and set their values via JsCmds.setValById, the values don't get submitted to Lift in the form. Has anyone else had this problem? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en . -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: lift-couchdb pushed to master
Congratulations Ross. Cheers, Tim On Feb 12, 5:07 am, Ross Mellgren dri...@gmail.com wrote: I've just pushed the CouchDB integration using Lift-JSON and Dispatch that I've talked about on the list a couple times before. It has a couple pieces: - A straight JSON integration to CouchDB implemented by providing a family of extended Request subclasses that model CouchDB operations such as queries, revisions, storing and so on. - A Lift-JSON Record implementation, JSONRecord. - An extended JSONRecord that integrates with the JSON-oriented integration, CouchRecord. The best examples of how to use it are currently the unit tests: http://github.com/dpp/liftweb/tree/master/framework/lift-persistence/... They cover most of the API. I plan to write some simple documentation at some point. Share and Enjoy, -Ross -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Cached CSS (and Javascript?) issue
This is pretty much what rails does. Straight from github: link href=/stylesheets/bundle_common.css?7371c81fbc6b010a32fb11b42a0fc322c3c57863 media=screen rel=stylesheet type=text/css / link href=/stylesheets/bundle_github.css?7371c81fbc6b010a32fb11b42a0fc322c3c57863 media=screen rel=stylesheet type=text/css / It would be nice to provide some kind of generic helper snippet for this. Some hash that is configured on boot up would be great; provide some function in lift rules to alter the behaviour and away we go. Perhaps something like: lift:css href=/whatever.css / Thoughts? Cheers, Tim On 12 Feb 2010, at 18:53, Jeppe Nejsum Madsen wrote: On Fri, Feb 12, 2010 at 7:28 PM, Marius marius.dan...@gmail.com wrote: Oh yes I did and I hate it. Ironically I was about to propose a solution for this. instead of link rel=stylesheet type=text/css href=mycss.css/ do something like: lift:css name=mycss.css / this would render: link rel=stylesheet type=text/css href=mycss.css? i784yrfiuhferfhweir57=_/ the query string parameter would be generated at application start-up. If you update you css/js and restart the application the browser will refresh it. Potentially generating the random query string param could be a LiftRules function that by default generates a sequence once per application time. Thus you could potentially set your own function that reads this for a config file? Similarly lift:js name=myjs.js/ would do the same. I had similar thoughts sometime ago, but haven't looked at it since then: http://groups.google.com/group/liftweb/browse_thread/thread/1130ce4f9d5af010/a36c52fde3b2bc5b?lnk=gstq=jeppe++cachepli=1 For me, the real benefit would be combining many requests into one and setting a future Expires date but still be sure that all artifacts will be updated correctly. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Problems with SBT
pom.xml is irrelevant if your working with SBT. Please show your project.scala Cheers, Tim On 11 Feb 2010, at 16:24, Mads Hartmann wrote: Hello everyone, I was hoping I could get some help with an SBT error I'm getting: [error] /Users/Mads/Dev/logicOfScientificDiscovery/src/main/scala/ sidewayscoding/model/Discovery.scala:7: not found: value net [error] import net.liftweb._ [error]^ [error] /Users/Mads/Dev/logicOfScientificDiscovery/src/main/scala/ sidewayscoding/model/Discovery.scala:19: wrong number of arguments for constructor Object: ()java.lang.Object [error] object description extends MappedTextarea(this, 600) [error] [error] 94 errors found It looks like it doesn't import lift, build.properties #Project properties #Tue Feb 02 14:29:05 CET 2010 project.organization=sidewayscoding project.name=LogicOfScientificDiscovery sbt.version=0.5.6 project.version=1.0 scala.version=2.7.7 project.initialize=false pom.xm properties scala.version2.7.7/scala.version /properties ... dependency groupIdnet.liftweb/groupId artifactIdlift-mapper/artifactId version2.0-M1/version /dependency dependency groupIdnet.liftweb/groupId artifactIdlift-widgets/artifactId version2.0-M1/version /dependency dependency -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] very excited about 2.0
Its not everything, but it'll give you a general idea: http://scala-tools.org/mvnsites-snapshots/liftweb/changes-report.html Tim On 11 Feb 2010, at 14:44, Ivan Willig wrote: Hi guys, I am getting really excited about lift 2.0 but still feel in the dark about changes in 2.0. Is there a list of changes somewhere? I have looked on the mail list archives, the wiki and poked around the lift site. The SD time article mention that 2.0 brings many of Scala’s benefits, including a development model that looks like Ruby on Rails . Whats the best place for me to survey these changes? Thanks for you time. Ivan Willig 818-212-4554 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Problems with SBT
Dont use lift-core as a dependency.
Explicitly specify what it is you want webkit, mapper and widgets.
Cheers, Tim
On 11 Feb 2010, at 17:26, Mads Hartmann wrote:
Thanks Tim Timothy
-- properties
#Project properties
#Tue Feb 02 14:29:05 CET 2010
project.organization=sidewayscoding
project.name=LogicOfScientificDiscovery
sbt.version=0.5.6
project.version=1.0
scala.version=2.7.7
project.initialize=false
--- project file
import sbt._
class LogicOfScientificDiscovery(info: ProjectInfo) extends
DefaultWebProject(info)
{
val lift = net.liftweb % lift-core % 2.0-M1 % compile
val jetty6 = org.mortbay.jetty % jetty % 6.1.14 % test
// required because Ivy doesn't pull repositories from poms
val smackRepo = m2-repository-smack at http://maven.reucon.com/
public
}
---
My project is only dependent on lift-mapper and lift-widgets
I now get the following error when i try to run 'update'
warn] :: problems summary ::
[warn] WARNINGS
[warn]module not found: com.rabbitmq#amqp-client;1.7.0
[warn] local: tried
[warn] /Users/Mads/.ivy2/local/com.rabbitmq/amqp-client/1.7.0/ivys/
ivy.xml
[warn] -- artifact com.rabbitmq#amqp-client;1.7.0!amqp-client.jar:
[warn] /Users/Mads/.ivy2/local/com.rabbitmq/amqp-client/1.7.0/jars/
amqp-client.jar
[warn] m2-repository-smack: tried
[warn]
http://maven.reucon.com/public/com/rabbitmq/amqp-client/1.7.0/amqp-client-1.7.0.pom
[warn] -- artifact com.rabbitmq#amqp-client;1.7.0!amqp-client.jar:
[warn]
http://maven.reucon.com/public/com/rabbitmq/amqp-client/1.7.0/amqp-client-1.7.0.jar
[warn] public: tried
[warn]
http://repo1.maven.org/maven2/com/rabbitmq/amqp-client/1.7.0/amqp-client-1.7.0.pom
[warn] -- artifact com.rabbitmq#amqp-client;1.7.0!amqp-client.jar:
[warn]
http://repo1.maven.org/maven2/com/rabbitmq/amqp-client/1.7.0/amqp-client-1.7.0.jar
[warn] Scala-Tools Maven2 Repository: tried
[warn]
http://scala-tools.org/repo-releases/com/rabbitmq/amqp-client/1.7.0/amqp-client-1.7.0.pom
[warn] -- artifact com.rabbitmq#amqp-client;1.7.0!amqp-client.jar:
[warn]
http://scala-tools.org/repo-releases/com/rabbitmq/amqp-client/1.7.0/amqp-client-1.7.0.jar
[warn]::
[warn]:: UNRESOLVED DEPENDENCIES ::
[warn]::
[warn]:: com.rabbitmq#amqp-client;1.7.0: not found
[warn]::
[info]
On Feb 11, 6:08 pm, Tim Nelson tnell...@gmail.com wrote:
sbt doesn't look at POMs. You need to create Project file and add the
dependencies in there.
The example in the following is a little old, but it shows what you
needhttp://code.google.com/p/simple-build-tool/wiki/WebApplicationExample
Here's an updated example:
import sbt._
class HelloLiftProject(info: ProjectInfo) extends DefaultWebProject(info)
{
val lift = net.liftweb % lift-webkit % 2.0-M1 % compile
val jetty6 = org.mortbay.jetty % jetty % 6.1.14 % test
// required because Ivy doesn't pull repositories from poms
val smackRepo = m2-repository-smack at http://maven.reucon.com/public;
}
Tim
On Thu, Feb 11, 2010 at 10:24 AM, Mads Hartmann mads...@gmail.com wrote:
Hello everyone,
I was hoping I could get some help with an SBT error I'm getting:
[error] /Users/Mads/Dev/logicOfScientificDiscovery/src/main/scala/
sidewayscoding/model/Discovery.scala:7: not found: value net
[error] import net.liftweb._
[error]^
[error] /Users/Mads/Dev/logicOfScientificDiscovery/src/main/scala/
sidewayscoding/model/Discovery.scala:19: wrong number of arguments for
constructor Object: ()java.lang.Object
[error] object description extends MappedTextarea(this, 600)
[error]
[error] 94 errors found
It looks like it doesn't import lift,
build.properties
#Project properties
#Tue Feb 02 14:29:05 CET 2010
project.organization=sidewayscoding
project.name=LogicOfScientificDiscovery
sbt.version=0.5.6
project.version=1.0
scala.version=2.7.7
project.initialize=false
pom.xm
properties
scala.version2.7.7/scala.version
/properties
...
dependency
groupIdnet.liftweb/groupId
artifactIdlift-mapper/artifactId
version2.0-M1/version
/dependency
dependency
groupIdnet.liftweb/groupId
artifactIdlift-widgets/artifactId
version2.0-M1/version
/dependency
dependency
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group
Re: [Lift] Re: Problems with SBT
Your missing the servlet dependency... (its not rocket, copy it from the pom!)
On 11 Feb 2010, at 17:46, Mads Hartmann wrote:
I really appreciate the help guys - Just one error left now ;)
[error] /Users/Mads/Dev/logicOfScientificDiscovery/src/main/scala/
bootstrap/liftweb/Boot.scala:11: value servlet is not a member of
package javax
[error] import _root_.javax.servlet.http.{HttpServletRequest}
[error] ^
On Feb 11, 6:35 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Dont use lift-core as a dependency.
Explicitly specify what it is you want webkit, mapper and widgets.
Cheers, Tim
On 11 Feb 2010, at 17:26, Mads Hartmann wrote:
Thanks Tim Timothy
-- properties
#Project properties
#Tue Feb 02 14:29:05 CET 2010
project.organization=sidewayscoding
project.name=LogicOfScientificDiscovery
sbt.version=0.5.6
project.version=1.0
scala.version=2.7.7
project.initialize=false
--- project file
import sbt._
class LogicOfScientificDiscovery(info: ProjectInfo) extends
DefaultWebProject(info)
{
val lift = net.liftweb % lift-core % 2.0-M1 % compile
val jetty6 = org.mortbay.jetty % jetty % 6.1.14 % test
// required because Ivy doesn't pull repositories from poms
val smackRepo = m2-repository-smack at http://maven.reucon.com/
public
}
---
My project is only dependent on lift-mapper and lift-widgets
I now get the following error when i try to run 'update'
warn] :: problems summary ::
[warn] WARNINGS
[warn] module not found: com.rabbitmq#amqp-client;1.7.0
[warn] local: tried
[warn] /Users/Mads/.ivy2/local/com.rabbitmq/amqp-client/1.7.0/ivys/
ivy.xml
[warn] -- artifact com.rabbitmq#amqp-client;1.7.0!amqp-client.jar:
[warn] /Users/Mads/.ivy2/local/com.rabbitmq/amqp-client/1.7.0/jars/
amqp-client.jar
[warn] m2-repository-smack: tried
[warn]
http://maven.reucon.com/public/com/rabbitmq/amqp-client/1.7.0/amqp-cl...
[warn] -- artifact com.rabbitmq#amqp-client;1.7.0!amqp-client.jar:
[warn]
http://maven.reucon.com/public/com/rabbitmq/amqp-client/1.7.0/amqp-cl...
[warn] public: tried
[warn]
http://repo1.maven.org/maven2/com/rabbitmq/amqp-client/1.7.0/amqp-cli...
[warn] -- artifact com.rabbitmq#amqp-client;1.7.0!amqp-client.jar:
[warn]
http://repo1.maven.org/maven2/com/rabbitmq/amqp-client/1.7.0/amqp-cli...
[warn] Scala-Tools Maven2 Repository: tried
[warn]
http://scala-tools.org/repo-releases/com/rabbitmq/amqp-client/1.7.0/a...
[warn] -- artifact com.rabbitmq#amqp-client;1.7.0!amqp-client.jar:
[warn]
http://scala-tools.org/repo-releases/com/rabbitmq/amqp-client/1.7.0/a...
[warn] ::
[warn] :: UNRESOLVED DEPENDENCIES ::
[warn] ::
[warn] :: com.rabbitmq#amqp-client;1.7.0: not found
[warn] ::
[info]
On Feb 11, 6:08 pm, Tim Nelson tnell...@gmail.com wrote:
sbt doesn't look at POMs. You need to create Project file and add the
dependencies in there.
The example in the following is a little old, but it shows what you
needhttp://code.google.com/p/simple-build-tool/wiki/WebApplicationExample
Here's an updated example:
import sbt._
class HelloLiftProject(info: ProjectInfo) extends DefaultWebProject(info)
{
val lift = net.liftweb % lift-webkit % 2.0-M1 % compile
val jetty6 = org.mortbay.jetty % jetty % 6.1.14 % test
// required because Ivy doesn't pull repositories from poms
val smackRepo = m2-repository-smack at http://maven.reucon.com/public;
}
Tim
On Thu, Feb 11, 2010 at 10:24 AM, Mads Hartmann mads...@gmail.com wrote:
Hello everyone,
I was hoping I could get some help with an SBT error I'm getting:
[error] /Users/Mads/Dev/logicOfScientificDiscovery/src/main/scala/
sidewayscoding/model/Discovery.scala:7: not found: value net
[error] import net.liftweb._
[error]^
[error] /Users/Mads/Dev/logicOfScientificDiscovery/src/main/scala/
sidewayscoding/model/Discovery.scala:19: wrong number of arguments for
constructor Object: ()java.lang.Object
[error] object description extends MappedTextarea(this, 600)
[error]
[error] 94 errors found
It looks like it doesn't import lift,
build.properties
#Project properties
#Tue Feb 02 14:29:05 CET 2010
project.organization=sidewayscoding
project.name=LogicOfScientificDiscovery
sbt.version=0.5.6
project.version=1.0
scala.version=2.7.7
project.initialize=false
pom.xm
properties
scala.version2.7.7/scala.version
/properties
...
dependency
groupIdnet.liftweb/groupId
artifactIdlift-mapper/artifactId
version2.0-M1/version
/dependency
dependency
groupIdnet.liftweb/groupId
artifactIdlift-widgets
Re: [Lift] Re: lifecycle callbacks in record
LOL
Yeah that would be a bit of a problem!! Out of interest, what Record backend
are you trying to use?
Cheers, Tim
On 11 Feb 2010, at 21:57, harryh wrote:
OK kids. Here's a lesson for you. Don't mix Mapper and Record in the
same file! Cause if you do, you might do something like this:
class MCheckin extends MongoRecord[MCheckin] with MongoId[MCheckin]
with LifecycleCallbacks {
}
and wonder why the #$%^*( the callbacks aren't being called. But
then, after 5 hours of tinkering you finally realize that you were
implementing the mapper LifecycleCallbacks and not the record
LifecycleCallbacks.
-harryh
On Feb 10, 9:10 pm, harryh har...@gmail.com wrote:
Can anyone give me an example of how to implement a lifecycle callback
in record? I can't, for the life of me, get it to work. Nor does
there appear to be any documentation at all :(
-harryh
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: lifecycle callbacks in record
Oh thats epic. I didnt know that even existed... Lots of cool little projects kicking up at the moment! Cheers, Tim On 11 Feb 2010, at 22:17, harryh wrote: Yeah that would be a bit of a problem!! Out of interest, what Record backend are you trying to use? http://wiki.github.com/eltimn/scamongo/ Which needs some work (I have a fork on my local machine that I'm tinkering with), but mostly seems to be getting the job done. -harryh -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Snippet with no reflection an no massive case statement
So you don't want to write any explicit mapping, and you don't want to use reflection??? How would you propose Lift know what your asking for? Im afraid voodoo is not yet compatible with the JVM ;-) Cheers, Tim On 9 Feb 2010, at 16:54, Hugo Palma wrote: I just read http://wiki.github.com/dpp/liftweb/about-snippets and i have the following question: So is really the only way to avoid having a reflection call every time you use a snippet to use a DispatchSnippet with a case statement for every method ? It's just that i don't really think that the case is a very clean way of doing things. Can be ok for a couple of methods but it can be really ugly with more than that. So, is there any other way ? Thanks. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Support for page and snippet level localization
The analogy would be MVC controllers... the index method has an index page and an index resource bundle. Within Lift, we dont use controllers, so there is nothing stopping you calling a whole bunch of snippets on a single page - thus, there would be no single page resource bundle (that is, it wouldn't buy you anything IMHO) as different snippets might share localised text or whatever. I guess im just trying to say things are not silo'ed in Lift. Does that add some more clarity to my statement? Cheers, Tim On Feb 9, 2:47 pm, Hugo Palma hugo.m.pa...@gmail.com wrote: Sorry Tim but i don't quite understand what you mean by page is scoped to a single snippet and that invalidates that you have a resource bundle per page. Sorry is this is clear to everyone else but i'm new with Lift so i'm still grasping basic concepts. On Feb 8, 10:49 pm, Timothy Perrett timo...@getintheloop.eu wrote: That wouldn't work for Lift as it assumes a page is scoped to a single snippet. It works with Tapestry because its an MVC framework. Lift is *not* MVC. Have you seen LiftRules.resourceBundleFactories ? Cheers, Tim On 8 Feb 2010, at 22:11, Hugo Palma wrote: Lift only support global resource bundles, i think it would be very useful if page and snipped level resource bundles were supported. For example, if i have a page index it would automatically have access to the indexlocale.properties_ bundle. Obviously this bundle would not be accessible from any other page. I come from an Apache Tapestry background that has page and component level localization and it proved very useful. What do you guys think about this ? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Support for page and snippet level localization
Come to think of it - if you really wanted to have a resource bundle for each page... you could do that using the resource bundle factories I listed earlier. Cheers, Tim On Feb 9, 5:38 pm, Timothy Perrett timo...@getintheloop.eu wrote: The analogy would be MVC controllers... the index method has an index page and an index resource bundle. Within Lift, we dont use controllers, so there is nothing stopping you calling a whole bunch of snippets on a single page - thus, there would be no single page resource bundle (that is, it wouldn't buy you anything IMHO) as different snippets might share localised text or whatever. I guess im just trying to say things are not silo'ed in Lift. Does that add some more clarity to my statement? Cheers, Tim On Feb 9, 2:47 pm, Hugo Palma hugo.m.pa...@gmail.com wrote: Sorry Tim but i don't quite understand what you mean by page is scoped to a single snippet and that invalidates that you have a resource bundle per page. Sorry is this is clear to everyone else but i'm new with Lift so i'm still grasping basic concepts. On Feb 8, 10:49 pm, Timothy Perrett timo...@getintheloop.eu wrote: That wouldn't work for Lift as it assumes a page is scoped to a single snippet. It works with Tapestry because its an MVC framework. Lift is *not* MVC. Have you seen LiftRules.resourceBundleFactories ? Cheers, Tim On 8 Feb 2010, at 22:11, Hugo Palma wrote: Lift only support global resource bundles, i think it would be very useful if page and snipped level resource bundles were supported. For example, if i have a page index it would automatically have access to the indexlocale.properties_ bundle. Obviously this bundle would not be accessible from any other page. I come from an Apache Tapestry background that has page and component level localization and it proved very useful. What do you guys think about this ? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Support for page and snippet level localization
Appreciate where you are coming from, however, the defaults are working quite well so perhaps it would be frugal to break some other boxed configurations into lift-localization or something... Such as page related resource bundles. Needs some thinking, but its certainly possible. Lift is extremely flexible in this regard. Cheers, Tim On 9 Feb 2010, at 17:52, Hugo Palma wrote: So what you're saying is that a page can include a bunch of snippets and that's why it doesn't be an advantage to have page resource bundles ? I'm sorry but i don't see why. I'm not sure how people are using resource bundles with Lift now but the way i would do it would be to create a resource bundle for each page that would have the properties that are specific to that page and then i would have one or more bundles with properties that would be used in several pages across the application. I think this makes sense in large applications because it's just a natural way of organizing your translated text. I realize this is possible with Lift now, but it has the following problems: - Even if you separate in bundles the properties are globally available. There's no bundle namespace concept. For example, i might want to have the property page-name with the current page name. And if i'm on the home page i want it to translate to Home and if i'm on the search page i want it to translate to Search. This could be possible with this. - I have to register every single resource bundle in LiftRules.resourceNames. Although not critical this could easily be replace with automatic bindle discovery like i suggested. On Tue, Feb 9, 2010 at 17:38, Timothy Perrett timo...@getintheloop.eu wrote: The analogy would be MVC controllers... the index method has an index page and an index resource bundle. Within Lift, we dont use controllers, so there is nothing stopping you calling a whole bunch of snippets on a single page - thus, there would be no single page resource bundle (that is, it wouldn't buy you anything IMHO) as different snippets might share localised text or whatever. I guess im just trying to say things are not silo'ed in Lift. Does that add some more clarity to my statement? Cheers, Tim On Feb 9, 2:47 pm, Hugo Palma hugo.m.pa...@gmail.com wrote: Sorry Tim but i don't quite understand what you mean by page is scoped to a single snippet and that invalidates that you have a resource bundle per page. Sorry is this is clear to everyone else but i'm new with Lift so i'm still grasping basic concepts. On Feb 8, 10:49 pm, Timothy Perrett timo...@getintheloop.eu wrote: That wouldn't work for Lift as it assumes a page is scoped to a single snippet. It works with Tapestry because its an MVC framework. Lift is *not* MVC. Have you seen LiftRules.resourceBundleFactories ? Cheers, Tim On 8 Feb 2010, at 22:11, Hugo Palma wrote: Lift only support global resource bundles, i think it would be very useful if page and snipped level resource bundles were supported. For example, if i have a page index it would automatically have access to the indexlocale.properties_ bundle. Obviously this bundle would not be accessible from any other page. I come from an Apache Tapestry background that has page and component level localization and it proved very useful. What do you guys think about this ? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Support for page and snippet level localization
mm im not sure who would take this on, as I think i've been doing most of the localisation stuff and I don't have capacity to do anything about this for quite some time unless it becomes an urgent priority. Any discussion must take place on this list, not on (or in) tickets, review board or otherwise. Right now, I think you could service the need yourself using locale calculator and resourceBundleFactories. To that end, the work we are talking about here is helpers rather than core functionality. Not to belittle it, as it could be quite useful - its just a case of working out what needs doing and where. Create a ticket in Assembla, mark it as webkit enhancement and assign it to me. I'll look at it, some when. Cheers, Tim On 9 Feb 2010, at 22:25, Hugo Palma wrote: I understand, just trying to share some of my own experience and ideas. So, should i create an issue for further discussion or do we just let it be ? On Tue, Feb 9, 2010 at 18:43, Timothy Perrett timo...@getintheloop.eu wrote: Appreciate where you are coming from, however, the defaults are working quite well so perhaps it would be frugal to break some other boxed configurations into lift-localization or something... Such as page related resource bundles. Needs some thinking, but its certainly possible. Lift is extremely flexible in this regard. Cheers, Tim On 9 Feb 2010, at 17:52, Hugo Palma wrote: So what you're saying is that a page can include a bunch of snippets and that's why it doesn't be an advantage to have page resource bundles ? I'm sorry but i don't see why. I'm not sure how people are using resource bundles with Lift now but the way i would do it would be to create a resource bundle for each page that would have the properties that are specific to that page and then i would have one or more bundles with properties that would be used in several pages across the application. I think this makes sense in large applications because it's just a natural way of organizing your translated text. I realize this is possible with Lift now, but it has the following problems: - Even if you separate in bundles the properties are globally available. There's no bundle namespace concept. For example, i might want to have the property page-name with the current page name. And if i'm on the home page i want it to translate to Home and if i'm on the search page i want it to translate to Search. This could be possible with this. - I have to register every single resource bundle in LiftRules.resourceNames. Although not critical this could easily be replace with automatic bindle discovery like i suggested. On Tue, Feb 9, 2010 at 17:38, Timothy Perrett timo...@getintheloop.eu wrote: The analogy would be MVC controllers... the index method has an index page and an index resource bundle. Within Lift, we dont use controllers, so there is nothing stopping you calling a whole bunch of snippets on a single page - thus, there would be no single page resource bundle (that is, it wouldn't buy you anything IMHO) as different snippets might share localised text or whatever. I guess im just trying to say things are not silo'ed in Lift. Does that add some more clarity to my statement? Cheers, Tim On Feb 9, 2:47 pm, Hugo Palma hugo.m.pa...@gmail.com wrote: Sorry Tim but i don't quite understand what you mean by page is scoped to a single snippet and that invalidates that you have a resource bundle per page. Sorry is this is clear to everyone else but i'm new with Lift so i'm still grasping basic concepts. On Feb 8, 10:49 pm, Timothy Perrett timo...@getintheloop.eu wrote: That wouldn't work for Lift as it assumes a page is scoped to a single snippet. It works with Tapestry because its an MVC framework. Lift is *not* MVC. Have you seen LiftRules.resourceBundleFactories ? Cheers, Tim On 8 Feb 2010, at 22:11, Hugo Palma wrote: Lift only support global resource bundles, i think it would be very useful if page and snipped level resource bundles were supported. For example, if i have a page index it would automatically have access to the indexlocale.properties_ bundle. Obviously this bundle would not be accessible from any other page. I come from an Apache Tapestry background that has page and component level localization and it proved very useful. What do you guys think about this ? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com
Re: [Lift] Re: Forcing Authentication not working
You need to be registered on assembla and watching the Lift space - we do that to avoid spam Cheers, Tim On 8 Feb 2010, at 09:18, aw wrote: On Feb 7, 11:31 pm, Marius marius.dan...@gmail.com wrote: Please open a defect herehttp://www.assembla.com/spaces/liftweb/tickets Would love to, but the New Ticket button does not seem to exist... Is this project configured correctly to accept non-teammate submissions? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Support for page and snippet level localization
That wouldn't work for Lift as it assumes a page is scoped to a single snippet. It works with Tapestry because its an MVC framework. Lift is *not* MVC. Have you seen LiftRules.resourceBundleFactories ? Cheers, Tim On 8 Feb 2010, at 22:11, Hugo Palma wrote: Lift only support global resource bundles, i think it would be very useful if page and snipped level resource bundles were supported. For example, if i have a page index it would automatically have access to the indexlocale.properties_ bundle. Obviously this bundle would not be accessible from any other page. I come from an Apache Tapestry background that has page and component level localization and it proved very useful. What do you guys think about this ? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Submit form on enter in textarea
In a textarea?!! Why on earth would you want to do that? I would imagine that you would need to use some kind of JQuery event binding that subsequently triggered an XHR form submit; you'd have to implement this as a JSON form on the server side id imagine though as im not sure how you'd hook into the default AJAX form stuff otherwise... perhaps marius could shed some light. Cheers, Tim On 8 Feb 2010, at 21:57, Heiko Seeberger wrote: Hi folks, this time *with* body and hopefully quite understandable: What's the most clever way to submit a (AJAX)form when ENTER is hit in a textarea? Thanks, Heiko -- Heiko Seeberger Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: HTTP Reason Phrase
Ah yes - keep forgetting one day we'll have netty et al providers! Interested to see what you come up with Marius Cheers, Tim On 8 Feb 2010, at 19:23, Marius wrote: I think it worth to add this support even if servlet API is a little weird sometimes but Lift HTTP API could provide a nicer support. Furthermore such Lift API support would be handy for non JEE containers therefore I'd vote for it. Erkky would you please open a defect (https://www.assembla.com/spaces/ liftweb/tickets) and assign it to me ? Br's, Marius On 8 feb., 21:08, David Pollak feeder.of.the.be...@gmail.com wrote: I think this issue rests with Marius. He's done most of the interface between Lift and the servlet containers. Let's see what he has to say. On Sun, Feb 7, 2010 at 2:47 PM, Erkki Lindpere vill...@gmail.com wrote: Ok. The feature is not really that important for me, just something that would be nice to have. I think some hack could be made with sendError(int, String) and web.xml config, but that would be worse than using the deprecated method. Erkki L On Feb 7, 11:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: I agree Ross... I would be very reluctant to have Lift rely on some deprecated method in the servlet spec - even if it is in servlet 3.0. Cheers, Tim On 7 Feb 2010, at 20:48, Ross Mellgren wrote: Yeah you're very correct. It's unfortunate, but I think since it's deprecated in the container we should probably not add support for it. I can't believe they deprecated it for the reason they did, but there it is. -Ross On Feb 7, 2010, at 8:16 AM, Erkki Lindpere wrote: Actually, the reason phrase is not a normal HTTP header, but part of the status line: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Examples: HTTP/1.1 200 OK HTTP/1.1 404 The user with id 8 does not exist The only way of setting this in Java Servlets as far as I know is through HttpServletResponse.setStatus(int, String), which unfortunately is deprecated. A non-deprecated possibility is sendError(int, String), but that goes to the container's default error page (or the one defined in web.xml, I think) so it's not exactly what I would like. Also, I checked that FireBug actually does display the custom reason phrase, but Chrome displays the standard one instead. Erkki L On Feb 7, 1:08 pm, Timothy Perrett timo...@getintheloop.eu wrote: If you want to alter the Reason-Phrase, you can already do that - objects like NotFoundResponse are just helpers on InMemoryResponse... nothing stopping you adding your own helpers that set headers with customised reason codes; this should give you what you what. I haven't managed to find an RFC that lists reason-phrase as anything but a particular header in the HTTP response. Moreover, its not the wrong thing to return a plain text response if the request mime was text/plain... indeed, it would be even less helpful if it returned JSON or such. IMHO, the response type should match what was asked for by the caller - i.e. its an implementation issue not a framework level issue. Tim On 6 Feb 2010, at 21:55, Erkki Lindpere wrote: The NotFoundResponse (and others) puts the custom message into the request body. That works as well, but to be really lean (mainly for bragging rights :)) I'd like to remove any unnecessary elements from the rest api. Most of the error messages are going to be simple one- line messages (and short sentences). For some errors I might provide a detailed response and it could go into the body, as XML/JSON/... That's inconsistent if the other errors have a plain text message in the body. So I could either go with structured details for all messages or in simple cases use the HTTP headers or status line. A custom header would work, but the status line is standard and also more easily accessed with some client libraries. And last but perhaps not least, for debugging purposes, the HTTP Reason Code should show up better in web developer tools (for example FireBug, Chrome's tools). My web UI also goes through the REST API so it would be nice to read error messages right in the listing in firebug's net panel. So I'm suggesting that perhaps Lift would like to provide only the possibility of changing that value in user code. But I completely understand if it doesn't. Currently it doesn't seem to be supported in Lift's http.provider package and even in javax.servlet the setStatus(int, String) method is deprecated (I'm not sure if sendError(int, String) uses the reason phrase). Erkki L On Feb 6, 9:59 pm, Ross Mellgren dri...@gmail.com wrote: I think it would be fine to have different text there, probably better than having the standard text if you have refined detail. I don't think it'd be a good idea to conditionalize on the response text in client code - that's always fragile. If you want
Re: [Lift] Support for page and snippet level localization
Generally I find that to be only of use when needed specific adjustments to templates. For instance, english vs german... the german language is significantly more verbose so requires different div heights etc sometimes. Its not generally a strategy one adopts for their entire localisation scheme. Cheers, Tim On 8 Feb 2010, at 22:52, Naftoli Gugenheim wrote: You can just have separate index html files for different locales, and when the user goes to /index (or / I suppose) Lift selects the correct one. - Hugo Palmahugo.m.pa...@gmail.com wrote: Lift only support global resource bundles, i think it would be very useful if page and snipped level resource bundles were supported. For example, if i have a page index it would automatically have access to the indexlocale.properties_ bundle. Obviously this bundle would not be accessible from any other page. I come from an Apache Tapestry background that has page and component level localization and it proved very useful. What do you guys think about this ? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: HTTP Reason Phrase
If you want to alter the Reason-Phrase, you can already do that - objects like NotFoundResponse are just helpers on InMemoryResponse... nothing stopping you adding your own helpers that set headers with customised reason codes; this should give you what you what. I haven't managed to find an RFC that lists reason-phrase as anything but a particular header in the HTTP response. Moreover, its not the wrong thing to return a plain text response if the request mime was text/plain... indeed, it would be even less helpful if it returned JSON or such. IMHO, the response type should match what was asked for by the caller - i.e. its an implementation issue not a framework level issue. Tim On 6 Feb 2010, at 21:55, Erkki Lindpere wrote: The NotFoundResponse (and others) puts the custom message into the request body. That works as well, but to be really lean (mainly for bragging rights :)) I'd like to remove any unnecessary elements from the rest api. Most of the error messages are going to be simple one- line messages (and short sentences). For some errors I might provide a detailed response and it could go into the body, as XML/JSON/... That's inconsistent if the other errors have a plain text message in the body. So I could either go with structured details for all messages or in simple cases use the HTTP headers or status line. A custom header would work, but the status line is standard and also more easily accessed with some client libraries. And last but perhaps not least, for debugging purposes, the HTTP Reason Code should show up better in web developer tools (for example FireBug, Chrome's tools). My web UI also goes through the REST API so it would be nice to read error messages right in the listing in firebug's net panel. So I'm suggesting that perhaps Lift would like to provide only the possibility of changing that value in user code. But I completely understand if it doesn't. Currently it doesn't seem to be supported in Lift's http.provider package and even in javax.servlet the setStatus(int, String) method is deprecated (I'm not sure if sendError(int, String) uses the reason phrase). Erkki L On Feb 6, 9:59 pm, Ross Mellgren dri...@gmail.com wrote: I think it would be fine to have different text there, probably better than having the standard text if you have refined detail. I don't think it'd be a good idea to conditionalize on the response text in client code - that's always fragile. If you want to give additional machine-readable detail, I'd put it in a response header or in the body as a JSON or XML field or what have you. You can specify custom text there, but you may have to sidestep the usual response classes, depending on which one. The one you gave, not found, can have the message customized though, just do new NotFoundResponse(the message). -Ross On Feb 6, 2010, at 2:52 PM, Erkki Lindpere wrote: It seems Lift does not support custom HTTP Reason Phrases in responses. I would like to send error messages in the Reason Phrase (along with a vaguely applicable HTTP status code) in a RESTful API I'm providing. My understanding of the HTTP spec is that the reason phrase is meant to be human readable and does not have to contain the recommended messages (i.e. Not Found). But maybe it would not be wise to do this? I'm not actually aware of any API-s that send error messages in the Reason Phrase. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
