[Lift] Re: NetBeans is barfing on the new pom.xml structure
I ran into that -it's a missing version number in the root pom. Fixed in my kjn-loc-wip branch if you just want to grab it from there. On Fri, Oct 23, 2009 at 3:41 PM, David Pollak wrote: > Folks, > > Any idea why NetBeans doesn't like the new Lift pom structure? > > 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 liftweb@googlegroups.com To unsubscribe from 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: catch a URL
Great suggestions - thanks guys!
Jeppe Nejsum Madsen wrote:
> Timothy Perrett writes:
>
>> Ah. In that case, does this help:
>>
>> Menu(Loc("Some", List("some","page"), "Some",
>>EarlyResponse(() => {
>> // do some response here,
>> // return Empty if you dont want
>> // a response but a filter style
>> // intercept.
>> Empty
>>})
>> ))
>>
>> Does that help?
>
> Or, if you just need to run some code before a template is rendered:
>
> Menu(Loc("test", List("landing"), "test", Template{() =>
> println("Hit the template URL");
> // Handle Empty case :-)
>
> TemplateFinder.findAnyTemplate(List("mytemplat","index")).open_!
>}))
>
> /Jeppe
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from 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] Playing around with Loc
Hi, all, I've been messing around with Loc a bit to try to tighten up the type safety of the parameterized type and add authentication LocParams that can be aware of the current value encapsulated by the Loc. I've put up some changes on the kjn-loc-wip branch and would really like some feedback. Some of the major changes: * gave LocParam a covariant type parameter to go with Loc's type parameter and made it a sealed trait, with UserLocParam[T] as the main extension point for user-defined traits. Added AnyLocParam as base trait of LocParam instances that are not dependent upon T * Added IfValue & UnlessValue LocParams * Made default Loc parameterized by Unit instead of NullLocParams * Some minor renaming to distinguish between uses of the "Param" name- - now all Param usages refer to LocParams * Removed need for a bunch of asInstanceOf casts What do you all think? Is this something that you'd like to see cleaned up & committed to master? Thanks, --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: Are we willing to make a breaking change for Joda Time?
I'll make these changes and work on improving the internal implementation of
TimeSpan and TimeHelpers to work better within the existing method
signatures, but I want to be clear that I'm extremely unhappy that I can't
be accommodated otherwise.
Thanks,
Derek
On Fri, Oct 23, 2009 at 5:05 PM, David Pollak wrote:
>
>
> On Fri, Oct 23, 2009 at 3:53 PM, Derek Chen-Becker
> wrote:
>
>> I could do that, but I would still have an ambiguous definition of "now",
>> "today", "epoch", etc if I want to use Joda Time and the requirement is that
>> an import Helpers._ cannot conflict.
>
>
> now, today and epoch are not part of TimeSpan.
>
> Update TimeSpan to *internally* use Periods. Don't break the interface to
> TimeSpan. If you add methods to TimeSpan, that's fine.
>
> Please add additional methods to TimeHelpers that support returning the
> JodaTime equivalents of what now, today, and epoch return.
>
>
>> The whole reason that I want to write a separate trait is that Lift
>> currently has some nice convenience methods and a DSL in TimeHelpers, but
>> they all return java.util.{Calendar,Date}. I'm just trying to mirror the API
>> usage, except have everything return Joda Time classes instead. That way, I
>> can upgrade all of my current Lift apps to use Joda Time simply by changing
>> the import. It's entirely subjective, but I just strongly dislike the idea
>> of using method names like jtNow, etc. Anthony brings up a good point about
>> Joda Time in large part becoming the new Java Date/Time API, but we can
>> always deal with that when it comes along.
>>
>> Derek
>>
>>
>> On Fri, Oct 23, 2009 at 4:00 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
Period is field-based, and therefore deals with non-linear time changes
like daylight savings time. Periods can be converted to millisecond
durations based on "standard" field durations (60 seconds == 1 minute, etc)
if needed, so it's a superset of the current functionality of TimeSpan.
>>>
>>> So, why not make TimeSpan use Period, but preserve the interface so you
>>> can build one with millis and get it to spit out millis or Period as the
>>> case may be?
>>>
>>>
On Fri, Oct 23, 2009 at 3:37 PM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:
>
>
> On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker <
> dchenbec...@gmail.com> wrote:
>
>> Well, I had intended to write a JodaHelpers trait that is the same as
>> Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
>> TimeHelpers and TimeFormats, respectively. The main reason is that I
>> would
>> like to have the time DSL be based on Periods instead of millisecond
>> durations, and with TimeHelpers already in scope there would be ambiguous
>> implicit conversions from Long/Int to TimeSpan or Period.
>
>
> What is the advantage of using Period internally instead of
> milliseconds?
>
>
>> Supposedly, 2.8 will have some support for masking or overriding
>> implicits, but I don't want to rely on that in the short term. If a
>> JodaHelpers trait that would replace a Helpers import isn't OK then I can
>> just do this in my own repo.
>>
>> Thanks,
>>
>> Derek
>>
>>
>> On Fri, Oct 23, 2009 at 2:52 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
It sounds like you're pretty set against making separate impl traits
and would prefer just putting things directly on TimeHelper. I'm OK
with
that, but I would really like to add a lift-joda module that contains
the
JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would
like to
use them. I should be able to delegate a good chunk of the methods to
TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
reasonable compromise?
>>>
>>> Yes, as long as import Helpers._ is not incompatible with importing
>>> whatever trait you come up with.
>>>
>>>
Derek
On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker <
dchenbec...@gmail.com> wrote:
> I agree that the goal isn't to remove java.util.Date. For trivial
> time handling it works just fine. What I'm trying to achieve here is
> a way
> to make Joda Time be the default impl while leaving the user a
> choice. By
> using separate traits instead of different names on the same trait, we
> achieve a few things:
>
>1. A consistent API for both java.util and Joda Time in terms
>of method names. As Naftoli pointed out
[Lift] Re: Are we willing to make a breaking change for Joda Time?
On Fri, Oct 23, 2009 at 3:53 PM, Derek Chen-Becker wrote:
> I could do that, but I would still have an ambiguous definition of "now",
> "today", "epoch", etc if I want to use Joda Time and the requirement is that
> an import Helpers._ cannot conflict.
now, today and epoch are not part of TimeSpan.
Update TimeSpan to *internally* use Periods. Don't break the interface to
TimeSpan. If you add methods to TimeSpan, that's fine.
Please add additional methods to TimeHelpers that support returning the
JodaTime equivalents of what now, today, and epoch return.
> The whole reason that I want to write a separate trait is that Lift
> currently has some nice convenience methods and a DSL in TimeHelpers, but
> they all return java.util.{Calendar,Date}. I'm just trying to mirror the API
> usage, except have everything return Joda Time classes instead. That way, I
> can upgrade all of my current Lift apps to use Joda Time simply by changing
> the import. It's entirely subjective, but I just strongly dislike the idea
> of using method names like jtNow, etc. Anthony brings up a good point about
> Joda Time in large part becoming the new Java Date/Time API, but we can
> always deal with that when it comes along.
>
> Derek
>
>
> On Fri, Oct 23, 2009 at 4:00 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker > > wrote:
>>
>>> Period is field-based, and therefore deals with non-linear time changes
>>> like daylight savings time. Periods can be converted to millisecond
>>> durations based on "standard" field durations (60 seconds == 1 minute, etc)
>>> if needed, so it's a superset of the current functionality of TimeSpan.
>>>
>>
>> So, why not make TimeSpan use Period, but preserve the interface so you
>> can build one with millis and get it to spit out millis or Period as the
>> case may be?
>>
>>
>>>
>>> On Fri, Oct 23, 2009 at 3:37 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>
On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker <
dchenbec...@gmail.com> wrote:
> Well, I had intended to write a JodaHelpers trait that is the same as
> Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
> TimeHelpers and TimeFormats, respectively. The main reason is that I would
> like to have the time DSL be based on Periods instead of millisecond
> durations, and with TimeHelpers already in scope there would be ambiguous
> implicit conversions from Long/Int to TimeSpan or Period.
What is the advantage of using Period internally instead of
milliseconds?
> Supposedly, 2.8 will have some support for masking or overriding
> implicits, but I don't want to rely on that in the short term. If a
> JodaHelpers trait that would replace a Helpers import isn't OK then I can
> just do this in my own repo.
>
> Thanks,
>
> Derek
>
>
> On Fri, Oct 23, 2009 at 2:52 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> It sounds like you're pretty set against making separate impl traits
>>> and would prefer just putting things directly on TimeHelper. I'm OK with
>>> that, but I would really like to add a lift-joda module that contains
>>> the
>>> JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like
>>> to
>>> use them. I should be able to delegate a good chunk of the methods to
>>> TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
>>> reasonable compromise?
>>>
>>
>> Yes, as long as import Helpers._ is not incompatible with importing
>> whatever trait you come up with.
>>
>>
>>>
>>> Derek
>>>
>>>
>>> On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
I agree that the goal isn't to remove java.util.Date. For trivial
time handling it works just fine. What I'm trying to achieve here is a
way
to make Joda Time be the default impl while leaving the user a choice.
By
using separate traits instead of different names on the same trait, we
achieve a few things:
1. A consistent API for both java.util and Joda Time in terms of
method names. As Naftoli pointed out, people expect naming of
functions
consistent with what they do and having two different "now"s on the
same
trait is going to look a little strange to people, I think.
2. A clean *optional* usage of Joda Time. If we put code that
utilizes Joda Time directly into TimeHelpers then it's not an
optional
dependency. Making a separate trait means that if someone doesn't
use the
Joda
[Lift] In the spirit of Friday, anyone want to see this ruby rack ported to lift?
http://coderack.org/users/MetaSkills/entries/15-zombie-shotgun and yes, I'm volunteering. :) -- 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 liftweb@googlegroups.com To unsubscribe from 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: Are we willing to make a breaking change for Joda Time?
I could do that, but I would still have an ambiguous definition of "now",
"today", "epoch", etc if I want to use Joda Time and the requirement is that
an import Helpers._ cannot conflict. The whole reason that I want to write a
separate trait is that Lift currently has some nice convenience methods and
a DSL in TimeHelpers, but they all return java.util.{Calendar,Date}. I'm
just trying to mirror the API usage, except have everything return Joda Time
classes instead. That way, I can upgrade all of my current Lift apps to use
Joda Time simply by changing the import. It's entirely subjective, but I
just strongly dislike the idea of using method names like jtNow, etc.
Anthony brings up a good point about Joda Time in large part becoming the
new Java Date/Time API, but we can always deal with that when it comes
along.
Derek
On Fri, Oct 23, 2009 at 4:00 PM, David Pollak wrote:
>
>
> On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker
> wrote:
>
>> Period is field-based, and therefore deals with non-linear time changes
>> like daylight savings time. Periods can be converted to millisecond
>> durations based on "standard" field durations (60 seconds == 1 minute, etc)
>> if needed, so it's a superset of the current functionality of TimeSpan.
>>
>
> So, why not make TimeSpan use Period, but preserve the interface so you can
> build one with millis and get it to spit out millis or Period as the case
> may be?
>
>
>>
>> On Fri, Oct 23, 2009 at 3:37 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
Well, I had intended to write a JodaHelpers trait that is the same as
Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
TimeHelpers and TimeFormats, respectively. The main reason is that I would
like to have the time DSL be based on Periods instead of millisecond
durations, and with TimeHelpers already in scope there would be ambiguous
implicit conversions from Long/Int to TimeSpan or Period.
>>>
>>>
>>> What is the advantage of using Period internally instead of milliseconds?
>>>
>>>
Supposedly, 2.8 will have some support for masking or overriding
implicits, but I don't want to rely on that in the short term. If a
JodaHelpers trait that would replace a Helpers import isn't OK then I can
just do this in my own repo.
Thanks,
Derek
On Fri, Oct 23, 2009 at 2:52 PM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:
>
>
> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker <
> dchenbec...@gmail.com> wrote:
>
>> It sounds like you're pretty set against making separate impl traits
>> and would prefer just putting things directly on TimeHelper. I'm OK with
>> that, but I would really like to add a lift-joda module that contains the
>> JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like
>> to
>> use them. I should be able to delegate a good chunk of the methods to
>> TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
>> reasonable compromise?
>>
>
> Yes, as long as import Helpers._ is not incompatible with importing
> whatever trait you come up with.
>
>
>>
>> Derek
>>
>>
>> On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> I agree that the goal isn't to remove java.util.Date. For trivial
>>> time handling it works just fine. What I'm trying to achieve here is a
>>> way
>>> to make Joda Time be the default impl while leaving the user a choice.
>>> By
>>> using separate traits instead of different names on the same trait, we
>>> achieve a few things:
>>>
>>>1. A consistent API for both java.util and Joda Time in terms of
>>>method names. As Naftoli pointed out, people expect naming of
>>> functions
>>>consistent with what they do and having two different "now"s on the
>>> same
>>>trait is going to look a little strange to people, I think.
>>>2. A clean *optional* usage of Joda Time. If we put code that
>>>utilizes Joda Time directly into TimeHelpers then it's not an
>>> optional
>>>dependency. Making a separate trait means that if someone doesn't
>>> use the
>>>Joda Time trait then they don't need to have the Joda Time jar in
>>> their
>>>classpath and they never know that it's not there.
>>>3. A relatively simple code change path to move from java.util to
>>>Joda Time by simply changing imports.
>>>
>>> Your assertion that Date is a simple wrapper for a Long timestamp is
>>> pretty accurate, but really Joda Time's DateTime is a superset of
>>> *Calendar*, not Date. Just look at what we had to do with
>>> CalendarExtension
>>> to get some simple date m
[Lift] Re: A Critique On Lift
On Fri, Oct 23, 2009 at 3:28 PM, Viktor Klang wrote: > On Sat, Oct 24, 2009 at 12:23 AM, Jim Barrows wrote: > >> On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang wrote: >> >>> But if you name your method: "ashiuahsdyasdasd" what does it do? >>> >> >> Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read >> it >> > > Chtuluh ftagn! ;D > Huh. Now he's 6 inches tall and has a red nose interesting. Also I think we've made our point about cryptic method names whether there alphanumeric or not, whether you call them operators or not... are problematic. Now excuse me... cthulu appears to be mucking with my code 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 liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
On Sat, Oct 24, 2009 at 12:23 AM, Jim Barrows wrote: > > > On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang wrote: > >> But if you name your method: "ashiuahsdyasdasd" what does it do? >> > > Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read > it > Chtuluh ftagn! ;D > > >> >> On Fri, Oct 23, 2009 at 9:47 PM, bob wrote: >> >>> >>> >I'll repeat: there are no operators in scala >>> >>> s/operators/methods-with-operator-like-names/ >>> >>> anywhere, here's a typical case: >>> >>> import some.library.package.foo._ >>> >>> val a = bar 42 >>> val b = a ~!~ 3.14159 >>> >>> you can't easily tell that bar is being imported via foo._ . >>> what is bar's return type? >>> what does ~!~ do? >>> >>> i'm not saying its not possible to track all this down, but you can't >>> just print out a listing of a class and take it on the subway. you >>> have to have access to the scaladocs and possibly even the sources. >>> >>> --b >>> >>> >>> >>> >>> >> >> >> -- >> Viktor Klang >> | "A complex system that works is invariably >> | found to have evolved from a simple system >> | that worked." - John Gall >> >> Blog: klangism.blogspot.com >> Twttr: viktorklang >> Code: github.com/viktorklang >> >> >> > > > -- > James A Barrows > > > > > > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Blog: klangism.blogspot.com Twttr: viktorklang Code: github.com/viktorklang --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: SLF4J Logging for my classes
Sure, I could create a trait as you suggested... But, this sounds like a common problem -- does this not already exist? I see discussions about adding it to Scala, but I don't think it exists. And Lift already has a logging infrastructure (i.e. LogBoot as you suggest). Does it not make sense to add this trait to lift-util or lift-common? (I just want to avoid recreating the wheel.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang wrote: > But if you name your method: "ashiuahsdyasdasd" what does it do? > Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read it > > On Fri, Oct 23, 2009 at 9:47 PM, bob wrote: > >> >> >I'll repeat: there are no operators in scala >> >> s/operators/methods-with-operator-like-names/ >> >> anywhere, here's a typical case: >> >> import some.library.package.foo._ >> >> val a = bar 42 >> val b = a ~!~ 3.14159 >> >> you can't easily tell that bar is being imported via foo._ . >> what is bar's return type? >> what does ~!~ do? >> >> i'm not saying its not possible to track all this down, but you can't >> just print out a listing of a class and take it on the subway. you >> have to have access to the scaladocs and possibly even the sources. >> >> --b >> >> >> >> >> > > > -- > Viktor Klang > | "A complex system that works is invariably > | found to have evolved from a simple system > | that worked." - John Gall > > Blog: klangism.blogspot.com > Twttr: viktorklang > Code: github.com/viktorklang > > > > -- 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 liftweb@googlegroups.com To unsubscribe from 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: Security Explained
Thank you for this, and so quickly! I was able to leverage this for what I needed. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: Are we willing to make a breaking change for Joda Time?
> That's pretty much my take. The whole Java Calendar/Date/Timezone impl is > poorly designed, hence Joda Time. I like Joda Time too, and used to be apprehensive about integrating it as a dependency into my projects -- at least for simple things that I could probably do with Date/Calendar, just more hassle... But I am less apprehensive now that I know that Stephen Colebourne from Joda- Time is developing JSR-310 (https://jsr-310.dev.java.net/) -- a new Date and Time API for Java 7. If you look at the API, the new javax.time is basically stealing (I mean integrating) all of the best parts of Joda-Time. Now, I am happily using org.joda.time.LocalDate because I know that eventually, I will just need to change my imports to upgrade to javax.time.calendar.LocalDate. I haven't had a close look at Scala-Time, but I am not sure if I understand the value when using straight Joda Time with Scala was so painless. But I am sure there is room to leverage Scala features for things like implicit conversions. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
But if you name your method: "ashiuahsdyasdasd" what does it do? On Fri, Oct 23, 2009 at 9:47 PM, bob wrote: > > >I'll repeat: there are no operators in scala > > s/operators/methods-with-operator-like-names/ > > anywhere, here's a typical case: > > import some.library.package.foo._ > > val a = bar 42 > val b = a ~!~ 3.14159 > > you can't easily tell that bar is being imported via foo._ . > what is bar's return type? > what does ~!~ do? > > i'm not saying its not possible to track all this down, but you can't > just print out a listing of a class and take it on the subway. you > have to have access to the scaladocs and possibly even the sources. > > --b > > > > > > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Blog: klangism.blogspot.com Twttr: viktorklang Code: github.com/viktorklang --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: Testing for SQL Server drivers
Ahhh sorry I didn't see this before - I'm using lift mapper with SQL server at work. I can test this no worries. Just let me know what I should try ;-) Cheers, Tim Sent from my iPhone On 23 Oct 2009, at 21:18, Derek Chen-Becker wrote: > I'm pretty much 100% linux at home. I can test any other database > (Oracle, MySQL, PostgreSQL, etc), but SQL Server is the exception :) > > On Fri, Oct 23, 2009 at 2:14 PM, Naftoli Gugenheim > wrote: > 100%. Just curious. :) > > > On Fri, Oct 23, 2009 at 4:05 PM, David Pollak > wrote: > > > On Fri, Oct 23, 2009 at 12:10 PM, Naftoli Gugenheim > wrote: > Don't you have a Windows machine that you can install SQL Server > Express on? > > Even if Derek does have such a machine, he's been doing an awful lot > of work on Lift. Recruiting people from the community to help is > encouraged. > > > > On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker > wrote: > Hi, > I've made some changes to Mapper to better support SQL Server, > particularly with Unicode text. Does anyone out there use SQL Server > that would be willing to test the code on the wip-dcb-issue-16-sql- > server branch to make sure nothing breaks? > > Thanks, > > Derek > > > > > > > > > -- > 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 liftweb@googlegroups.com To unsubscribe from 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: Are we willing to make a breaking change for Joda Time?
On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker wrote: > Period is field-based, and therefore deals with non-linear time changes > like daylight savings time. Periods can be converted to millisecond > durations based on "standard" field durations (60 seconds == 1 minute, etc) > if needed, so it's a superset of the current functionality of TimeSpan. > So, why not make TimeSpan use Period, but preserve the interface so you can build one with millis and get it to spit out millis or Period as the case may be? > > On Fri, Oct 23, 2009 at 3:37 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> >> >> On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker > > wrote: >> >>> Well, I had intended to write a JodaHelpers trait that is the same as >>> Helpers except with JodaTimeHelpers and JodaTimeFormats replacing >>> TimeHelpers and TimeFormats, respectively. The main reason is that I would >>> like to have the time DSL be based on Periods instead of millisecond >>> durations, and with TimeHelpers already in scope there would be ambiguous >>> implicit conversions from Long/Int to TimeSpan or Period. >> >> >> What is the advantage of using Period internally instead of milliseconds? >> >> >>> Supposedly, 2.8 will have some support for masking or overriding >>> implicits, but I don't want to rely on that in the short term. If a >>> JodaHelpers trait that would replace a Helpers import isn't OK then I can >>> just do this in my own repo. >>> >>> Thanks, >>> >>> Derek >>> >>> >>> On Fri, Oct 23, 2009 at 2:52 PM, David Pollak < >>> feeder.of.the.be...@gmail.com> wrote: >>> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker < dchenbec...@gmail.com> wrote: > It sounds like you're pretty set against making separate impl traits > and would prefer just putting things directly on TimeHelper. I'm OK with > that, but I would really like to add a lift-joda module that contains the > JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to > use them. I should be able to delegate a good chunk of the methods to > TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a > reasonable compromise? > Yes, as long as import Helpers._ is not incompatible with importing whatever trait you come up with. > > Derek > > > On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker < > dchenbec...@gmail.com> wrote: > >> I agree that the goal isn't to remove java.util.Date. For trivial time >> handling it works just fine. What I'm trying to achieve here is a way to >> make Joda Time be the default impl while leaving the user a choice. By >> using >> separate traits instead of different names on the same trait, we achieve >> a >> few things: >> >>1. A consistent API for both java.util and Joda Time in terms of >>method names. As Naftoli pointed out, people expect naming of >> functions >>consistent with what they do and having two different "now"s on the >> same >>trait is going to look a little strange to people, I think. >>2. A clean *optional* usage of Joda Time. If we put code that >>utilizes Joda Time directly into TimeHelpers then it's not an optional >>dependency. Making a separate trait means that if someone doesn't use >> the >>Joda Time trait then they don't need to have the Joda Time jar in >> their >>classpath and they never know that it's not there. >>3. A relatively simple code change path to move from java.util to >>Joda Time by simply changing imports. >> >> Your assertion that Date is a simple wrapper for a Long timestamp is >> pretty accurate, but really Joda Time's DateTime is a superset of >> *Calendar*, not Date. Just look at what we had to do with >> CalendarExtension >> to get some simple date manipulation functions, where those same methods >> are >> already defined on DateTime. The vast majority of Joda Time's classes are >> immutable, and the mutators return new instances instead of modifying the >> current instance. TimeSpan's current handling of duration addition >> doesn't >> cope with DST, which I'm sure will show up as a bug in someone's code if >> it >> hasn't already. Having done a fair amount of java.util.Date handling and >> then moving to Joda Time, I find it hard to call the difference between >> the >> two APIs "marginal". In any case, I still feel that my proposal makes >> Joda >> Time available in a nicer way while leaving existing code completely >> untouched (by introducing a JodaHelpers trait that mirrors Helpers). >> >> Derek >> >> >> On Tue, Oct 20, 2009 at 9:25 PM, David Pollak < >> feeder.of.the.be...@gmail.com> wrote: >> >>> >>> >>> On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim < >>
[Lift] Re: Are we willing to make a breaking change for Joda Time?
Period is field-based, and therefore deals with non-linear time changes like daylight savings time. Periods can be converted to millisecond durations based on "standard" field durations (60 seconds == 1 minute, etc) if needed, so it's a superset of the current functionality of TimeSpan. On Fri, Oct 23, 2009 at 3:37 PM, David Pollak wrote: > > > On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker > wrote: > >> Well, I had intended to write a JodaHelpers trait that is the same as >> Helpers except with JodaTimeHelpers and JodaTimeFormats replacing >> TimeHelpers and TimeFormats, respectively. The main reason is that I would >> like to have the time DSL be based on Periods instead of millisecond >> durations, and with TimeHelpers already in scope there would be ambiguous >> implicit conversions from Long/Int to TimeSpan or Period. > > > What is the advantage of using Period internally instead of milliseconds? > > >> Supposedly, 2.8 will have some support for masking or overriding >> implicits, but I don't want to rely on that in the short term. If a >> JodaHelpers trait that would replace a Helpers import isn't OK then I can >> just do this in my own repo. >> >> Thanks, >> >> Derek >> >> >> On Fri, Oct 23, 2009 at 2:52 PM, David Pollak < >> feeder.of.the.be...@gmail.com> wrote: >> >>> >>> >>> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker < >>> dchenbec...@gmail.com> wrote: >>> It sounds like you're pretty set against making separate impl traits and would prefer just putting things directly on TimeHelper. I'm OK with that, but I would really like to add a lift-joda module that contains the JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to use them. I should be able to delegate a good chunk of the methods to TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a reasonable compromise? >>> >>> Yes, as long as import Helpers._ is not incompatible with importing >>> whatever trait you come up with. >>> >>> Derek On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker < dchenbec...@gmail.com> wrote: > I agree that the goal isn't to remove java.util.Date. For trivial time > handling it works just fine. What I'm trying to achieve here is a way to > make Joda Time be the default impl while leaving the user a choice. By > using > separate traits instead of different names on the same trait, we achieve a > few things: > >1. A consistent API for both java.util and Joda Time in terms of >method names. As Naftoli pointed out, people expect naming of functions >consistent with what they do and having two different "now"s on the > same >trait is going to look a little strange to people, I think. >2. A clean *optional* usage of Joda Time. If we put code that >utilizes Joda Time directly into TimeHelpers then it's not an optional >dependency. Making a separate trait means that if someone doesn't use > the >Joda Time trait then they don't need to have the Joda Time jar in their >classpath and they never know that it's not there. >3. A relatively simple code change path to move from java.util to >Joda Time by simply changing imports. > > Your assertion that Date is a simple wrapper for a Long timestamp is > pretty accurate, but really Joda Time's DateTime is a superset of > *Calendar*, not Date. Just look at what we had to do with > CalendarExtension > to get some simple date manipulation functions, where those same methods > are > already defined on DateTime. The vast majority of Joda Time's classes are > immutable, and the mutators return new instances instead of modifying the > current instance. TimeSpan's current handling of duration addition doesn't > cope with DST, which I'm sure will show up as a bug in someone's code if > it > hasn't already. Having done a fair amount of java.util.Date handling and > then moving to Joda Time, I find it hard to call the difference between > the > two APIs "marginal". In any case, I still feel that my proposal makes Joda > Time available in a nicer way while leaving existing code completely > untouched (by introducing a JodaHelpers trait that mirrors Helpers). > > Derek > > > On Tue, Oct 20, 2009 at 9:25 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> >> >> On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim < >> naftoli...@gmail.com> wrote: >> >>> >>> I agree with this. >>> My understanding is that the goal is that Lift should use Joda for >>> its time functions rather than java.util. >> >> >> This is not the goal. The goal is to make JodeTime available. There >> is no reason to remove support for java.util.Date. None. >> >> JodaTime offers some advantages, but there'
[Lift] NetBeans is barfing on the new pom.xml structure
Folks, Any idea why NetBeans doesn't like the new Lift pom structure? 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 liftweb@googlegroups.com To unsubscribe from 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: unnecessary COMMITs?
When an connection is finished on a thread, if no exception has happened, the connection is committed This will be fixed after I finish with defect 129 (I'm currently working on it) On Fri, Oct 23, 2009 at 2:36 PM, harryh wrote: > > Seeing a great many of these on my postgresql logs: > > 2009-10-23 21:35:02 UTC WARNING: there is no transaction in progress > 2009-10-23 21:35:02 UTC STATEMENT: COMMIT > > Any idea what might be causing this? I can filter them out but > > a) that would be a little annoying > b) vaguely worried that something non ideal is going on here > > -harryh > > > -- 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 liftweb@googlegroups.com To unsubscribe from 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: Are we willing to make a breaking change for Joda Time?
On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker wrote: > Well, I had intended to write a JodaHelpers trait that is the same as > Helpers except with JodaTimeHelpers and JodaTimeFormats replacing > TimeHelpers and TimeFormats, respectively. The main reason is that I would > like to have the time DSL be based on Periods instead of millisecond > durations, and with TimeHelpers already in scope there would be ambiguous > implicit conversions from Long/Int to TimeSpan or Period. What is the advantage of using Period internally instead of milliseconds? > Supposedly, 2.8 will have some support for masking or overriding implicits, > but I don't want to rely on that in the short term. If a JodaHelpers trait > that would replace a Helpers import isn't OK then I can just do this in my > own repo. > > Thanks, > > Derek > > > On Fri, Oct 23, 2009 at 2:52 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> >> >> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker > > wrote: >> >>> It sounds like you're pretty set against making separate impl traits and >>> would prefer just putting things directly on TimeHelper. I'm OK with that, >>> but I would really like to add a lift-joda module that contains the >>> JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to >>> use them. I should be able to delegate a good chunk of the methods to >>> TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a >>> reasonable compromise? >>> >> >> Yes, as long as import Helpers._ is not incompatible with importing >> whatever trait you come up with. >> >> >>> >>> Derek >>> >>> >>> On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker < >>> dchenbec...@gmail.com> wrote: >>> I agree that the goal isn't to remove java.util.Date. For trivial time handling it works just fine. What I'm trying to achieve here is a way to make Joda Time be the default impl while leaving the user a choice. By using separate traits instead of different names on the same trait, we achieve a few things: 1. A consistent API for both java.util and Joda Time in terms of method names. As Naftoli pointed out, people expect naming of functions consistent with what they do and having two different "now"s on the same trait is going to look a little strange to people, I think. 2. A clean *optional* usage of Joda Time. If we put code that utilizes Joda Time directly into TimeHelpers then it's not an optional dependency. Making a separate trait means that if someone doesn't use the Joda Time trait then they don't need to have the Joda Time jar in their classpath and they never know that it's not there. 3. A relatively simple code change path to move from java.util to Joda Time by simply changing imports. Your assertion that Date is a simple wrapper for a Long timestamp is pretty accurate, but really Joda Time's DateTime is a superset of *Calendar*, not Date. Just look at what we had to do with CalendarExtension to get some simple date manipulation functions, where those same methods are already defined on DateTime. The vast majority of Joda Time's classes are immutable, and the mutators return new instances instead of modifying the current instance. TimeSpan's current handling of duration addition doesn't cope with DST, which I'm sure will show up as a bug in someone's code if it hasn't already. Having done a fair amount of java.util.Date handling and then moving to Joda Time, I find it hard to call the difference between the two APIs "marginal". In any case, I still feel that my proposal makes Joda Time available in a nicer way while leaving existing code completely untouched (by introducing a JodaHelpers trait that mirrors Helpers). Derek On Tue, Oct 20, 2009 at 9:25 PM, David Pollak < feeder.of.the.be...@gmail.com> wrote: > > > On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim < > naftoli...@gmail.com> wrote: > >> >> I agree with this. >> My understanding is that the goal is that Lift should use Joda for its >> time functions rather than java.util. > > > This is not the goal. The goal is to make JodeTime available. There > is no reason to remove support for java.util.Date. None. > > JodaTime offers some advantages, but there's no reason, none, nada, to > *remove* support for java.util.Date. > > I'm cool with different names (not jtNow, but choose something else). > > But I view removal of support for java.util.Date as gratuitous. Sure, > if we were to make the clean-slate decision today, I'd opt for primary > support of JodaTime and secondary support for java.util.Date. But we're > making a decision based on legacy. We're not going to cut off > java.util.Date just because something margina
[Lift] unnecessary COMMITs?
Seeing a great many of these on my postgresql logs: 2009-10-23 21:35:02 UTC WARNING: there is no transaction in progress 2009-10-23 21:35:02 UTC STATEMENT: COMMIT Any idea what might be causing this? I can filter them out but a) that would be a little annoying b) vaguely worried that something non ideal is going on here -harryh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: Are we willing to make a breaking change for Joda Time?
Well, I had intended to write a JodaHelpers trait that is the same as Helpers except with JodaTimeHelpers and JodaTimeFormats replacing TimeHelpers and TimeFormats, respectively. The main reason is that I would like to have the time DSL be based on Periods instead of millisecond durations, and with TimeHelpers already in scope there would be ambiguous implicit conversions from Long/Int to TimeSpan or Period. Supposedly, 2.8 will have some support for masking or overriding implicits, but I don't want to rely on that in the short term. If a JodaHelpers trait that would replace a Helpers import isn't OK then I can just do this in my own repo. Thanks, Derek On Fri, Oct 23, 2009 at 2:52 PM, David Pollak wrote: > > > On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker > wrote: > >> It sounds like you're pretty set against making separate impl traits and >> would prefer just putting things directly on TimeHelper. I'm OK with that, >> but I would really like to add a lift-joda module that contains the >> JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to >> use them. I should be able to delegate a good chunk of the methods to >> TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a >> reasonable compromise? >> > > Yes, as long as import Helpers._ is not incompatible with importing > whatever trait you come up with. > > >> >> Derek >> >> >> On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker < >> dchenbec...@gmail.com> wrote: >> >>> I agree that the goal isn't to remove java.util.Date. For trivial time >>> handling it works just fine. What I'm trying to achieve here is a way to >>> make Joda Time be the default impl while leaving the user a choice. By using >>> separate traits instead of different names on the same trait, we achieve a >>> few things: >>> >>>1. A consistent API for both java.util and Joda Time in terms of >>>method names. As Naftoli pointed out, people expect naming of functions >>>consistent with what they do and having two different "now"s on the same >>>trait is going to look a little strange to people, I think. >>>2. A clean *optional* usage of Joda Time. If we put code that >>>utilizes Joda Time directly into TimeHelpers then it's not an optional >>>dependency. Making a separate trait means that if someone doesn't use the >>>Joda Time trait then they don't need to have the Joda Time jar in their >>>classpath and they never know that it's not there. >>>3. A relatively simple code change path to move from java.util to >>>Joda Time by simply changing imports. >>> >>> Your assertion that Date is a simple wrapper for a Long timestamp is >>> pretty accurate, but really Joda Time's DateTime is a superset of >>> *Calendar*, not Date. Just look at what we had to do with CalendarExtension >>> to get some simple date manipulation functions, where those same methods are >>> already defined on DateTime. The vast majority of Joda Time's classes are >>> immutable, and the mutators return new instances instead of modifying the >>> current instance. TimeSpan's current handling of duration addition doesn't >>> cope with DST, which I'm sure will show up as a bug in someone's code if it >>> hasn't already. Having done a fair amount of java.util.Date handling and >>> then moving to Joda Time, I find it hard to call the difference between the >>> two APIs "marginal". In any case, I still feel that my proposal makes Joda >>> Time available in a nicer way while leaving existing code completely >>> untouched (by introducing a JodaHelpers trait that mirrors Helpers). >>> >>> Derek >>> >>> >>> On Tue, Oct 20, 2009 at 9:25 PM, David Pollak < >>> feeder.of.the.be...@gmail.com> wrote: >>> On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim < naftoli...@gmail.com> wrote: > > I agree with this. > My understanding is that the goal is that Lift should use Joda for its > time functions rather than java.util. This is not the goal. The goal is to make JodeTime available. There is no reason to remove support for java.util.Date. None. JodaTime offers some advantages, but there's no reason, none, nada, to *remove* support for java.util.Date. I'm cool with different names (not jtNow, but choose something else). But I view removal of support for java.util.Date as gratuitous. Sure, if we were to make the clean-slate decision today, I'd opt for primary support of JodaTime and secondary support for java.util.Date. But we're making a decision based on legacy. We're not going to cut off java.util.Date just because something marginally better (and I'm not being facetious here... at the bottom, these are just wrappers for number of milliseconds since Jan 1, 1970). > If the Joda methods have different and longer names, then it's existing > side by side with the java.util implementation, not replacing it
[Lift] Re: Are we willing to make a breaking change for Joda Time?
On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker wrote: > It sounds like you're pretty set against making separate impl traits and > would prefer just putting things directly on TimeHelper. I'm OK with that, > but I would really like to add a lift-joda module that contains the > JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to > use them. I should be able to delegate a good chunk of the methods to > TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a > reasonable compromise? > Yes, as long as import Helpers._ is not incompatible with importing whatever trait you come up with. > > Derek > > > On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker > wrote: > >> I agree that the goal isn't to remove java.util.Date. For trivial time >> handling it works just fine. What I'm trying to achieve here is a way to >> make Joda Time be the default impl while leaving the user a choice. By using >> separate traits instead of different names on the same trait, we achieve a >> few things: >> >>1. A consistent API for both java.util and Joda Time in terms of >>method names. As Naftoli pointed out, people expect naming of functions >>consistent with what they do and having two different "now"s on the same >>trait is going to look a little strange to people, I think. >>2. A clean *optional* usage of Joda Time. If we put code that utilizes >>Joda Time directly into TimeHelpers then it's not an optional dependency. >>Making a separate trait means that if someone doesn't use the Joda Time >>trait then they don't need to have the Joda Time jar in their classpath >> and >>they never know that it's not there. >>3. A relatively simple code change path to move from java.util to Joda >>Time by simply changing imports. >> >> Your assertion that Date is a simple wrapper for a Long timestamp is >> pretty accurate, but really Joda Time's DateTime is a superset of >> *Calendar*, not Date. Just look at what we had to do with CalendarExtension >> to get some simple date manipulation functions, where those same methods are >> already defined on DateTime. The vast majority of Joda Time's classes are >> immutable, and the mutators return new instances instead of modifying the >> current instance. TimeSpan's current handling of duration addition doesn't >> cope with DST, which I'm sure will show up as a bug in someone's code if it >> hasn't already. Having done a fair amount of java.util.Date handling and >> then moving to Joda Time, I find it hard to call the difference between the >> two APIs "marginal". In any case, I still feel that my proposal makes Joda >> Time available in a nicer way while leaving existing code completely >> untouched (by introducing a JodaHelpers trait that mirrors Helpers). >> >> Derek >> >> >> On Tue, Oct 20, 2009 at 9:25 PM, David Pollak < >> feeder.of.the.be...@gmail.com> wrote: >> >>> >>> >>> On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim >> > wrote: >>> I agree with this. My understanding is that the goal is that Lift should use Joda for its time functions rather than java.util. >>> >>> >>> This is not the goal. The goal is to make JodeTime available. There is >>> no reason to remove support for java.util.Date. None. >>> >>> JodaTime offers some advantages, but there's no reason, none, nada, to >>> *remove* support for java.util.Date. >>> >>> I'm cool with different names (not jtNow, but choose something else). >>> >>> But I view removal of support for java.util.Date as gratuitous. Sure, if >>> we were to make the clean-slate decision today, I'd opt for primary support >>> of JodaTime and secondary support for java.util.Date. But we're making a >>> decision based on legacy. We're not going to cut off java.util.Date just >>> because something marginally better (and I'm not being facetious here... at >>> the bottom, these are just wrappers for number of milliseconds since Jan 1, >>> 1970). >>> >>> If the Joda methods have different and longer names, then it's existing side by side with the java.util implementation, not replacing it. To many people, it is important that methods etc. should be named properly and aesthetically. It's not pleasant to use names like "jtNow" in your code when that is the method that gets used normally. Sure, if 'now' was the usual method and a 'jtNow' method was called in special circumstances, it's an understandable name. But names that are used in ordinary circumstances should have straightforward names. (Names should be concise expressions of what they represent. This aids in memorization and code readability.) Also, it will be impossible to deprecate the java.util implementation and have a clean API instead. If we use separate traits with the same method names, then we will be able to. - Derek Chen-Becker wrote: On Tue, Oct 20,
[Lift] Re: Testing for SQL Server drivers
I'm pretty much 100% linux at home. I can test any other database (Oracle, MySQL, PostgreSQL, etc), but SQL Server is the exception :) On Fri, Oct 23, 2009 at 2:14 PM, Naftoli Gugenheim wrote: > 100%. Just curious. :) > > > On Fri, Oct 23, 2009 at 4:05 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> >> >> On Fri, Oct 23, 2009 at 12:10 PM, Naftoli Gugenheim > > wrote: >> >>> Don't you have a Windows machine that you can install SQL Server Express >>> on? >> >> >> Even if Derek does have such a machine, he's been doing an awful lot of >> work on Lift. Recruiting people from the community to help is encouraged. >> >> >>> >>> >>> On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker < >>> dchenbec...@gmail.com> wrote: >>> Hi, I've made some changes to Mapper to better support SQL Server, particularly with Unicode text. Does anyone out there use SQL Server that would be willing to test the code on the wip-dcb-issue-16-sql-server branch to make sure nothing breaks? Thanks, Derek >>> >>> >>> >> >> >> -- >> 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 liftweb@googlegroups.com To unsubscribe from 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: Testing for SQL Server drivers
100%. Just curious. :) On Fri, Oct 23, 2009 at 4:05 PM, David Pollak wrote: > > > On Fri, Oct 23, 2009 at 12:10 PM, Naftoli Gugenheim > wrote: > >> Don't you have a Windows machine that you can install SQL Server Express >> on? > > > Even if Derek does have such a machine, he's been doing an awful lot of > work on Lift. Recruiting people from the community to help is encouraged. > > >> >> >> On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker > > wrote: >> >>> Hi, >>> I've made some changes to Mapper to better support SQL Server, >>> particularly with Unicode text. Does anyone out there use SQL Server that >>> would be willing to test the code on the wip-dcb-issue-16-sql-server branch >>> to make sure nothing breaks? >>> >>> Thanks, >>> >>> Derek >>> >>> >>> >> >> >> > > > -- > 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 liftweb@googlegroups.com To unsubscribe from 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: Announcing the Lift Announce group/mailing list **IMPORTANT**
On Fri, Oct 23, 2009 at 1:04 PM, Naftoli Gugenheim wrote: > Will non-committers be able to reply on a thread? We'll cross-post to the Lift list. People can discuss on that list. The point of the announce list is so that people who don't have the bandwidth to track the Lift list can still get heads up about important stuff. > > > On Fri, Oct 23, 2009 at 9:07 AM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> Folks, >> >> After yesterday's issues surrounding the breaking changes in Lift, I've >> decided to create a low volume group called Lift Announce. You can see the >> group at http://groups.google.com/group/lift-announce?lnk=gcimh >> >> This group is an announce-only group which means that only the Lift >> committers will post to the group. >> >> Lift Announce will contain: announcements of Lift releases and milestone >> releases, invitations to comment about release planning (basically, if we're >> having a release planning discussion on the main list, we'll announce this >> so folks can participate in choosing features for the next release), and >> announcements about breaking changes. >> >> I expect than on average, there will be 1 post per week to this list. >> >> If you are using Lift actively, it is very important to subscribe to this >> list. It will be your guide to changes in 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 >> >> >> > > > > -- 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 liftweb@googlegroups.com To unsubscribe from 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: Testing for SQL Server drivers
On Fri, Oct 23, 2009 at 12:10 PM, Naftoli Gugenheim wrote: > Don't you have a Windows machine that you can install SQL Server Express > on? Even if Derek does have such a machine, he's been doing an awful lot of work on Lift. Recruiting people from the community to help is encouraged. > > > On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker > wrote: > >> Hi, >> I've made some changes to Mapper to better support SQL Server, >> particularly with Unicode text. Does anyone out there use SQL Server that >> would be willing to test the code on the wip-dcb-issue-16-sql-server branch >> to make sure nothing breaks? >> >> Thanks, >> >> Derek >> >> >> > > > > -- 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 liftweb@googlegroups.com To unsubscribe from 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: Announcing the Lift Announce group/mailing list **IMPORTANT**
Will non-committers be able to reply on a thread? On Fri, Oct 23, 2009 at 9:07 AM, David Pollak wrote: > Folks, > > After yesterday's issues surrounding the breaking changes in Lift, I've > decided to create a low volume group called Lift Announce. You can see the > group at http://groups.google.com/group/lift-announce?lnk=gcimh > > This group is an announce-only group which means that only the Lift > committers will post to the group. > > Lift Announce will contain: announcements of Lift releases and milestone > releases, invitations to comment about release planning (basically, if we're > having a release planning discussion on the main list, we'll announce this > so folks can participate in choosing features for the next release), and > announcements about breaking changes. > > I expect than on average, there will be 1 post per week to this list. > > If you are using Lift actively, it is very important to subscribe to this > list. It will be your guide to changes in 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 liftweb@googlegroups.com To unsubscribe from 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: Testing for SQL Server drivers
I have one virtual Win2K instance for some legacy software, but looking at the requirements that doesn't seem to be supported. On Fri, Oct 23, 2009 at 1:10 PM, Naftoli Gugenheim wrote: > Don't you have a Windows machine that you can install SQL Server Express > on? > > > On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker > wrote: > >> Hi, >> I've made some changes to Mapper to better support SQL Server, >> particularly with Unicode text. Does anyone out there use SQL Server that >> would be willing to test the code on the wip-dcb-issue-16-sql-server branch >> to make sure nothing breaks? >> >> Thanks, >> >> Derek >> >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: How to create an rss?
Hi Glenn
thanks for your reply. It seems to work for me :-) I was confused
between AtomResponse, Box[NodeSeq] and LiftResponse. I am at beginning
of this journey.
regards,
wibblecp.
On 23 Ott, 18:49, glenn wrote:
> I don't know if this will help, but I use a simple createTag to just
> enclose the full xml so it has a root element:
>
> def createTag(in: NodeSeq) = {
> {in}
>
> }
>
> and then showArticles would call into a feed wrapper, passing in the
> result of yield, like this for an Atom feed:
>
> //Reacts to Get all reguest
> def showArticles():AtomResponse = {
> val eList = for(e <- Content.findAll) yield {
> e.toAtom
> }
>
> AtomResponse(feedWrapper(eList))
>
> }
>
> Glenn
>
> On Oct 23, 6:24 am, wibblecp wrote:
>
> > hi guys,
> > I'm looking for a way to generate an rss feed with lift, I'm working
> > on something like this (from lift-book):
>
> > object OwnRssFeed extends XMLApiHelper {
> > def dispatch: LiftRules.DispatchPF = {
> > case Req("rss" :: Nil, "", GetRequest) => () => showArticles()
> > case Req("rss" :: _ :: Nil, "", _) => failure _
> > }
>
> > def failure() : LiftResponse = {
> > val ret: Box[NodeSeq] = Full()
> > NotFoundResponse()
> > }
>
> > def createTag(in: NodeSeq) = {
> > println("[CreateTag] " + in)
> >
> >
> > title
> > http://example.org
> > Example.org
> > en-us
>
> > Lift WebFramework
> > {in}
> >
> >
> > }
>
> > def showArticles(): LiftResponse = {
> > val a: Box[NodeSeq] = for(a <- Article.find(By
> > (Article.published, true))) yield {
> > a.toXML
> > }
> > a
> > }
>
> > }
>
> > obviously the yield into the definition of showArticles method break
> > the cycle to the first one.
>
> > Could you suggest me what I can do? I am evaluating lift and scala
> > just in a while.
> > Thanks for your attention.
> > w.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from 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: A Critique On Lift
>I'll repeat: there are no operators in scala s/operators/methods-with-operator-like-names/ anywhere, here's a typical case: import some.library.package.foo._ val a = bar 42 val b = a ~!~ 3.14159 you can't easily tell that bar is being imported via foo._ . what is bar's return type? what does ~!~ do? i'm not saying its not possible to track all this down, but you can't just print out a listing of a class and take it on the subway. you have to have access to the scaladocs and possibly even the sources. --b --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: catch a URL
Timothy Perrett writes:
> Ah. In that case, does this help:
>
> Menu(Loc("Some", List("some","page"), "Some",
>EarlyResponse(() => {
> // do some response here,
> // return Empty if you dont want
> // a response but a filter style
> // intercept.
> Empty
>})
> ))
>
> Does that help?
Or, if you just need to run some code before a template is rendered:
Menu(Loc("test", List("landing"), "test", Template{() =>
println("Hit the template URL");
// Handle Empty case :-)
TemplateFinder.findAnyTemplate(List("mytemplat","index")).open_!
}))
/Jeppe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from 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: Testing for SQL Server drivers
Don't you have a Windows machine that you can install SQL Server Express on? On Wed, Oct 21, 2009 at 6:02 PM, Derek Chen-Becker wrote: > Hi, > I've made some changes to Mapper to better support SQL Server, > particularly with Unicode text. Does anyone out there use SQL Server that > would be willing to test the code on the wip-dcb-issue-16-sql-server branch > to make sure nothing breaks? > > Thanks, > > Derek > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
jlist9 wrote: > It's often hard to describe some (I'd say most) of the Scala syntax > if you want to search for an answer online. I can't relate with that. I've been coding scala for 3-4 months, and I've never had any problem finding method definitions. Most of this probably had to do with that fact that I was reading through several language overviews and tutorials. > It would be great if the eclipse plugin can tell you what the code is > trying to do and what kind of syntax is that, for example, linking > an operator back to a method name. I'll repeat: there are no operators in scala. Not a single one. "linking an operator back to a method name" doesn't make sense. Accept that _everything_ in scala, except methods, is an object, and as such adheres to its respective class contract. If you need to look up the meaning of an "operator," all you need to know is the type on which it is being invoked. The only real complexity in this resolution then is introduced by implicits. > > On Fri, Oct 23, 2009 at 6:27 AM, bob wrote: >> i believe that one of the best ways to learn a new programming >> language is to read software written in it >> >> when reading Scala code, I rarely say "i don't understand how that >> works" and when I do, there's usually a good explanation of it >> somewhere on the web. >> >> usually I find myself asking "where is that defined?" or "what part of >> the language is that?" >> >> Scala is not like, for example, BASIC, where you can look up FOR, IF/ >> THEN/ELSE. there's lots of individual and compound punctuation marks >> that are very difficult to search for online and in PDFs (try >> searching for "!"). >> >> a lot of scala also relies on syntactic sugar, such as omitted types >> (no ": T" after a val/var/def); the dreaded underbar; operator >> overloading; and implicit conversions. you can hate on Java's >> verbosity (i know i have), but brevity has its own difficulties. >> >> On Oct 22, 11:44 pm, Naftoli Gugenheim wrote: >>> The last use of _, as in empty_?, is not a special scala meaning. As on >>> Java, underscores can be part of an identifier. Scala takes advantage of >>> this to combine letters and symbols in one name. These names, like empty_?, >>> are a Lift convention, as well as ..._! for use-with-care methods. The >>> scala library uses isEmpty. David, is it your original convention?. >>> >>> - >>> >>> tiro wrote: override def validations = validPriority _ :: super.validations >>> funny, I had stumbled on exactly the same line of code when beginning. >>> Took me more than a day to understand what's going on. Especially >>> because when you copied code from the PDF version of the Liftbook/Lift >>> getting started guide, it would mess up spaces, so I would keep >>> loooking for a "_::" operator. >>> The Scala guys have really pushed it a bit hard on the use of the >>> underscore. At least four different uses: >>> - "it" for defining anonymous functions like above >>> - default value >>> - matching placeholder whose value is ignored >>> - use for constructing setter method names boolean functions (empty_?) >>> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Problem to process a PUT request in a lift API
In order to trigger XML parsing, you have to set the Content-Type to
text/xml
On Fri, Oct 23, 2009 at 10:30 AM, GA wrote:
>
> I have printed Req in the log and it looks like the XML is really empty:
>
> Req(List(), Map(), ParsePath(List(api, person),,true,false), ,
> PutRequest, Empty)
>
> This is how I send the XML:
>
> def post(url:URL):String = {
>
> val message =
>
> John
> John
> Smith
> a
> a...@.com
> 10/12/2009
> John
> 10/12/2009
> John
>
>
> url.openConnection match { case conn: HttpURLConnection => {
> conn.setRequestMethod("PUT")
> conn.setDoOutput(true)
> //conn.connect
> conn.getOutputStream.write
> (message.mkString.getBytes)
> scala.io.Source.fromInputStream
> (conn.getInputStream).getLines.mkString
> }
> }
> }
>
> Any suggestions?
>
> Cheers,
>
> GA
>
>
>
>
> On Oct 23, 2009, at 5:15 PM, GA wrote:
>
> >
> > Hello guys,
> >
> > I have created an API to process a PUT request and a GET request. The
> > GET works perfectly fine, but with the PUT the XML seems to be lost in
> > its way. I have the following code:
> >
> > def dispatch: LiftRules.DispatchPF = {
> > case Req("api" :: "person" :: userName :: Nil, "",
> > GetRequest) =>
> > () => showPerson(userName)
> >
> > case r @ Req(List("api", "person"), "", PutRequest) =>
> > () => addPerson(r)
> > }
> >
> > In the addPerson method I have the following code:
> >
> > req.xml match {
> > case Full({parameters @_*}) => {
> > for(parameter <- parameters){ parameter match {
> >
> > All the XML parsing
> >
> > }
> > }
> >
> > try {
> > person.validate match {
> > case Nil =>
> > person.save
> > CreatedResponse(wrapXmlBody
> > (), "text/xml")
> > case _ =>
> > CreatedResponse(wrapXmlBody
> > (), "text/xml")
> > }
> > }
> > catch {
> > case e => Log.error("Could not add person",
> > e); BadResponse()
> > }
> > }
> > case _ => Log.error("Request was malformed "+req.view);
> > BadResponse()
> > }
> >
> > The method always goes through the last case: "Request was malformed".
> >
> > I was checking the values to req.view and req.xml.toString and the
> > results are "person" and empty, respectively.
> >
> > Any ideas about what it could be happening?
> >
> > Thanks in advance,
> >
> > GA
> >
> >
> > >
>
>
> >
>
--
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 liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Problem to process a PUT request in a lift API
I have printed Req in the log and it looks like the XML is really empty:
Req(List(), Map(), ParsePath(List(api, person),,true,false), ,
PutRequest, Empty)
This is how I send the XML:
def post(url:URL):String = {
val message =
John
John
Smith
a
a...@.com
10/12/2009
John
10/12/2009
John
url.openConnection match { case conn: HttpURLConnection => {
conn.setRequestMethod("PUT")
conn.setDoOutput(true)
//conn.connect
conn.getOutputStream.write
(message.mkString.getBytes)
scala.io.Source.fromInputStream
(conn.getInputStream).getLines.mkString
}
}
}
Any suggestions?
Cheers,
GA
On Oct 23, 2009, at 5:15 PM, GA wrote:
>
> Hello guys,
>
> I have created an API to process a PUT request and a GET request. The
> GET works perfectly fine, but with the PUT the XML seems to be lost in
> its way. I have the following code:
>
> def dispatch: LiftRules.DispatchPF = {
> case Req("api" :: "person" :: userName :: Nil, "",
> GetRequest) =>
> () => showPerson(userName)
>
> case r @ Req(List("api", "person"), "", PutRequest) =>
> () => addPerson(r)
> }
>
> In the addPerson method I have the following code:
>
> req.xml match {
> case Full({parameters @_*}) => {
> for(parameter <- parameters){ parameter match {
>
> All the XML parsing
>
> }
> }
>
> try {
> person.validate match {
> case Nil =>
> person.save
> CreatedResponse(wrapXmlBody
> (), "text/xml")
> case _ =>
> CreatedResponse(wrapXmlBody
> (), "text/xml")
> }
> }
> catch {
> case e => Log.error("Could not add person",
> e); BadResponse()
> }
> }
> case _ => Log.error("Request was malformed "+req.view);
> BadResponse()
> }
>
> The method always goes through the last case: "Request was malformed".
>
> I was checking the values to req.view and req.xml.toString and the
> results are "person" and empty, respectively.
>
> Any ideas about what it could be happening?
>
> Thanks in advance,
>
> GA
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from 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: A Critique On Lift
It's often hard to describe some (I'd say most) of the Scala syntax if you want to search for an answer online. It would be great if the eclipse plugin can tell you what the code is trying to do and what kind of syntax is that, for example, linking an operator back to a method name. On Fri, Oct 23, 2009 at 6:27 AM, bob wrote: > > i believe that one of the best ways to learn a new programming > language is to read software written in it > > when reading Scala code, I rarely say "i don't understand how that > works" and when I do, there's usually a good explanation of it > somewhere on the web. > > usually I find myself asking "where is that defined?" or "what part of > the language is that?" > > Scala is not like, for example, BASIC, where you can look up FOR, IF/ > THEN/ELSE. there's lots of individual and compound punctuation marks > that are very difficult to search for online and in PDFs (try > searching for "!"). > > a lot of scala also relies on syntactic sugar, such as omitted types > (no ": T" after a val/var/def); the dreaded underbar; operator > overloading; and implicit conversions. you can hate on Java's > verbosity (i know i have), but brevity has its own difficulties. > > On Oct 22, 11:44 pm, Naftoli Gugenheim wrote: >> The last use of _, as in empty_?, is not a special scala meaning. As on >> Java, underscores can be part of an identifier. Scala takes advantage of >> this to combine letters and symbols in one name. These names, like empty_?, >> are a Lift convention, as well as ..._! for use-with-care methods. The scala >> library uses isEmpty. David, is it your original convention?. >> >> - >> >> tiro wrote: >> > override def validations = validPriority _ :: super.validations >> >> funny, I had stumbled on exactly the same line of code when beginning. >> Took me more than a day to understand what's going on. Especially >> because when you copied code from the PDF version of the Liftbook/Lift >> getting started guide, it would mess up spaces, so I would keep >> loooking for a "_::" operator. >> The Scala guys have really pushed it a bit hard on the use of the >> underscore. At least four different uses: >> - "it" for defining anonymous functions like above >> - default value >> - matching placeholder whose value is ignored >> - use for constructing setter method names boolean functions (empty_?) > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: How to create an rss?
I don't know if this will help, but I use a simple createTag to just
enclose the full xml so it has a root element:
def createTag(in: NodeSeq) = {
{in}
}
and then showArticles would call into a feed wrapper, passing in the
result of yield, like this for an Atom feed:
//Reacts to Get all reguest
def showArticles():AtomResponse = {
val eList = for(e <- Content.findAll) yield {
e.toAtom
}
AtomResponse(feedWrapper(eList))
}
Glenn
On Oct 23, 6:24 am, wibblecp wrote:
> hi guys,
> I'm looking for a way to generate an rss feed with lift, I'm working
> on something like this (from lift-book):
>
> object OwnRssFeed extends XMLApiHelper {
> def dispatch: LiftRules.DispatchPF = {
> case Req("rss" :: Nil, "", GetRequest) => () => showArticles()
> case Req("rss" :: _ :: Nil, "", _) => failure _
> }
>
> def failure() : LiftResponse = {
> val ret: Box[NodeSeq] = Full()
> NotFoundResponse()
> }
>
> def createTag(in: NodeSeq) = {
> println("[CreateTag] " + in)
>
>
> title
> http://example.org
> Example.org
> en-us
>
> Lift WebFramework
> {in}
>
>
> }
>
> def showArticles(): LiftResponse = {
> val a: Box[NodeSeq] = for(a <- Article.find(By
> (Article.published, true))) yield {
> a.toXML
> }
> a
> }
>
> }
>
> obviously the yield into the definition of showArticles method break
> the cycle to the first one.
>
> Could you suggest me what I can do? I am evaluating lift and scala
> just in a while.
> Thanks for your attention.
> w.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from 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: A Critique On Lift
On Fri, Oct 23, 2009 at 9:29 AM, Jim Barrows wrote: > > On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis wrote: > >> >> My head just exploded. Twice. >> > > That explains the wet face this morning when I woke up... thought it was > the dog licking it... :) > > >> >> ngocdaothanh wrote: >> > Because Lift's ad is so good. >> >> *boom* >> > > It was good. My first thought was "Yeah > rIGHT!" Let's see what they mean. > And voila... here I am.. so it was good, if only because it was right :) > > >> >> For example: >> > >> > "Lift is the only new framework in the last four years to offer fresh >> > and innovative approaches to web development. It's not just some >> > incremental improvements over the status quo, it redefines the state >> > of the art. If you are a web developer, you should learn Lift. Even if >> > you don't wind up using it everyday, it will change the way you >> > approach web applications." >> > >> > Lift can't be used without Scala. Is there a plan to implement Lift in >> > Clojure, for example? :D >> > I've thought about it and even done some initial poking around with Clojure. It could be done, but I really like static typing so don't want to spend a lot of time in Clojure's unityped land. > >> *BOOM* >> > > Ummm.. ok.. This one I understand. > > >> >> > >> > >> > On Oct 22, 3:47 pm, TylerWeir wrote: >> >> On Oct 22, 2:02 am, ngocdaothanh wrote: >> >> >> >>> jlist9, >> >>> This is a Lift group, but I have to say I feel the same about Scala. >> >>> I had to ask for advice here: >> http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a... >> >>> Scala may help me to get my work done for the day. But I don't feel >> >>> happy with Scala. Scala makes me feel I'm a slave all the day to >> >>> machines (or Scala itself!). >> >> If it makes you feel like a slave, why are you using Scala at all >> >> then? >> >> >> >> >> >> >> >>> On Oct 22, 2:13 pm, jlist9 wrote: >> override def validations = validPriority _ :: super.validations >> This is a more of a comment about Scala than one about Lift - this >> does >> look cryptic to me. And this is just one of the simpler syntax that >> confuses >> people, who are new to the language. And I'm one of them. >> I understand that you don't have to learn all the tricks/syntax to >> start >> coding in Scala but you do have to understand it when you read >> source code of libraries written by someone with much more advanced >> language skills. >> In David's book he says "After more than two years of coding Scala, >> ... >> My brain has finally stopped hurting." This sounds like a very high >> barrier to entry. >> I'm just wondering why Scala has to be so complicated. I'm sure a lot >> of things in Scala have their reasons but at the mean time I also >> suspect that many of the odd things are there to reduce >> typing, which is advertised as one of the advantages of this language >> - >> conciseness. (I could be very wrong due to my lack of understanding.) >> If the latter is true, I feel that I'd rather type a little more to >> make the >> code easier to read. >> Just feeling a little frustrated learning Scala. I think it's much >> easier learning >> Java. Not much surprise. Not sure if anyone shares my experience >> (and opinion, if there is one.) >> On Wed, Oct 21, 2009 at 3:56 PM, Randinn wrote: >> > http://localhost3000.de/2009/10/a-quick-glance-at-lift/ >> > The site above is a blog post from a Rails developer, he had some >> good >> > and bad things to say about Lift and since I do not know enough to >> > debate with him I thought I'd post it here. >> > >> > > >> > >> >> >> > > > -- > James A Barrows > > > > > > -- 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 liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis wrote: > > My head just exploded. Twice. > That explains the wet face this morning when I woke up... thought it was the dog licking it... :) > > ngocdaothanh wrote: > > Because Lift's ad is so good. > > *boom* > It was good. My first thought was "Yeah rIGHT!" Let's see what they mean. And voila... here I am.. so it was good, if only because it was right :) > > For example: > > > > "Lift is the only new framework in the last four years to offer fresh > > and innovative approaches to web development. It's not just some > > incremental improvements over the status quo, it redefines the state > > of the art. If you are a web developer, you should learn Lift. Even if > > you don't wind up using it everyday, it will change the way you > > approach web applications." > > > > Lift can't be used without Scala. Is there a plan to implement Lift in > > Clojure, for example? :D > > *BOOM* > Ummm.. ok.. This one I understand. > > > > > > > On Oct 22, 3:47 pm, TylerWeir wrote: > >> On Oct 22, 2:02 am, ngocdaothanh wrote: > >> > >>> jlist9, > >>> This is a Lift group, but I have to say I feel the same about Scala. > >>> I had to ask for advice here: > http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a... > >>> Scala may help me to get my work done for the day. But I don't feel > >>> happy with Scala. Scala makes me feel I'm a slave all the day to > >>> machines (or Scala itself!). > >> If it makes you feel like a slave, why are you using Scala at all > >> then? > >> > >> > >> > >>> On Oct 22, 2:13 pm, jlist9 wrote: > override def validations = validPriority _ :: super.validations > This is a more of a comment about Scala than one about Lift - this > does > look cryptic to me. And this is just one of the simpler syntax that > confuses > people, who are new to the language. And I'm one of them. > I understand that you don't have to learn all the tricks/syntax to > start > coding in Scala but you do have to understand it when you read > source code of libraries written by someone with much more advanced > language skills. > In David's book he says "After more than two years of coding Scala, > ... > My brain has finally stopped hurting." This sounds like a very high > barrier to entry. > I'm just wondering why Scala has to be so complicated. I'm sure a lot > of things in Scala have their reasons but at the mean time I also > suspect that many of the odd things are there to reduce > typing, which is advertised as one of the advantages of this language > - > conciseness. (I could be very wrong due to my lack of understanding.) > If the latter is true, I feel that I'd rather type a little more to > make the > code easier to read. > Just feeling a little frustrated learning Scala. I think it's much > easier learning > Java. Not much surprise. Not sure if anyone shares my experience > (and opinion, if there is one.) > On Wed, Oct 21, 2009 at 3:56 PM, Randinn wrote: > > http://localhost3000.de/2009/10/a-quick-glance-at-lift/ > > The site above is a blog post from a Rails developer, he had some > good > > and bad things to say about Lift and since I do not know enough to > > debate with him I thought I'd post it here. > > > > > > > > > > > -- 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 liftweb@googlegroups.com To unsubscribe from 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: catch a URL
Ah. In that case, does this help:
Menu(Loc("Some", List("some","page"), "Some",
EarlyResponse(() => {
// do some response here,
// return Empty if you dont want
// a response but a filter style
// intercept.
Empty
})
))
Does that help?
Cheers, Tim
On 23 Oct 2009, at 17:07, Chris Lewis wrote:
>
> Hi Tim,
>
> I don't specifically want to rewrite anything. What I want is to be
> able
> to run some initialization code when a specific page is requested.
> As I
> said, I'm writing a google app engine app that uses google's
> authentication service to auth users (using their google account). I'm
> instructing the auth service to returned the authenticated user to
> their
> home page, a page protected and mapped via SiteMap. However, if it's
> their first time logging in, I need to bootstrap them in my app.
> Rewriting was suggested by Jeppe, and I had thought that way might
> work.
> It doesn't seem to, b/c Lift doesn't appear to fire the rewriters on
> URLs mapped in SiteMap.
>
> I'm not married to the idea of rewrites to solve this problem, I just
> need a non-snippet way to solve it.
>
> -chris
>
> Timothy Perrett wrote:
>> Chris,
>>
>> SiteMap deals with what pages you are saying should be visible. Here,
>> I term "page" as the physical xhtml file that represents the stuff
>> the users sees - its a file on your system.
>>
>> Rewritten URLs dont need to feature in SiteMap because lift is clever
>> enough to know that the page you are rewriting to already has (or has
>> not) been allowed access via sitemap.
>>
>> Sounds like your trying to add rewritten URLs to your sitemap?
>>
>> Cheers, Tim
>>
>> PS: Jeppe, thanks for the link recycling!!
>>
>> On 23 Oct 2009, at 16:43, Chris Lewis wrote:
>>
>>> Thanks for that link, however it doesn't seem like rewrite rules
>>> fire
>>> for paths that are mapped in the SiteMap. Can anyone confirm that? I
>>> could have the redirect point to a non-existing URL, and do logic +
>>> rewrite there. I'm curious though, are rewrites considered if the
>>> URL
>>> matches a page in the SiteMap?
>>>
>>> Jeppe Nejsum Madsen wrote:
Chris Lewis writes:
> Hi list,
>
> I'm working on an appengine app, and need to store some user
> information. I authenticate the user with their google account,
> and I
> need to create their "local" entity only if it's their first time
> logging in.
>
> When a user logs in via google, they are redirected back to your
> app, to
> a URL of your choosing. My thought was to catch the request as it
> comes
> back and, if it's their first time logging in, create a User
> entity. My
> question then is how can I do this without:
>
> a) Using a snippet, called from the return landing page and
> emitting
> NodeSeq.Empty - hack.
>
> b) Using custom dispatch and then redirecting. That may work, but
> it's
> an unneeded round trip.
>
> Any thoughts? Thanks!
Not sure if the landing page is static, has parameters etc and what
you
want to do afterwards.
Assume you need to render some template and the landing page is not
static (if it is you could just use a normal Loc) I would probably
wrap
the landing page in a RewriteRequest, and when a match is made, do
the
user creation/lookup thing and then just render the template.
Tim wrote and article about rewriting
http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework
Also, I've been using the Locs from CRUDify as an example of how to
do
more custom-type Locs with rewriting.
/Jeppe
>>
>>
>>>
>>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from 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: A Critique On Lift
My head just exploded. Twice. ngocdaothanh wrote: > Because Lift's ad is so good. *boom* For example: > > "Lift is the only new framework in the last four years to offer fresh > and innovative approaches to web development. It's not just some > incremental improvements over the status quo, it redefines the state > of the art. If you are a web developer, you should learn Lift. Even if > you don't wind up using it everyday, it will change the way you > approach web applications." > > Lift can't be used without Scala. Is there a plan to implement Lift in > Clojure, for example? :D *BOOM* > > > On Oct 22, 3:47 pm, TylerWeir wrote: >> On Oct 22, 2:02 am, ngocdaothanh wrote: >> >>> jlist9, >>> This is a Lift group, but I have to say I feel the same about Scala. >>> I had to ask for advice >>> here:http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a... >>> Scala may help me to get my work done for the day. But I don't feel >>> happy with Scala. Scala makes me feel I'm a slave all the day to >>> machines (or Scala itself!). >> If it makes you feel like a slave, why are you using Scala at all >> then? >> >> >> >>> On Oct 22, 2:13 pm, jlist9 wrote: override def validations = validPriority _ :: super.validations This is a more of a comment about Scala than one about Lift - this does look cryptic to me. And this is just one of the simpler syntax that confuses people, who are new to the language. And I'm one of them. I understand that you don't have to learn all the tricks/syntax to start coding in Scala but you do have to understand it when you read source code of libraries written by someone with much more advanced language skills. In David's book he says "After more than two years of coding Scala, ... My brain has finally stopped hurting." This sounds like a very high barrier to entry. I'm just wondering why Scala has to be so complicated. I'm sure a lot of things in Scala have their reasons but at the mean time I also suspect that many of the odd things are there to reduce typing, which is advertised as one of the advantages of this language - conciseness. (I could be very wrong due to my lack of understanding.) If the latter is true, I feel that I'd rather type a little more to make the code easier to read. Just feeling a little frustrated learning Scala. I think it's much easier learning Java. Not much surprise. Not sure if anyone shares my experience (and opinion, if there is one.) On Wed, Oct 21, 2009 at 3:56 PM, Randinn wrote: > http://localhost3000.de/2009/10/a-quick-glance-at-lift/ > The site above is a blog post from a Rails developer, he had some good > and bad things to say about Lift and since I do not know enough to > debate with him I thought I'd post it here. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: catch a URL
Hi Tim, I don't specifically want to rewrite anything. What I want is to be able to run some initialization code when a specific page is requested. As I said, I'm writing a google app engine app that uses google's authentication service to auth users (using their google account). I'm instructing the auth service to returned the authenticated user to their home page, a page protected and mapped via SiteMap. However, if it's their first time logging in, I need to bootstrap them in my app. Rewriting was suggested by Jeppe, and I had thought that way might work. It doesn't seem to, b/c Lift doesn't appear to fire the rewriters on URLs mapped in SiteMap. I'm not married to the idea of rewrites to solve this problem, I just need a non-snippet way to solve it. -chris Timothy Perrett wrote: > Chris, > > SiteMap deals with what pages you are saying should be visible. Here, > I term "page" as the physical xhtml file that represents the stuff > the users sees - its a file on your system. > > Rewritten URLs dont need to feature in SiteMap because lift is clever > enough to know that the page you are rewriting to already has (or has > not) been allowed access via sitemap. > > Sounds like your trying to add rewritten URLs to your sitemap? > > Cheers, Tim > > PS: Jeppe, thanks for the link recycling!! > > On 23 Oct 2009, at 16:43, Chris Lewis wrote: > >> Thanks for that link, however it doesn't seem like rewrite rules fire >> for paths that are mapped in the SiteMap. Can anyone confirm that? I >> could have the redirect point to a non-existing URL, and do logic + >> rewrite there. I'm curious though, are rewrites considered if the URL >> matches a page in the SiteMap? >> >> Jeppe Nejsum Madsen wrote: >>> Chris Lewis writes: >>> Hi list, I'm working on an appengine app, and need to store some user information. I authenticate the user with their google account, and I need to create their "local" entity only if it's their first time logging in. When a user logs in via google, they are redirected back to your app, to a URL of your choosing. My thought was to catch the request as it comes back and, if it's their first time logging in, create a User entity. My question then is how can I do this without: a) Using a snippet, called from the return landing page and emitting NodeSeq.Empty - hack. b) Using custom dispatch and then redirecting. That may work, but it's an unneeded round trip. Any thoughts? Thanks! >>> Not sure if the landing page is static, has parameters etc and what >>> you >>> want to do afterwards. >>> >>> Assume you need to render some template and the landing page is not >>> static (if it is you could just use a normal Loc) I would probably >>> wrap >>> the landing page in a RewriteRequest, and when a match is made, do >>> the >>> user creation/lookup thing and then just render the template. >>> >>> Tim wrote and article about rewriting >>> http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework >>> >>> Also, I've been using the Locs from CRUDify as an example of how to >>> do >>> more custom-type Locs with rewriting. >>> >>> /Jeppe >>> > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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] Foreign Key Constraints in PostgreSQL through MappedLongForeignKey fields?
I was running the models of One-To-Many example from WiKi (http:// wiki.github.com/dpp/liftweb/how-to-work-with-one-to-many- relationships) against PostgreSQL hoping to see a foreign key constraint on the "Book" table. I got an index instead. Is there a way to get schemifier to acknowledge the foreign key constraints? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: catch a URL
Chris, SiteMap deals with what pages you are saying should be visible. Here, I term "page" as the physical xhtml file that represents the stuff the users sees - its a file on your system. Rewritten URLs dont need to feature in SiteMap because lift is clever enough to know that the page you are rewriting to already has (or has not) been allowed access via sitemap. Sounds like your trying to add rewritten URLs to your sitemap? Cheers, Tim PS: Jeppe, thanks for the link recycling!! On 23 Oct 2009, at 16:43, Chris Lewis wrote: > > Thanks for that link, however it doesn't seem like rewrite rules fire > for paths that are mapped in the SiteMap. Can anyone confirm that? I > could have the redirect point to a non-existing URL, and do logic + > rewrite there. I'm curious though, are rewrites considered if the URL > matches a page in the SiteMap? > > Jeppe Nejsum Madsen wrote: >> Chris Lewis writes: >> >>> Hi list, >>> >>> I'm working on an appengine app, and need to store some user >>> information. I authenticate the user with their google account, >>> and I >>> need to create their "local" entity only if it's their first time >>> logging in. >>> >>> When a user logs in via google, they are redirected back to your >>> app, to >>> a URL of your choosing. My thought was to catch the request as it >>> comes >>> back and, if it's their first time logging in, create a User >>> entity. My >>> question then is how can I do this without: >>> >>> a) Using a snippet, called from the return landing page and emitting >>> NodeSeq.Empty - hack. >>> >>> b) Using custom dispatch and then redirecting. That may work, but >>> it's >>> an unneeded round trip. >>> >>> Any thoughts? Thanks! >> >> Not sure if the landing page is static, has parameters etc and what >> you >> want to do afterwards. >> >> Assume you need to render some template and the landing page is not >> static (if it is you could just use a normal Loc) I would probably >> wrap >> the landing page in a RewriteRequest, and when a match is made, do >> the >> user creation/lookup thing and then just render the template. >> >> Tim wrote and article about rewriting >> http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework >> >> Also, I've been using the Locs from CRUDify as an example of how to >> do >> more custom-type Locs with rewriting. >> >> /Jeppe >> >>> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: catch a URL
Thanks for that link, however it doesn't seem like rewrite rules fire for paths that are mapped in the SiteMap. Can anyone confirm that? I could have the redirect point to a non-existing URL, and do logic + rewrite there. I'm curious though, are rewrites considered if the URL matches a page in the SiteMap? Jeppe Nejsum Madsen wrote: > Chris Lewis writes: > >> Hi list, >> >> I'm working on an appengine app, and need to store some user >> information. I authenticate the user with their google account, and I >> need to create their "local" entity only if it's their first time >> logging in. >> >> When a user logs in via google, they are redirected back to your app, to >> a URL of your choosing. My thought was to catch the request as it comes >> back and, if it's their first time logging in, create a User entity. My >> question then is how can I do this without: >> >> a) Using a snippet, called from the return landing page and emitting >> NodeSeq.Empty - hack. >> >> b) Using custom dispatch and then redirecting. That may work, but it's >> an unneeded round trip. >> >> Any thoughts? Thanks! > > Not sure if the landing page is static, has parameters etc and what you > want to do afterwards. > > Assume you need to render some template and the landing page is not > static (if it is you could just use a normal Loc) I would probably wrap > the landing page in a RewriteRequest, and when a match is made, do the > user creation/lookup thing and then just render the template. > > Tim wrote and article about rewriting > http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework > > Also, I've been using the Locs from CRUDify as an example of how to do > more custom-type Locs with rewriting. > > /Jeppe > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Problem to process a PUT request in a lift API
Hello guys,
I have created an API to process a PUT request and a GET request. The
GET works perfectly fine, but with the PUT the XML seems to be lost in
its way. I have the following code:
def dispatch: LiftRules.DispatchPF = {
case Req("api" :: "person" :: userName :: Nil, "",
GetRequest) =>
() => showPerson(userName)
case r @ Req(List("api", "person"), "", PutRequest) =>
() => addPerson(r)
}
In the addPerson method I have the following code:
req.xml match {
case Full({parameters @_*}) => {
for(parameter <- parameters){ parameter match {
All the XML parsing
}
}
try {
person.validate match {
case Nil =>
person.save
CreatedResponse(wrapXmlBody
(), "text/xml")
case _ =>
CreatedResponse(wrapXmlBody
(), "text/xml")
}
}
catch {
case e => Log.error("Could not add person",
e); BadResponse()
}
}
case _ => Log.error("Request was malformed "+req.view);
BadResponse()
}
The method always goes through the last case: "Request was malformed".
I was checking the values to req.view and req.xml.toString and the
results are "person" and empty, respectively.
Any ideas about what it could be happening?
Thanks in advance,
GA
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from 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: A Critique On Lift
bob wrote: > i believe that one of the best ways to learn a new programming > language is to read software written in it > > when reading Scala code, I rarely say "i don't understand how that > works" and when I do, there's usually a good explanation of it > somewhere on the web. > > usually I find myself asking "where is that defined?" or "what part of > the language is that?" > > Scala is not like, for example, BASIC, where you can look up FOR, IF/ > THEN/ELSE. there's lots of individual and compound punctuation marks > that are very difficult to search for online and in PDFs (try > searching for "!"). Indeed, but even cursory survey of scala will reveal that scala has no operators, only methods. This leads the user to search for docs on type of instance on which the punctuated invocation is made. I don't see the confusion there. You could of course make an argument on implicits ... > > a lot of scala also relies on syntactic sugar, such as omitted types > (no ": T" after a val/var/def); the dreaded underbar; operator > overloading; and implicit conversions. you can hate on Java's > verbosity (i know i have), but brevity has its own difficulties. > > On Oct 22, 11:44 pm, Naftoli Gugenheim wrote: >> The last use of _, as in empty_?, is not a special scala meaning. As on >> Java, underscores can be part of an identifier. Scala takes advantage of >> this to combine letters and symbols in one name. These names, like empty_?, >> are a Lift convention, as well as ..._! for use-with-care methods. The scala >> library uses isEmpty. David, is it your original convention?. >> >> - >> >> tiro wrote: >>> override def validations = validPriority _ :: super.validations >> funny, I had stumbled on exactly the same line of code when beginning. >> Took me more than a day to understand what's going on. Especially >> because when you copied code from the PDF version of the Liftbook/Lift >> getting started guide, it would mess up spaces, so I would keep >> loooking for a "_::" operator. >> The Scala guys have really pushed it a bit hard on the use of the >> underscore. At least four different uses: >> - "it" for defining anonymous functions like above >> - default value >> - matching placeholder whose value is ignored >> - use for constructing setter method names boolean functions (empty_?) > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
i believe that one of the best ways to learn a new programming language is to read software written in it when reading Scala code, I rarely say "i don't understand how that works" and when I do, there's usually a good explanation of it somewhere on the web. usually I find myself asking "where is that defined?" or "what part of the language is that?" Scala is not like, for example, BASIC, where you can look up FOR, IF/ THEN/ELSE. there's lots of individual and compound punctuation marks that are very difficult to search for online and in PDFs (try searching for "!"). a lot of scala also relies on syntactic sugar, such as omitted types (no ": T" after a val/var/def); the dreaded underbar; operator overloading; and implicit conversions. you can hate on Java's verbosity (i know i have), but brevity has its own difficulties. On Oct 22, 11:44 pm, Naftoli Gugenheim wrote: > The last use of _, as in empty_?, is not a special scala meaning. As on Java, > underscores can be part of an identifier. Scala takes advantage of this to > combine letters and symbols in one name. These names, like empty_?, are a > Lift convention, as well as ..._! for use-with-care methods. The scala > library uses isEmpty. David, is it your original convention?. > > - > > tiro wrote: > > override def validations = validPriority _ :: super.validations > > funny, I had stumbled on exactly the same line of code when beginning. > Took me more than a day to understand what's going on. Especially > because when you copied code from the PDF version of the Liftbook/Lift > getting started guide, it would mess up spaces, so I would keep > loooking for a "_::" operator. > The Scala guys have really pushed it a bit hard on the use of the > underscore. At least four different uses: > - "it" for defining anonymous functions like above > - default value > - matching placeholder whose value is ignored > - use for constructing setter method names boolean functions (empty_?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] How to create an rss?
hi guys,
I'm looking for a way to generate an rss feed with lift, I'm working
on something like this (from lift-book):
object OwnRssFeed extends XMLApiHelper {
def dispatch: LiftRules.DispatchPF = {
case Req("rss" :: Nil, "", GetRequest) => () => showArticles()
case Req("rss" :: _ :: Nil, "", _) => failure _
}
def failure() : LiftResponse = {
val ret: Box[NodeSeq] = Full()
NotFoundResponse()
}
def createTag(in: NodeSeq) = {
println("[CreateTag] " + in)
title
http://example.org
Example.org
en-us
Lift WebFramework
{in}
}
def showArticles(): LiftResponse = {
val a: Box[NodeSeq] = for(a <- Article.find(By
(Article.published, true))) yield {
a.toXML
}
a
}
}
obviously the yield into the definition of showArticles method break
the cycle to the first one.
Could you suggest me what I can do? I am evaluating lift and scala
just in a while.
Thanks for your attention.
w.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Welcome Dirk Louwers to the Lift committers
Welkom Dirk, Je moet de HU ook echt te makkelijk vinden? je zit nu in de tweede? I'll continue in english ;) . As a fellow Dutchman I couldn't resist googlening you. I found out that we're going to the same School (HU). I'm a third year student and doing my internship in the US atm. I'll be back at the HU in the second semester, we should definitely meet up! groeten, Michel On Oct 23, 8:39 am, Dirk Louwers wrote: > Hi all, > > Sorry for the late update. Had a few busy weeks business wise. > > I am a Dutch self taught software writer. I am running my own company > from home and planning to use lift to make rich web applications. > Meanwhile I work part time as a coder for a healthcare company to pay > the bills. I have mainly focussed on web applications so far. I > started with PHP, then moved to C# (.NET) and am finally looking at > the java side of web applications through scala since recently. I have > done some small open source contributions, like Spring.NET Db4o > (object database) integration. > > Like David said, I am indeed planning to integrate Ext 3 Core into > Lift, which is a modest contribution. After that I am planning to > create an Ext Direct stack which will probably be an external module. > > Best, > > Dirk > > On 15 okt, 19:16, Timothy Perrett wrote: > > > > > Welcome to the team dude - care to give some information about > > yourself and background? > > > Cheers, Tim > > > On Oct 15, 4:46 pm, David Pollak > > wrote: > > > > Folks, > > > Please join me in welcoming Dirk to theLift committers. Dirk is going to > > > integrate Ext.Js (the MIT licensed part of it) into Lift. > > > > Welcome Dirk and we look forward to your contributions! > > > > 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 liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
All, the _ "name" is also used frequently in C++ for template-based lambdas. At least it is in many of the Boost libraries. Jeremy On Fri, Oct 23, 2009 at 2:37 AM, Viktor Klang wrote: > My personal interpretation is "sh!t I don't know here or don't care what it > is" > > > On Fri, Oct 23, 2009 at 9:08 AM, Joni Freeman wrote: > >> >> I love it too. While it is used in many different places it always >> means "stuff that I do not care to name". >> >> BTW. "high priest of the lambda calculus" loves it too :) It has its >> roots in Haskell... >> >> >> http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-4-of-13/ >> >> Cheers Joni >> >> On 23 loka, 09:48, Jonas Bonér wrote: >> > I love the _ operator. >> > >> > 2009/10/22 Timothy Perrett : >> > >> > >> > >> > >> > >> > > I think this is a bit of a running joke in the scala comunity right >> > > now - your right, underscore really does have a number of meanings; I >> > > think this will be changed in some future Scala release. >> > >> > > Your also forgetting: >> > >> > > import some.package._ >> > >> > > Cheers, Tim >> > >> > > On 22 Oct 2009, at 12:57, tiro wrote: >> > >> > >> underscore. At least four different uses: >> > >> - "it" for defining anonymous functions like above >> > >> - default value >> > >> - matching placeholder whose value is ignored >> > >> - use for constructing setter method names boolean functions >> (empty_?) >> > >> > -- >> > Jonas Bonér >> > >> > twitter: @jboner >> > blog:http://jonasboner.com >> > work: http://scalablesolutions.se >> > code: http://github.com/jboner >> > code: http://akkasource.org >> > also:http://letitcrash.com >> >> > > > -- > Viktor Klang > | "A complex system that works is invariably > | found to have evolved from a simple system > | that worked." - John Gall > > Blog: klangism.blogspot.com > Twttr: viktorklang > Code: github.com/viktorklang > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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] Announcing the Lift Announce group/mailing list **IMPORTANT**
Folks, After yesterday's issues surrounding the breaking changes in Lift, I've decided to create a low volume group called Lift Announce. You can see the group at http://groups.google.com/group/lift-announce?lnk=gcimh This group is an announce-only group which means that only the Lift committers will post to the group. Lift Announce will contain: announcements of Lift releases and milestone releases, invitations to comment about release planning (basically, if we're having a release planning discussion on the main list, we'll announce this so folks can participate in choosing features for the next release), and announcements about breaking changes. I expect than on average, there will be 1 post per week to this list. If you are using Lift actively, it is very important to subscribe to this list. It will be your guide to changes in 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Welcome Dirk Louwers to the Lift committers
Hi all, Sorry for the late update. Had a few busy weeks business wise. I am a Dutch self taught software writer. I am running my own company from home and planning to use lift to make rich web applications. Meanwhile I work part time as a coder for a healthcare company to pay the bills. I have mainly focussed on web applications so far. I started with PHP, then moved to C# (.NET) and am finally looking at the java side of web applications through scala since recently. I have done some small open source contributions, like Spring.NET Db4o (object database) integration. Like David said, I am indeed planning to integrate Ext 3 Core into Lift, which is a modest contribution. After that I am planning to create an Ext Direct stack which will probably be an external module. Best, Dirk On 15 okt, 19:16, Timothy Perrett wrote: > Welcome to the team dude - care to give some information about > yourself and background? > > Cheers, Tim > > On Oct 15, 4:46 pm, David Pollak > wrote: > > > Folks, > > Please join me in welcoming Dirk to theLift committers. Dirk is going to > > integrate Ext.Js (the MIT licensed part of it) into Lift. > > > Welcome Dirk and we look forward to your contributions! > > > 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 liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
I *think* you're referring to a thread I started some time ago: http://www.nabble.com/functional-newbie,-domain-entities-td22957479.html It turned out to be a lively discussion. On a related note, Jonas Boner gisted this in August: http://gist.github.com/173921 It's not full code, but it gives you an idea how an immutable data model might be composed and backed with JPA. There are pain points (java collections) and unanswered questions here (how will the JPA provider initialize such a class), but there's what I feel is a language-level issue. In Scala, if you want methods to immutably evolve an objects' state, then you must, as Jonas did, write your own "setters" that yield a new instance with the modification. Sounds like boilerplate to me, that's another topic. For the record, I'm not yet fully convinced of the gains in using immutability in a domain model. Domain entities represent the state of an application, and in many cases that changes frequently and naturally. Period. How and why those changes occur are often the result of human behavior (twitter, facebook). These behaviors are not functional in the mathematical sense (at least, not that we've discovered), and so I'm not clear on what we stand to gain in a typical domain model. Naftoli Gugenheim wrote: > How hard can automatic save be? > But how would immutable DAOs work? There was a thread, I think on scala-user, > a long time ago discussing it, that pretty much concluded it would be very > problematic. David weighed in and said after a long time he concluded that > databases represent state. > > > - > Timothy Perrett wrote: > > > Right, no one likes mutable anything :-) > > I kinda wondered why you haven't pushed forward any more with the > current record implementation... can one assume that is why - because > it didn't feel right? > > Some of this stuff is going to be fundamental to how we move forward - > id love to perhaps discuss something that would be better than what we > have already. Even if its just pie in the sky talk... > > Cheers, Tim > > On 22 Oct 2009, at 17:22, David Pollak wrote: > >> I don't like mutable fields. I don't like manual saving. Dunno... >> it's hard to articulate... it just feels wrong in my tummy. Also, I >> want to be clear that I think Marius did a great job of cleaning up >> some of the problems with Mapper when he did Record... my comments >> are not a negative to him... there's just something unsatisfying >> about the whole approach. >> >> Bet that was less than helpful. > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
My personal interpretation is "sh!t I don't know here or don't care what it is" On Fri, Oct 23, 2009 at 9:08 AM, Joni Freeman wrote: > > I love it too. While it is used in many different places it always > means "stuff that I do not care to name". > > BTW. "high priest of the lambda calculus" loves it too :) It has its > roots in Haskell... > > > http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-4-of-13/ > > Cheers Joni > > On 23 loka, 09:48, Jonas Bonér wrote: > > I love the _ operator. > > > > 2009/10/22 Timothy Perrett : > > > > > > > > > > > > > I think this is a bit of a running joke in the scala comunity right > > > now - your right, underscore really does have a number of meanings; I > > > think this will be changed in some future Scala release. > > > > > Your also forgetting: > > > > > import some.package._ > > > > > Cheers, Tim > > > > > On 22 Oct 2009, at 12:57, tiro wrote: > > > > >> underscore. At least four different uses: > > >> - "it" for defining anonymous functions like above > > >> - default value > > >> - matching placeholder whose value is ignored > > >> - use for constructing setter method names boolean functions (empty_?) > > > > -- > > Jonas Bonér > > > > twitter: @jboner > > blog:http://jonasboner.com > > work: http://scalablesolutions.se > > code: http://github.com/jboner > > code: http://akkasource.org > > also:http://letitcrash.com > > > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Blog: klangism.blogspot.com Twttr: viktorklang Code: github.com/viktorklang --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from 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: A Critique On Lift
I love it too. While it is used in many different places it always means "stuff that I do not care to name". BTW. "high priest of the lambda calculus" loves it too :) It has its roots in Haskell... http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-4-of-13/ Cheers Joni On 23 loka, 09:48, Jonas Bonér wrote: > I love the _ operator. > > 2009/10/22 Timothy Perrett : > > > > > > > I think this is a bit of a running joke in the scala comunity right > > now - your right, underscore really does have a number of meanings; I > > think this will be changed in some future Scala release. > > > Your also forgetting: > > > import some.package._ > > > Cheers, Tim > > > On 22 Oct 2009, at 12:57, tiro wrote: > > >> underscore. At least four different uses: > >> - "it" for defining anonymous functions like above > >> - default value > >> - matching placeholder whose value is ignored > >> - use for constructing setter method names boolean functions (empty_?) > > -- > Jonas Bonér > > twitter: @jboner > blog: http://jonasboner.com > work: http://scalablesolutions.se > code: http://github.com/jboner > code: http://akkasource.org > also: http://letitcrash.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
