[Lift] Re: Serious widget action

[Timothy Perrett]

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  wrote:
> On Mar 10, 1:15 am, Timothy Perrett  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: Serious widget action

[Timothy Perrett]

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  wrote:
>>> 
>>> Please see here
>>> http://groups.google.com/group/liftweb/browse_thread/thread/5e4f5e424d33db40/32cfb6752954?lnk=gst&q=ExtJs#32cfb6752954
>>> 
>>> I'd strongly encourage you to integrate ExtJs with Lift and
>>> potentially other frameworks. Depending on JS library licence we'd be
>>> happy to have integrations with other JS frameworks.
>>> 
>>> JsArtifacts should provide you the necessary abstractions for such
>>> integrations but if you run into problems, please let us know.
>>> 
>>> On Mar 10, 8:27 am, Jim Barrows  wrote:
 On Tue, Mar 9, 2010 at 8:45 PM, aw  wrote:
> It is time for me to add some serious widgets to my lift app.
 
> So far, I am most enamored by ExtJS.
> Another alternative could possibly be ZK.
 
> Does anybody have any experience with these frameworks?  Can you
> comment on why integrating them with Scala/Lift would be a bad idea
> (or not work)?
 
> I searched for some historical posts on ExtJS and discovered some
> threads about it's license and how it impacts inclusion in the lift
> framework.  Would a commercial license prohibit it from being a lift-
> widget submodule candidate?
 
> Does anybody have a better suggestion that you think can compete with
> ExtJS?
 
 I'm using ExtJS in anger at 0rk.  3.1.1 is nice.  3.0.0 is weird.  Some odd
 bugs being reported.  We're also getting some weird interactions with some
 other js libraries ( I won't mention it, it's not available anymore, and if
 it was it just leave you scarred) and CSS.  However, that's the other
 libraries fault more then ExtJS's.
 
 If you want something that looks and feels as close to a desktop app as you
 can get.. ExtJS can do the job well.  With Lift providing the JSON, it 
 would
 be hard to go wrong.  That said.. ExtJS is not an easy beast to learn.  
 It's
 even worse to try and L10N it easily.  I would not try and use just pieces
 of it, it's really not designed to do that.  It seems to me to be an all or
 nothing approach.  That's not say you can't use it piecemeal, I think you
 lose a lot of flexibility (especially in layout) that way.
 
 I wouldn't use it if left to my own devices though, unless I had a
 requirement for a desktop app on the web.  It's serious overkill.
 
 --
 James A Barrows
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> liftweb+unsubscr...@googlegroups.com.
>>> For more options, visit this group at 
>>> http://groups.google.com/group/liftweb?hl=en.
>>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from 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...@g

Re: [Lift] Serious widget action

[Timothy Perrett]

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: File Download

[Timothy Perrett]

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  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  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  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  wrote:
>> 
>>>>> Thanks Tim, that's exactly what I'm looking for!
>> 
>>>>> On Feb 14, 11:27 am, Timothy Perrett  wrote:
>> 
>>>>>> See:
>> 
>>>>>> http://blog.getintheloop.eu/2009/3/19/understandi

Re: [Lift] Re: Converting a null String to an empty String

[Timothy Perrett]

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] Converting a null String to an empty String

[Timothy Perrett]

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

[Timothy Perrett]

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

[Timothy Perrett]

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

[Timothy Perrett]

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


But on the other hand it happens not too often. I'm personally very
very happy with current productiveness using Lift + Jetty + JRebel.
But what happens when Zeroturnaround will turn back to Scala ? It is
quite possible that Scala will go mainstream. It might be viable
solution then.

Simple solution would be putting Menu building just before page
rendering in "development" mode. But i can live perfectly without that
as well (using JRebel).

On Mar 9, 9:37 am, Jeppe Nejsum Madsen  wrote:
On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett  
 wrote:
I'm afraid I agree with Marius... I'm just not sure on the benefit  
here over

JRebel?


My main pain point was changes to Sitemap. JRebel doesn't help you
here as it's fixed once Lift is booted...
/Jeppe


--
You received this message because you are subscribed to the Google  
Groups "Lift" group.

To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com 
.
For more options, visit this group 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

[Timothy Perrett]

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  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  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] lift-blog - lift based blogging app

[Timothy Perrett]

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

[Timothy Perrett]

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

[Timothy Perrett]

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.

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

[Timothy Perrett]

> > Back when I was doing Rails, the state of Rails' documentation was not
> > materially different from the current state of Lift's documentation with the
> > exception of DHH's awesome book (which is my all time favorite tech book).
> > Most of the online documentation was weak or non-existent.
>
> This is true, but *getting started* was extremely easy. A few very non-
> intimidating commands and you were up & running and making quick edits
> that appeared in real time. Once you started to dig a little deeper
> you ran into the problems you describe but by that point the fish was
> already on the hook.

See:
http://code.google.com/p/simple-build-tool/wiki/Processors

This is what I am working on with Mark Harrah. We will ultimately have
a simple "lift" command in the SBT shell... As i said before (and it
appears to have been ignored) we are working on this, and its going to
give us a very robust platform and vastly improve user experience.

> > While I'm not sure I 100% agree with Tim's "6 million dollar man" argument
> > about PDF, PDF is common and useful... Scribd (which is definitely in the
> > hip-cool-kids side of street) is built on PDF.
>
> PDF is great if you're making an ebook. It loses on every other score.
> I have to download it each time it's updated. I can't link into it
> from other sites.

HAHA... well i wont start an argument on that, i'll just say that we
as an organisation have tens of millions of dollars invested in PDF...
its not going anywhere from the IT eco-system and I generally disagree
with your points but I wont get into the finer points of electronic
document creation.

> > Okay... sorry... but this is a gratuitous swipe.  Ugly == Not Easy to Use.
> > Nope.  Sorry.  I don't buy this.
>
> It's because of this - it suggests that the people behind the docs
> don't have either the time or the inclination to attend to the little
> details, which implies that other details might also be overlooked. If
> making attractive & easy to read introductory materials isn't a
> priority for the developers, maybe they also don't care about making
> the rest of the experience pleasant.

Im not sure I agree (experience tells me developers are more
pragmatic), but I take your point.

> I haven't found this to be the case at all. I build a new ruby into a
> separate install prefix and gem install rails and I'm ready to go. I
> certainly don't have to deal with anything approaching the complexity
> and inscrutability of a 152 line pom.xml.

See above about SBT. Moreover, what was your feeling the first time
you saw a complex rake file? Im not defending maven, rather, just
think of the similar reaction.

> > I do 50% of my coding with Emacs and my fingers do the right thing.  Those
> > using TextMate or an IDE don't worry at all.
>
> I already hate having to navigate 3 directory levels in rails, even
> with ido mode. Three *more* tabs to each file doesn't sound like fun.

As was already discussed, its only 3 more levels if you use the java
package naming. Call it whatever you want.

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

[Timothy Perrett]

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

[Timothy Perrett]

Sorry Jeppe, but I disagree. The issue to date has been getting someone to work 
on it for free... The recession has worked against us here because people have 
been hand-to-mouth work wise, and couldn't spare time that wasn't paid for. 

I actually come from a marketing / design background, and have tried to move 
this aspect of Lift along, but its been problematic with designers not 
committing and so forth. Lift needs a rebrand / restyle, yes, however, its 
easier said than done.

Cheers, Tim


On 6 Mar 2010, at 10:00, Jeppe Nejsum Madsen wrote:

> I think the underlying problem here is that the Lift committers are
> mostly code geeks and not really into the visual aesthetics. Maybe this
> is a difference from the Rails community: I think a lot (not all of
> course) of Lift's users have a Java background which is usually not
> connected with great visual artwork. But many of the Rails guys (the few
> I've talked to at least), seems to come from design studios etc. where
> there's very much focus on design.

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

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

[Timothy Perrett]

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

Re: [Lift] Re: Response Optimizations too aggressive

[Timothy Perrett]

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  wrote:
> On Mar 4, 6:56 am, Naftoli Gugenheim  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: LiftRules.rewrite, 404 error

[Timothy Perrett]

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( 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  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: Lift security vulnerability

[Timothy Perrett]

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: Wow... Lift has some amazing stats

[Timothy Perrett]

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  wrote:
>> Folks,
>> 
>> I just looked at Lift's stats on ohloh.  (http://www.ohloh.net/p/liftweb)
>> A couple of key items:
>> 
>> Very large, active development team
>> 
>> Over the past twelve months, 33
>> developerscontributed new
>> code to
>>  Lift .
>> 
>> This is one of the largest open-source teams in the world, and is in the top
>> 2% of all project teams on Ohloh.
>> 
>> For this measurement, Ohloh considered only recent changes to the code. Over
>> the entire history of the project, 45 developers have contributed.
>> Increasing year-over-year development activity
>> 
>> Over the last twelve months, Lift  has seen
>> a substantial increase in activity. This is probably good sign that interest
>> in this project is rising, and that the open source community has embraced
>> this project.
>> 
>> Ohloh makes this determination by comparing total number of commits made by
>> all developers during the most recent twelve months with the same figure for
>> the twelve months before that. The number of developers and total lines of
>> code are not considered.
>> So, a big thanks to the community for driving Lift and another big thanks to
>> the Lift committers for adding so much to Lift!
>> 
>> Thanks,
>> 
>> David
>> 
>> --
>> Lift, the simply functional web frameworkhttp://liftweb.net
>> Beginning Scalahttp://www.apress.com/book/view/1430219890
>> Follow me:http://twitter.com/dpp
>> Surf the harmonics
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en.
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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

[Timothy Perrett]

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] Wow... Lift has some amazing stats

[Timothy Perrett]

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] Re: Customizing generated form elements without touching scala code

[Timothy Perrett]

It depends on your abstraction composition. Typically, I make sure that my 
business logic is separate from UI logic... this is just good design; its 
possible to abuse any tool or framework if you have no idea about proper 
software engineering. I wouldn't worry too much about that - the pattern itself 
is far cleaner than MVC.

Cheers, Tim

On 5 Mar 2010, at 14:21, Julian Backes wrote:

> Thank you for your answer, also thanks to Jeppe who posted the same solution.
> 
> > I disagree with the unglyness you are talking about just because
> > Snipets are UI elements.
> I already read that and although I don't want to start a discussion on this, 
> I want to share my opinion with you:
> I already read in some blog entries and also here on the mailing list that 
> lift completely avoids the problem of having business logic in your 
> views/templates.
> I think in general, this is a very good idea. On the other hand, many people 
> say snippets are part of the view. In almost all examples I found, you can 
> see business logic in the snippets. Is this really better now? I think you 
> are still mixing business logic and UI stuff, just on a different level. Of 
> course, you can seperate that but this adds unnecessary complexity to an 
> application.
> Or am I missing something? I'm still a beginner in the scala/lift world... :-)
> 
> Julian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en.
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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

[Timothy Perrett]

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  wrote:
>> aw  writes:
>>> 
>> 
>> 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

[Timothy Perrett]

Probally worth sticking this on the wiki

Cheers, Tim

Sent from my iPhone

On 2 Mar 2010, at 14:37, Jeppe Nejsum Madsen  wrote:


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

[Lift] Re: Documenting the source code / supplementing the API docs

[Timothy Perrett]

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

Re: [Lift] Re: The role of LiftRules

[Timothy Perrett]

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

Re: [Lift] Re: Logging, part 2

[Timothy Perrett]

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

Re: [Lift] [urgent] Master is fundamentally broken!!!!!!

[Timothy Perrett]

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

[Timothy Perrett]

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.

[Lift] Re: This is the style of SQL persistence that I like ...

[Timothy Perrett]

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  wrote:
> On Wed, Feb 24, 2010 at 1:27 PM, Timothy Perrett 
> wrote:
>
> > 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  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 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.
>
> --
> 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] [urgent] Master is fundamentally broken!!!!!!

[Timothy Perrett]

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.

Re: [Lift] This is the style of SQL persistence that I like ...

[Timothy Perrett]

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

[Timothy Perrett]

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] [urgent] Master is fundamentally broken!!!!!!

[Timothy Perrett]

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 
> {expression} 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  
> 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:
> 
> 
> // <![CDATA[
> jQuery(document).ready(function()
> {liftAjax.lift_successRegisterGC();});
> var lift_page = "F1075228527421HHA";
> // ]]>
> 
> 
> 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.

[Lift] Re: [urgent] Master is fundamentally broken!!!!!!

[Timothy Perrett]

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  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:
>
> > 
> > // <![CDATA[
> > jQuery(document).ready(function()
> > {liftAjax.lift_successRegisterGC();});
> > var lift_page = "F1075228527421HHA";
> > // ]]>
> > 
>
> > 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: Master is fundamentally broken!!!!!!

[Timothy Perrett]

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  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   
> 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 Perrett  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  
> >>> 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:
>
> >>>> 
> >>>> //<![CDATA[
> >>>> jQuery(document).ready(function()
> >>>> {liftAjax.lift_successRegisterGC();});
> >>>> var lift_page ="F1075228527421HHA";
> >>>> // ]]>
> >>>> 
>
> >>>> 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] Re: Master is fundamentally broken!!!!!!

[Timothy Perrett]

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




//<![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page ="F1075228527421HHA";
// ]]>



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

[Timothy Perrett]

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  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  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:
>
> > 
> > // <![CDATA[
> > jQuery(document).ready(function()
> > {liftAjax.lift_successRegisterGC();});
> > var lift_page = "F1075228527421HHA";
> > // ]]>
> > 
>
> > 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!!!!!!

[Timothy Perrett]

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  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:
>
> 
> // <![CDATA[
> jQuery(document).ready(function()
> {liftAjax.lift_successRegisterGC();});
> var lift_page = "F1075228527421HHA";
> // ]]>
> 
>
> 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] [urgent] Master is fundamentally broken!!!!!!

[Timothy Perrett]

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:


// <![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page = "F1075228527421HHA";
// ]]>


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

[Timothy Perrett]

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  wrote:
>> Jon, did it go through a discussion on the mailing list? I dont
>> remember seeing it? (and I cant find it in the archives if it was)
>> 
>> Anything like this really needs discussion on the mailing list as its
>> fundamental to the Lift story and we need to maintain a consistent
>> API.
>> 
>> Cheers, Tim
>> 
>> On Feb 23, 7:48 pm, Jonathan Hoffman  wrote:
>> 
>> 
>> 
>>> I originally added LiftRules.jQueryVersion, but I agree that this is a much 
>>> better solution.
>> 
>>> thanks,
>> 
>>> - Jon
>>> On Feb 23, 2010, at 6:00 AM, Marius wrote:
>> 
>>>> I opened this 
>>>> ticket:http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryve...
>> 
>>>> I realize that this would bring a slight breaking change but I believe
>>>> it is worth it.
>> 
>>>> Folks please speak up if you think otherwise.
>> 
>>>> Br's,
>>>> Marius
>> 
>>>> On Feb 23, 10:25 am, Marius  wrote:
>>>>> (yeah forgive me :) ...)
>> 
>>>>> On Feb 23, 10:18 am, Jeppe Nejsum Madsen  wrote:
>> 
>>>>>> +1 (and we might as well add 1.4.2 as well/instead :-)
>> 
>>>>>> On Tue, Feb 23, 2010 at 9:11 AM, Marius  wrote:
>>>>>>> Guys,
>> 
>>>>>>> This has been added not so long ago, and I am aware that I should
>>>>>>> express my perspective on this back then as now it might be too late.
>>>>>>> IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
>>>>>>> ResourceServer should not even be aware of the underlying JS framework
>>>>>>> thus the JQuery  name in LiftRules is very unsound to me.
>> 
>>>>>>> Here is other proposal of keeping things decoupled:
>> 
>>>>>>> .
>>>>>>> We currently have JQueryArtifacts which holds the JQuery
>>>>>>> implementation.
>> 
>>>>>>> We add in the JsArtifacts this:
>> 
>>>>>>> trait JsArtifacts {
>>>>>>>  ...
>>>>>>>  def version
>>>>>>> }
>> 
>>>>>>> then
>> 
>>>>>>> case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
>>>>>>>  def version = "1.3.2-min"
>>>>>>> }
>> 
>>>>>>> case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
>>>>>>>  def version = "1.4.1-min"
>>>>>>> }
>> 
>>>>>>> Then to select one or another we use the existent mechanism:
>> 
>>>>>>> LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
>>>>>>> can change this easily
>> 
>>>>>>> then in ResourceServer we can easily make the version selection.
>> 
>>>>>>> In this way LiftRules has no idea about JQuery, YUI etc  and it
>>>>>>> doesn't need to. it is only about feeding different implementations of
>>>>>>> JsArtifact.
>> 
>>>>>>> Thoughts?
>> 
>>>>>>> Br's,
>>>>>>> Marius
>> 
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google 
>>>>>>> Groups "Lift" group.
>>>>>>> To post to this group, send email to lift...@googlegroups.com.
>>>>>>> To unsubscribe from this group, send email to 
>>>>>>> liftweb+unsubscr...@googlegroups.com.
>>>>>>> For more options, visit this group 
>>>>>>> athttp://groups.google.com/group/liftweb?hl=en.
>> 
>>>> --
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "Lift" group.
>>>> To post to this group, send email to lift...@googlegroups.com.
>>>> To unsubscribe from this group, send email to 
>>>> liftweb+unsubscr...@googlegroups.com.
>>>> For more options, visit this group 
>>>> athttp://groups.google.com/group/liftweb?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en.
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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?

[Timothy Perrett]

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  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  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: What is LDAP doing in modules?

[Timothy Perrett]

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

[Lift] Re: What is LDAP doing in modules?

[Timothy Perrett]

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

[Lift] Re: What is LDAP doing in modules?

[Timothy Perrett]

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

[Timothy Perrett]

Jon, did it go through a discussion on the mailing list? I dont
remember seeing it? (and I cant find it in the archives if it was)

Anything like this really needs discussion on the mailing list as its
fundamental to the Lift story and we need to maintain a consistent
API.

Cheers, Tim

On Feb 23, 7:48 pm, Jonathan Hoffman  wrote:
> I originally added LiftRules.jQueryVersion, but I agree that this is a much 
> better solution.
>
> thanks,
>
> - Jon
> On Feb 23, 2010, at 6:00 AM, Marius wrote:
>
>
>
> > I opened this 
> > ticket:http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryve...
>
> > I realize that this would bring a slight breaking change but I believe
> > it is worth it.
>
> > Folks please speak up if you think otherwise.
>
> > Br's,
> > Marius
>
> > On Feb 23, 10:25 am, Marius  wrote:
> >> (yeah forgive me :) ...)
>
> >> On Feb 23, 10:18 am, Jeppe Nejsum Madsen  wrote:
>
> >>> +1 (and we might as well add 1.4.2 as well/instead :-)
>
> >>> On Tue, Feb 23, 2010 at 9:11 AM, Marius  wrote:
>  Guys,
>
>  This has been added not so long ago, and I am aware that I should
>  express my perspective on this back then as now it might be too late.
>  IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
>  ResourceServer should not even be aware of the underlying JS framework
>  thus the JQuery  name in LiftRules is very unsound to me.
>
>  Here is other proposal of keeping things decoupled:
>
>  .
>  We currently have JQueryArtifacts which holds the JQuery
>  implementation.
>
>  We add in the JsArtifacts this:
>
>  trait JsArtifacts {
>   ...
>   def version
>  }
>
>  then
>
>  case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
>   def version = "1.3.2-min"
>  }
>
>  case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
>   def version = "1.4.1-min"
>  }
>
>  Then to select one or another we use the existent mechanism:
>
>  LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
>  can change this easily
>
>  then in ResourceServer we can easily make the version selection.
>
>  In this way LiftRules has no idea about JQuery, YUI etc  and it
>  doesn't need to. it is only about feeding different implementations of
>  JsArtifact.
>
>  Thoughts?
>
>  Br's,
>  Marius
>
>  --
>  You received this message because you are subscribed to the Google 
>  Groups "Lift" group.
>  To post to this group, send email to lift...@googlegroups.com.
>  To unsubscribe from this group, send email to 
>  liftweb+unsubscr...@googlegroups.com.
>  For more options, visit this group 
>  athttp://groups.google.com/group/liftweb?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/liftweb?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: What is LDAP doing in modules?

[Timothy Perrett]

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  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] What is LDAP doing in modules?

[Timothy Perrett]

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.

Re: [Lift] Re: LiftRules.jQueryVersion ... :(

[Timothy Perrett]

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  wrote:
>> (yeah forgive me :) ...)
>> 
>> On Feb 23, 10:18 am, Jeppe Nejsum Madsen  wrote:
>> 
>> 
>> 
>>> +1 (and we might as well add 1.4.2 as well/instead :-)
>> 
>>> On Tue, Feb 23, 2010 at 9:11 AM, Marius  wrote:
 Guys,
>> 
 This has been added not so long ago, and I am aware that I should
 express my perspective on this back then as now it might be too late.
 IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
 ResourceServer should not even be aware of the underlying JS framework
 thus the JQuery  name in LiftRules is very unsound to me.
>> 
 Here is other proposal of keeping things decoupled:
>> 
 .
 We currently have JQueryArtifacts which holds the JQuery
 implementation.
>> 
 We add in the JsArtifacts this:
>> 
 trait JsArtifacts {
  ...
  def version
 }
>> 
 then
>> 
 case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
  def version = "1.3.2-min"
 }
>> 
 case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
  def version = "1.4.1-min"
 }
>> 
 Then to select one or another we use the existent mechanism:
>> 
 LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
 can change this easily
>> 
 then in ResourceServer we can easily make the version selection.
>> 
 In this way LiftRules has no idea about JQuery, YUI etc  and it
 doesn't need to. it is only about feeding different implementations of
 JsArtifact.
>> 
 Thoughts?
>> 
 Br's,
 Marius
>> 
 --
 You received this message because you are subscribed to the Google Groups 
 "Lift" group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en.
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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

[Timothy Perrett]

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] anybody used OPA?

[Timothy Perrett]

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] Re: Setting run mode for Lift applications

[Timothy Perrett]

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  
> 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
> >  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] Re: Setting run mode for Lift applications

[Timothy Perrett]

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
>  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: London Lift talk

[Timothy Perrett]

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: Documenting the source code / supplementing the API docs

[Timothy Perrett]

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

Re: [Lift] Versions: Netbeans, Scala and Lift

[Timothy Perrett]

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: Setting run mode for Lift applications

[Timothy Perrett]

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] Re: London Lift talk

[Timothy Perrett]

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  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] Documenting the source code / supplementing the API docs

[Timothy Perrett]

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] translate doc to Russian

[Timothy Perrett]

My bad, I thought he was referring to the wiki!

Cheers, Tim

On 18 Feb 2010, at 17:44, David Pollak wrote:

> 
> 
> On Thu, Feb 18, 2010 at 6:38 AM, Timothy Perrett  
> wrote:
> Adel,
> 
> This is certainly NOT against any copyright...
> 
> Actually, technically it is a violation of the license: 
> http://creativecommons.org/licenses/by-nd/3.0/  By, I give my permission (and 
> a hearty "THANK YOU!!") to make a derivative work (translation) of the work.  
> I'll ping Derek and Tyler to get their permission.  Marius still reads this 
> list so he can choose to grant permission (or not.)
>  
> in fact, we welcome such an effort!
> 
> We certainly do.  Sorry for being pedantic above, but, well, I was trained to 
> be pedantic.
>  
> 
> Thanks for your work on this.
> 
> Cheers, Tim
> 
> On 18 Feb 2010, at 09:52, Adel Chepkunov wrote:
> 
> > Hello all!
> >
> > I start translate "Starting with Lift" on
> > http://translated.by/you/starting-with-lift/into-ru/trans/?page=1
> >
> > I not violate copyrights?
> >
> > And if it ok, can you help me? In this server You can login via
> > OpenId, so You not need create new account.
> >
> > Sorry for my bad English
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from 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] Re: Another convert

[Timothy Perrett]

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:


 

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  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] Implementing "You are here:"

[Timothy Perrett]

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
>  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] Another convert

[Timothy Perrett]

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] translate doc to Russian

[Timothy Perrett]

Adel,

This is certainly NOT against any copyright... in fact, we welcome such an 
effort!

Thanks for your work on this.

Cheers, Tim

On 18 Feb 2010, at 09:52, Adel Chepkunov wrote:

> Hello all!
> 
> I start translate "Starting with Lift" on
> http://translated.by/you/starting-with-lift/into-ru/trans/?page=1
> 
> I not violate copyrights?
> 
> And if it ok, can you help me? In this server You can login via
> OpenId, so You not need create new account.
> 
> Sorry for my bad English
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from 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

[Timothy Perrett]

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.

[Lift] Re: [urgent] Broken lift-record

[Timothy Perrett]

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  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)
>
>       { String.valueOf(res1) } ++ { String.valueOf(res2) 
> }
>
> 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  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() ?
>
> >>> Cheers, Tim
>
> >>> On Feb 17, 5:46 pm, Ross Mellgren  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: FieldVa

[Lift] Re: [urgent] Broken lift-record

[Timothy Perrett]

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  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() ?
>
> > Cheers, Tim
>
> > On Feb 17, 5:46 pm, Ross Mellgren  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

[Timothy Perrett]

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

Cheers, Tim

On Feb 17, 5:46 pm, Ross Mellgren  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] [urgent] Broken lift-record

[Timothy Perrett]

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.

Re: [Lift] setuid

[Timothy Perrett]

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  wrote:
>> On Wed, Feb 17, 2010 at 3:40 PM, trizk  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.

Re: [Lift] Re: thread [Image upload and serving example]

[Timothy Perrett]

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

Re: [Lift] Context path, proxies & Lift

[Timothy Perrett]

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  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   
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] Context path, proxies & Lift

[Timothy Perrett]

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  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] Lift Record

[Timothy Perrett]

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] Nginx, Jetty & multiple contexts

[Timothy Perrett]

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
>  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] Nginx, Jetty & multiple contexts

[Timothy Perrett]

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

[Lift] Lift Record

[Timothy Perrett]

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

[Timothy Perrett]

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  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: Page transition using location.replace

[Timothy Perrett]

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  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] Improvements to Lift-Json

[Timothy Perrett]

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] File Download

[Timothy Perrett]

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] Page transition using location.replace

[Timothy Perrett]

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] Re: How do I build reusable modules for lift?

[Timothy Perrett]

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  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  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] Re: JsCmds disabled inputs do not submit information

[Timothy Perrett]

Correct - they don't.

Sent from my iPhone

On 14 Feb 2010, at 00:24, ngocdaothanh  wrote:


I think it is the browsers that don't send values of disabled inputs.


On Feb 14, 2:46 am, Marius  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  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.

Re: [Lift] Re: very excited about 2.0

[Timothy Perrett]

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

[Timothy Perrett]

Seems like this conversation is diverging somewhat. 

Can I suggest there are two things in play here, and they address different 
problems.

1. Stopping the caching of resource files for an application build; the 
proposed solution is an md5 of the file contents so that the value persists 
application restarts (or with whatever random string)

2. Consolidation of CSS files on a given page for performance firstly, and 
secondly for caching.

Would there be times when people would not want the behaviour of 2? Im 
generally not a huge fan of things that mess with user code or could provide 
uneasy behaviour; im thinking specifically when people build there templates 
where CSS values are overridden by values loaded after initial value ad unless 
its munged together right, it might damage the expected behaviour (think 
blueprint)...? Can I suggest we solve the caching problem using the known hack 
of random strings, then deal with this proposal of resource consolidation?

Cheers

Tim


On 13 Feb 2010, at 08:45, Marius wrote:

> 
> 
> On 12 feb., 23:04, Alex Black  wrote:
>>> Yes, that's how it should work if everything was configured correctly
>>> (which I think it wasn't for the OP)
>> 
>> Heh, I'm the OP.
>> 
>> I'll have to dig into why its not working as expected I guess.
>> 
>>> But what we were discussing (at least I was :-) was more that Lift
>>> should serve resources with an "Expires" date in the far future. That
>>> way the browser will only make a single request for a resource (as
>>> long as the file is cached). This works well for returning visitors.
>>> But of course an updated resource should be fetched, hence the unique
>>> filenames.
>> 
>> There are some things I like about that solution, but the unique
>> filenames just seems wrong.
>> 
>> So I see that a far in the future expires works, but the reason you
>> need the unique filenames is because it doesn't really work. The far
>> in the future expires says "you can cache this for a long time cause
>> it won't change".
>> 
>> The other option is say "you can cache this for like the next hour"
>> but every time you fetch it, you can tell me when you last got it
>> (conditional GET), and I won't send it to you if it hasn't changed
>> (304 not modified).  This results in more requests, but no need for
>> unique filenames or anything, instead if the file changes then the
>> server will serve it up to whoever needs it.
> 
> It doesn't sound like today this solution is consistent on all "major"
> browsers. Can you confirm that it does?
> I used the query string solution in the past (like many others) and
> this works reasonably well. It is not a perfect solution
> but better then today. Besides if we want to adopt a different
> solution that would be pretty easy because this knowledge will be
> built
> in the snippet and the user code wont really change.
> 
>> 
>>> Combining individual files will improve load times for first time
>>> visitors by reducing the number of requests.
>> 
>> That sounds like a great idea.. would like the same thing for JS.
>> Does the YUI compressor tool that lift uses with maven have this type
>> of feature? I Thought I read that it did.
>> 
>> 
>> 
>> 
>> 
>>> /Jeppe
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group 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: Cached CSS (and Javascript?) issue

[Timothy Perrett]

This is pretty much what rails does. Straight from github:




It would be nice to provide some kind of generic helper snippet for this. Some 
hash that is configured on boot up would be great; provide some function in 
lift rules to alter the behaviour and away we go. Perhaps something like:



Thoughts?

Cheers, Tim


On 12 Feb 2010, at 18:53, Jeppe Nejsum Madsen wrote:

> On Fri, Feb 12, 2010 at 7:28 PM, Marius  wrote:
>> Oh yes I did and I hate it. Ironically I was about to propose a
>> solution for this.
>> 
>> instead of
>> 
>> 
>> 
>> do something like:
>> 
>> 
>> 
>> this would render:
>> 
>> 
>> 
>> the query string parameter would be generated at application start-up.
>> If you update you css/js and restart the application the browser will
>> refresh it. Potentially generating the random query string param could
>> be a LiftRules function that by default generates a sequence once per
>> application time. Thus you could potentially set your own function
>> that reads this for a config file?
>> 
>> Similarly  would do the same.
> 
> I had similar thoughts sometime ago, but haven't looked at it since then:
> 
> http://groups.google.com/group/liftweb/browse_thread/thread/1130ce4f9d5af010/a36c52fde3b2bc5b?lnk=gst&q=jeppe++cache&pli=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.

[Lift] Re: lift-couchdb pushed to master

[Timothy Perrett]

Congratulations Ross.

Cheers, Tim

On Feb 12, 5:07 am, Ross Mellgren  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: lifecycle callbacks in record

[Timothy Perrett]

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] Re: lifecycle callbacks in record

[Timothy Perrett]

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  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: Problems with SBT

[Timothy Perrett]

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

Re: [Lift] Re: Problems with SBT

[Timothy Perrett]

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  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  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
>> 
>>>  
>>>2.7.7
>>>  
>> 
>>> ...
>> 
>>>
>>>   net.liftweb
>>>   lift-mapper
>>>   2.0-M1
>>>
>>>
>>>   net.liftweb
>>>   lift-widgets
>>>   2.0-M1
>>>
>>>
>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> li

Re: [Lift] very excited about 2.0

[Timothy Perrett]

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] Problems with SBT

[Timothy Perrett]

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
> 
>  
>2.7.7
>  
> 
> ...
> 
>
>   net.liftweb
>   lift-mapper
>   2.0-M1
>
>
>   net.liftweb
>   lift-widgets
>   2.0-M1
>
>
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from 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

[Timothy Perrett]

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

Re: [Lift] Re: Support for page and snippet level localization

[Timothy Perrett]

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

[Lift] Re: Support for page and snippet level localization

[Timothy Perrett]

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

[Timothy Perrett]

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