[Lift] Fwd: [scala-internals] Re: Scala advertising at Stack Overflow

[Jorge Ortiz]

Lift might be interested in this too.

--j

Forwarded conversation
Subject: [scala-internals] Scala advertising at Stack Overflow


From: *Daniel Sobral* 
Date: Sat, Dec 19, 2009 at 8:29 AM
To: scala-internals 


Should EPFL endeavor to get some free advertising for Scala at Stack
Overflow, as described at
http://blog.stackoverflow.com/2009/12/free-vote-based-advertising-for-open-source-projects/
?

The required work consists of little more than producing a 220x220 Scala
advertising image and posting it at the proper (time-wise) thread tagged
open-source-advertising on meta.stackoverflow.com (
http://meta.stackoverflow.com/questions/tagged/open-source-advertising). The
exact details can be found in that post (presently,
http://meta.stackoverflow.com/questions/31913/open-source-advertising-sidebar-1h-2010
).

-- 
Daniel C. Sobral

I travel to the future all the time.

--
From: *Daniel Sobral* 
Date: Sat, Dec 19, 2009 at 8:48 AM
To: scala-internals 


Looking at some ads already posted, I think it is necessary to make a
clarification. These ads are not intended to be product ads, but open source
projects ads. Or, in other words, to attract interest from people interested
in working at these projects.

--

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

Re: [Lift] foursquare.com now basically all on Lift

[Jorge Ortiz]

I've been MIA from the Lift community recently, but I've gotta say I love
Foursquare and use it almost every day. It gives me even more warm fuzzies
to know that it's using Lift under the hood :)

Thanks for a great app!

--j

On Tue, Nov 17, 2009 at 12:16 PM, harryh  wrote:

> I've been a bit coy about it on the list, but three months ago when I
> joined the team at foursquare.com I made the final decision that we
> would port our webservers to Scala/Lift.  It took about 3 months, but
> foursquare.com is now basically running only on Lift(1).  This
> includes the website, a mobile website (m.foursquare.com) and a simple
> (but growing!) REST api (api.foursquare.com).
>
> I'd like the send a huge thank you to dpp and the rest of the Lift
> team. You've built a really great framework here, and I look forward
> to using it and seeing it grow for many years to come. An additional
> thanks goes out to all those who have answered my many random
> questions over the past couple of months.
>
> For those who haven't yet found out about foursquare, you can read
> more about it here: http://foursquare.com/learn_more
>
> Anyways, that's about enough self promotion, but I did want to
> officially let the community know about what I hope will be a fairly
> high profile site that is using Lift.
>
> -harryh
>
> (1) Haven't quite ported feeds.foursquare.com, and there is a legacy
> PHP based REST api that will live on for a bit longer as it supports
> current versions of our iPhone app.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>

--

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

Re: Lift + Scala 2.8 (Was: Re: [Lift] Re: Is there any eclipse setup that actually works for lift?)

[Jorge Ortiz]

No, sorry. I haven't spent any more time on this.

--j

On Thu, Jul 23, 2009 at 10:13 PM, Naftoli Gugenheim wrote:

> Any update on this?
>
>
> On Mon, Jun 22, 2009 at 10:55 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Mon, Jun 22, 2009 at 7:51 PM, Jorge Ortiz wrote:
>>
>>> I just spent all afternoon trying to get stuff to compile with Scala 2.8.
>>>
>>> Since Lift depends on Specs, and Specs depends on Scalacheck, I started
>>> trying to port Scalacheck to 2.8 so I could port Specs to 2.8 so I could
>>> port Lift. It was unable to get Scalacheck to compile due to bugs which
>>> cause the compiler to choke and throw an exception. Apparently both paulp
>>> and Iulian have tried to compile Scalacheck with 2.8 before and failed.
>>>
>>> Giving up on Specs and Scalacheck, I decided to try to compile Lift (sans
>>> tests) with 2.8. After fixing some of the breaking changes that 2.8
>>> introduces, I again ran into compiler troubles. In principle, with a lot of
>>> sleuthing I could figure out what code is causing the compiler to choke and
>>> give the compiler more type hints or whatever. Unfortunately this requires
>>> more work than I can put in today.
>>>
>>> Conclusion: 2.8 is basically unusable right now.
>>>
>>> (I'll check in my progress to GitHub later tonight or tomorrow.)
>>
>>
>> Thanks for your hard work!
>>
>>
>>>
>>>
>>> --j
>>>
>>> On Mon, Jun 22, 2009 at 11:35 AM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jun 22, 2009 at 11:25 AM, Ellis wrote:
>>>>
>>>>>
>>>>> Hello David,
>>>>>
>>>>> Thanks for your reply.  Do you know whether lift *should* work with
>>>>> scala 2.8 when we pull it from the maven repositories?
>>>>
>>>>
>>>> Lift currently only works with Scala 2.7.4.  You can use Eclipse and
>>>> 2.7.5 to edit Lift files, but Lift must be deployed against 2.7.4.
>>>>
>>>> We will have a branch of Lift (Jorge... you got this running yet)
>>>> building against 2.8, but it will be experimental.
>>>>
>>>> I have experienced a fair number of suboptimalities with Lift and
>>>> Eclipse in the last 3 weeks with the 2.7.5 stable plugin.  I have had
>>>> success recently with NetBeans, IntelliJ, and emacs.
>>>>
>>>>
>>>>>  If so, then
>>>>> I'll try deleting my ~/.m2 as Tim suggested.
>>>>>
>>>>> Thanks,
>>>>> Ellis
>>>>>
>>>>>
>>>>> On Jun 22, 8:14 pm, David Pollak 
>>>>> wrote:
>>>>> > Ellis,
>>>>> > Miles will be back online in a few days, but I suspect that the
>>>>> answer is
>>>>> > that the 2.8 plugin is the "new generation" and the 2.7.5 stuff is
>>>>> going to
>>>>> > have bugs. :-(
>>>>> >
>>>>> > Sorry.
>>>>> >
>>>>> > David
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Mon, Jun 22, 2009 at 11:08 AM, Ellis 
>>>>> wrote:
>>>>> >
>>>>> > > Hello everyone,
>>>>> >
>>>>> > > Does anyone have a setup for eclipse that works like it should?  By
>>>>> > > "like it should", I mostly mean that the scala plugin doesn't crash
>>>>> > > regularly AND it works with lift/maven.  If so, which versions of
>>>>> > > which plugins are you using?
>>>>> >
>>>>> > > The nightly build of the scala plugin seems to work better than
>>>>> > > 2.7.4/2.7.5 in some ways, but I couldn't get it working with lift/
>>>>> > > maven due to "signature differences" between the scala libraries.
>>>>> >
>>>>> > > Best regards,
>>>>> > > Ellis
>>>>> >
>>>>> > --
>>>>> > Lift, the simply functional web frameworkhttp://liftweb.net
>>>>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>>>>> > Follow me:http://twitter.com/dpp
>>>>> > Git some:http://github.com/dpp
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lift, the simply functional web framework http://liftweb.net
>>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>>>
>>>> Follow me: http://twitter.com/dpp
>>>> Git some: http://github.com/dpp
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: http://wiki.liftweb.net request

[Jorge Ortiz]

All you have to do is register for an account. Anonymous edits aren't
allowed.

--j

On Fri, Jul 10, 2009 at 11:09 PM, DFectuoso  wrote:

>
> How can people get editing power on the wiki? Is it intended to be
> used as a (real) wiki? Who is responsable right now for hosting that
> and keeping it up?
>
> I was fizzling around today with mySql and lift following the advice
> there and decided I would like to expand the article with some
> problems I had and how i solved and that kind of stuff =)
>
> >
>

--~--~-~--~~~---~--~~
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: Using Mapper outside Lift?

[Jorge Ortiz]

The OP claims his data model is simple enough for Mapper.

If he doesn't mind adding the lift-webkit jar to his classpath, I don't see
a problem with using Mapper.

--j

On Tue, Jun 23, 2009 at 10:46 AM, Timothy Perrett
wrote:

>
>
> I didn¹t say that it *wouldn¹t* work, just that its tied to lift-webkit...
> Besides, he says that he will be doing a lot of data intensive processing -
> seems like JPA would play better there as Mapper is usually has a ceiling
> of
> functionality and then it becomes necessary to move to JPA anyway. IMHO,
> might as well save the recoding time and just work with JPA right away if
> he
> knows from the start that he will have tricky data ORM tasks.
>
> Cheers, Tim
>
> On 23/06/2009 18:28, "Jorge Ortiz"  wrote:
>
> > I've used Mapper in desktop apps too. It works fine.
> >
> > --j
> >
> > On Tue, Jun 23, 2009 at 9:56 AM, Naftoli Gugenhem 
> > wrote:
> >>
> >> I used mapper in an offline (demo) app. You have to include the util and
> http
> >> jars IIRC but it's a desktop app. If you're subcribed to scala-user, I
> posted
> >> it (I think last week) in the thread about a scala SWT DSL.
> >>
> >> -
> >> Timothy Perrett wrote:
> >>
> >>
> >> Hi Joe,
> >>
> >> Mapper does not work standalone, its not like ActiveRecord in that
> >> sense - its tied to lift-webkit. Your best bet would be to go with
> >> JPA; I think that will serve you better anyway.
> >>
> >> Cheers, Tim
> >>
> >> On Jun 23, 4:47 pm, Joe Wass  wrote:
> >>> Good afternoon (at least in England),
> >>>
> >>> I'm writing an application which has a significant Lift manifestation,
> >>> but also some stand-alone Scala (maybe even Java but I'll exclude this
> >>> from the conversation). The stand-alone code is a set of tools that
> >>> hang off the database and do some heavy-lifting with the data in the
> >>> database, out of sync with the site. Something like periodic data-
> >>> crunching from the data on the site. The question comes down to
> >>> database mapping.
> >>>
> >>> I was wondering what people think is a sensible way of doing this. My
> >>> data model is simple enough that Mapper could work and I could use the
> >>> same classes. I'm aware there are many different ways I could do it,
> >>> but it would be nice to do it that way for the sake of simplicity.
> >>>
> >>> Does this sound a sensible approach? Has anyone else written an app
> >>> that's half online, half offline? Are there any obvious pitfalls?
> >>>
> >>> Cheers
> >>>
> >>> Joe
> >>
> >>
> >>
> >
> >
> > >
> >
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Using Mapper outside Lift?

[Jorge Ortiz]

I've used Mapper in desktop apps too. It works fine.

--j

On Tue, Jun 23, 2009 at 9:56 AM, Naftoli Gugenhem wrote:

>
> I used mapper in an offline (demo) app. You have to include the util and
> http jars IIRC but it's a desktop app. If you're subcribed to scala-user, I
> posted it (I think last week) in the thread about a scala SWT DSL.
>
> -
> Timothy Perrett wrote:
>
>
> Hi Joe,
>
> Mapper does not work standalone, its not like ActiveRecord in that
> sense - its tied to lift-webkit. Your best bet would be to go with
> JPA; I think that will serve you better anyway.
>
> Cheers, Tim
>
> On Jun 23, 4:47 pm, Joe Wass  wrote:
> > Good afternoon (at least in England),
> >
> > I'm writing an application which has a significant Lift manifestation,
> > but also some stand-alone Scala (maybe even Java but I'll exclude this
> > from the conversation). The stand-alone code is a set of tools that
> > hang off the database and do some heavy-lifting with the data in the
> > database, out of sync with the site. Something like periodic data-
> > crunching from the data on the site. The question comes down to
> > database mapping.
> >
> > I was wondering what people think is a sensible way of doing this. My
> > data model is simple enough that Mapper could work and I could use the
> > same classes. I'm aware there are many different ways I could do it,
> > but it would be nice to do it that way for the sake of simplicity.
> >
> > Does this sound a sensible approach? Has anyone else written an app
> > that's half online, half offline? Are there any obvious pitfalls?
> >
> > Cheers
> >
> > Joe
>
>
> >
>

--~--~-~--~~~---~--~~
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 + Scala 2.8 (Was: Re: [Lift] Re: Is there any eclipse setup that actually works for lift?)

[Jorge Ortiz]

I just spent all afternoon trying to get stuff to compile with Scala 2.8.

Since Lift depends on Specs, and Specs depends on Scalacheck, I started
trying to port Scalacheck to 2.8 so I could port Specs to 2.8 so I could
port Lift. It was unable to get Scalacheck to compile due to bugs which
cause the compiler to choke and throw an exception. Apparently both paulp
and Iulian have tried to compile Scalacheck with 2.8 before and failed.

Giving up on Specs and Scalacheck, I decided to try to compile Lift (sans
tests) with 2.8. After fixing some of the breaking changes that 2.8
introduces, I again ran into compiler troubles. In principle, with a lot of
sleuthing I could figure out what code is causing the compiler to choke and
give the compiler more type hints or whatever. Unfortunately this requires
more work than I can put in today.

Conclusion: 2.8 is basically unusable right now.

(I'll check in my progress to GitHub later tonight or tomorrow.)

--j

On Mon, Jun 22, 2009 at 11:35 AM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

>
>
> On Mon, Jun 22, 2009 at 11:25 AM, Ellis  wrote:
>
>>
>> Hello David,
>>
>> Thanks for your reply.  Do you know whether lift *should* work with
>> scala 2.8 when we pull it from the maven repositories?
>
>
> Lift currently only works with Scala 2.7.4.  You can use Eclipse and 2.7.5
> to edit Lift files, but Lift must be deployed against 2.7.4.
>
> We will have a branch of Lift (Jorge... you got this running yet) building
> against 2.8, but it will be experimental.
>
> I have experienced a fair number of suboptimalities with Lift and Eclipse
> in the last 3 weeks with the 2.7.5 stable plugin.  I have had success
> recently with NetBeans, IntelliJ, and emacs.
>
>
>>  If so, then
>> I'll try deleting my ~/.m2 as Tim suggested.
>>
>> Thanks,
>> Ellis
>>
>>
>> On Jun 22, 8:14 pm, David Pollak 
>> wrote:
>> > Ellis,
>> > Miles will be back online in a few days, but I suspect that the answer
>> is
>> > that the 2.8 plugin is the "new generation" and the 2.7.5 stuff is going
>> to
>> > have bugs. :-(
>> >
>> > Sorry.
>> >
>> > David
>> >
>> >
>> >
>> > On Mon, Jun 22, 2009 at 11:08 AM, Ellis 
>> wrote:
>> >
>> > > Hello everyone,
>> >
>> > > Does anyone have a setup for eclipse that works like it should?  By
>> > > "like it should", I mostly mean that the scala plugin doesn't crash
>> > > regularly AND it works with lift/maven.  If so, which versions of
>> > > which plugins are you using?
>> >
>> > > The nightly build of the scala plugin seems to work better than
>> > > 2.7.4/2.7.5 in some ways, but I couldn't get it working with lift/
>> > > maven due to "signature differences" between the scala libraries.
>> >
>> > > Best regards,
>> > > Ellis
>> >
>> > --
>> > Lift, the simply functional web frameworkhttp://liftweb.net
>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > Follow me:http://twitter.com/dpp
>> > Git some:http://github.com/dpp
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
>
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: scalajpa - while accessing two distincts databases, the second access is made with a connection to the first database

[Jorge Ortiz]

In Derek's defense, it's not how objects in classes work but how Lift
RequestVars work. Scala objects in classes aren't global singletons, just
per-class-instance singletons. But a Lift ReuqestVar object in a class is
pretty much a global singleton (unless you do some hacking like Derek did).

--j

On Tue, Jun 16, 2009 at 11:14 PM, Derek Chen-Becker
wrote:

> I agree that it's an issue. In my own defense, what I meant was not that I
> didn't think people would use more than one DB. I actually have several apps
> (not yet converted to Lift) that use 4 or more persistence units that
> represent various legacy databases. Rather, I failed to realize the problem
> that would arise from defining the EM factory as a singleton because when I
> wrote that code I didn't fully understand how member objects on classes
> worked. Other than that, I agree with your post :)
> Derek
>
> On Tue, Jun 16, 2009 at 5:38 PM, Meredith Gregory <
> lgreg.mered...@gmail.com> wrote:
>
>> Derek,
>>
>> 
>> You have just demonstrated a process that i have been talking about for
>> the last 15 years. People have a blind spot when it comes to thinking
>> compositionally. They think -- almost to a person -- about "god's eye view"
>> solutions where there's only one of some key solution component. They don't
>> think about solutions that are composed of ... (wait for it)... solutions!
>> It takes some serious training to think compositionally. Compositional
>> solutions, however, are the only realistic way to scale. When solutions are
>> compositional, you can *de*compose. The db example is a case in point.
>> One of the most natural ways to scale data access is sharding and
>> partitioning -- which requires upfront machinery to support decomposition of
>> the store.
>>
>> Lest you feel bad, note that some of the best scientific minds of all time
>> have fallen prey to this blind spot. Newtonian physics as well as Einstein's
>> update to Newton's proposal is a non-compositional solution. Quantum
>> mechanics also exhibits compositional failures. This is why physics is
>> failing to find proposals that link theories of gravitation (essentially
>> large scale) to quantum mechanical theories of the other forces (essentially
>> very small scale) -- the physical theories are non-compositional -- they
>> don't scale!
>>
>> One of the real things functional programming has going for it is that the
>> basic model of computation underlying the means of structuring and
>> manipulating programs is compositional. That's why it is important to have a
>> technology like Scala resting atop the incumbent execution model (JVM) being
>> deployed on web-scale problems. Compositionality is the only way to tackle
>> applications at global scale.
>> 
>>
>> Thanks for getting the fix to this problem in so quickly.
>>
>> Best wishes,
>>
>> --greg
>>
>>
>> On Tue, Jun 16, 2009 at 11:53 AM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> Using multiple EMs was not something I had considered when I wrote this.
>>> I think that I can modify the code to provide a __nameSalt def to
>>> differentiate instances. Let me work on it and I'll have something soon.
>>>
>>> Derek
>>>
>>>
>>> On 6/16/09, Jean-Luc  wrote:

 For your information, here is an extract of source code of RequestVarEM
 :

 Trait RequestVarEM extends ScalaEntityManager with ScalaEMFactory {
object emVar extends RequestVar[EntityManager](openEM()) { ... }
 }

 EntityManager is stored in the singleton emVar; so, all db access of
 Model objects are made using the singleton emVar.
 => trait RequestVarEM allow only one connection to a database within the
 same HttpRequest context.


 Jean-Luc

 2009/6/15 Jean-Luc 

>  Hello,
>
> I have two databases, db1 (a.k.a. Motorbike) and db2 (a.k.a. Motorway)
> defined with RequestVarEM :
> - object ModelDb1 extends LocalEMF("db1") with RequestVarEM  //
> Motorbike database
> - object ModelDb2 extends LocalEMF("db2") with RequestVarEM  //
> Motorway database
>
> I thought one could access to any databases independently from any
> snippet as long as the correct Model object were used (ModelDb1 or 
> ModelDb2
> for exemple) ; but when I access both databases from the same page, the
> second database access issues a "Named query not found" exception.
>
> I have two snippets, one to display a list of "motorbike", another to
> display a list of "motorway" :
> - page1 :
> ModelDb1.createNamedQuery[Motorbike]("Motorbike.findAll).getResultList() 
> =>
> ok
> - page2
> : ModelDb2.createNamedQuery[Motorway]("Motorway.findAll).getResultList() 
> =>
> ok
> - page3 : calling from page 3 motorbike & motorway snippets : Named
> query not found: Motorway.findAll
> - page4 : calling from page 4 motorway & motorbike snippets : Named
> query not found: Motorbike.findAll
> - page3 & cha

[Lift] Re: Cheap Hosting

[Jorge Ortiz]

Another option is http://prgmr.com/xen/

You can get as much RAM as Slicehost for only $8/mo (but slightly less
storage and data transfer).

The support will be much more barebones, though.

--j

On Mon, Jun 15, 2009 at 2:01 PM, Mark Lynn  wrote:

>
> I want to thank everyone that replied on this. Derek's suggestion of GAE is
> intriguing and I am at least going to check it out - I'm a little weary of
> that persistence situation with GAE since I don't have any experience with
> JDO or JPA. However, if GAE does not work out, I like the Mosso approach
> suggested by Tim below. This app has very minimal bandwidth requirements so
>  I suspect Mosso will be cheaper than Slicehost. Thanks again!
>
> Mark Lynn
>
>
> On Jun 15, 2009, at 9:50 AM, Tim Nelson wrote:
>
> You might want to also look into Mosso's Cloud Servers. They use
> Slicehosts' technology (Slicehost was purchased by rackspace, which owns
> mosso), but don't package the bandwidth in the price. If you have small
> bandwidth needs, it will be a little cheaper.
> Another alternative is mor.ph. It is a PaaS that has JavaEE as a choice.
> You just upload your WAR and off you go. I haven't tried this with a Lift
> app yet, but it should work.
>
> On Mon, Jun 15, 2009 at 8:28 AM, Jeremy Day  wrote:
>
>> Mark,
>>
>> It is my understanding (and this could be incorrect, of course) that you
>> can do whatever you want on a Slicehost Slice.  You can install whatever
>> Java applications you like.  You have total control.
>>
>> Jeremy
>>
>>
>> On Mon, Jun 15, 2009 at 8:02 AM, Mark Lynn  wrote:
>>
>>>
>>> Thanks. That is certainly very reasonable and VPS hosting is definitely a
>>> possibility. I guess what I am asking is whether there is shared hosting in
>>> the Java realm where you can also install Scala and LIft? I'm assuming the
>>> answer is not yet, but I thought I would ask.
>>>
>>>  Mark Lynn
>>>
>>>
>>> On Jun 14, 2009, at 11:56 PM, David Pollak wrote:
>>>
>>> Mark,
>>> You should be able to host a moderately trafficked site (400 unique
>>> visitors an hour) with a $20 slicehost.com account.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> On Sun, Jun 14, 2009 at 4:40 PM, Mark Lynn  wrote:
>>>


 I have a web app that I am doing free for a charitable organization
 that is sensitive to hosting costs. I would like to make it my first
 Lift app since it is pretty straight-forward - simple database and
 will probably just use Mapper. Most of my previous experience is with
 Rails projects or projects that were hosted internally so I don't have
 much experience with java hosting services. Does anyone have a
 recommendation for an inexpensive hosting option where I can use scala/
 lift? With Rails or PHP I can find stuff for as little as $5/mth.

 Mark Lynn







>>>
>>>
>>> --
>>> Lift, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Git some: http://github.com/dpp
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
>
> >
>

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

Re: [scala] Re: [Lift] Programming in Scala #5, Lift Book #8, Beginning Scala #9

[Jorge Ortiz]

In addition to the Lift Workshop, I also co-taught a ten-week (1.5hrs/wk)
course at Stanford on Scala. It was targeted at advanced undergrads and
graduate students. Most were programming language enthusiasts, so the course
focused more on the interesting parts of Scala from a programming language
perspective, rather than a more practical here's-how-you-get-stuff-done
course (like the Lift Workshop).

--j

On Tue, Jun 9, 2009 at 2:33 AM, David Pollak
wrote:

> Luc,
> Jorge, Kaliya and I did a LiftWorkshop in November.  We had 6 people at the
> workshop.  We tried to pack in Scala and Lift all into a day... it didn't
> work.
>
> Jorge and I have done some review and we figure there's 3 days of Scala
> training and 2-3 days of Lift training that would be a minimum for folks to
> be able to go home and build Lift apps.  The To Do example (see
> http://liftweb.net/docs/getting_started.html ) would be one of the days
> (we gave it about an hour during the workshop and that was not nearly
> enough.)
>
> Thanks,
>
> David
>
> On Tue, Jun 9, 2009 at 1:23 AM, Luc Duponcheel 
> wrote:
>
>> here are some thoughts:
>>
>>  - agreeing upon the *what* is probably easier than agreeing upon the *
>> how*
>>for example: which IDE to use (if any) during the labs [ Eclipse,
>> Netbeans, ... ] .
>>My experience is that the description of how to do labs should be
>> independent
>>of any tools (it does not make sense to explicitely state things like:
>> in Netbeans
>>go to this submenu and select that choice and ... ).
>>
>>  - I think we should go for 'extreme course development' in the sense that
>>changes can be incorporated quickly (any text based format that
>>can (in a moderated way) be edited by many people is good
>>(e.g. LaTeX, assuming the existence of templates))
>>[ maybe git would be a perfect candidate for doing version management ]
>>Another advantage of using text based development is that consistency
>>can be automated: for example, code excerpts in slides can be extracted
>>programmatically from the code proper so that all changes to that code
>>are automatically propagated [ and also propagated in the embedded
>> slides
>>of student guides ]. I have some LateX templates (and Scala code) to
>> automate all this.
>>[ I have to agree that there is much room for improvement of the
>> look-and-feel
>> (it has been some time since I played around with LaTeX, and I'm not a
>> specialist
>>   of LaTeX's beamer package) ]
>>
>> - About the financial model: if it is joint work, then I do not think it
>> makes
>>   much sense to ask companies like Sun (or Oracle) money for the *
>> development*
>>   of the material. If they are willing to make the material part of their
>> curriculum
>>   (which implies: visibility via their catalogs),
>>   then we can make money by *delivering* the material.
>>   Whether or not the material itself should be freely downoadable by
>> anyone
>>   in the world is yet another matter. Again, maybe there should be some
>>   moderated group of people having access to the material.
>>
>>
>> ...
>>
>> Luc
>> On Tue, Jun 9, 2009 at 9:25 AM, Viktor Klang wrote:
>>
>>>
>>>
>>>  On Tue, Jun 9, 2009 at 8:21 AM, Luc Duponcheel <
>>> luc.duponch...@gmail.com> wrote:
>>>
 Hi all,

 I attended the talk on Scala and the talk on Lift.
 Both excellent talks!

 [ I did not attend the talk on Actors
 (I was cycling on the other side of the Golden Gate Bridge (Mt
 Tamalpais)) ]

 ...

 Those talks act as 'teasers' to make developers
 'eager to know more about Scala'.

 This is great!

 But, sometimes, I also have the impression that those talks
 'preach for those that are already converted'.

 The point I want to make is the following:

 when talking to developers about Scala,
 I am almost always confronted with the fact that they
 still think it has a 'steep learning curve'.
 I tell them that 'once you have climbed the mountain,
 you can enjoy the view over the landscape' (cfr Mt Tamalpais).

 So, I really think there is this need for *hands on training*.

 Maybe some of you folks should try to convince Sun (or Oracle) Education
 to invest in training courses. Not a simple task indeed, but, worth the
 effort
 (helps Scala becoming mainstream).

 ps: I agree that I'm partially saying this out of pure opportunism
 (I'm delivering Java courses for Sun Education, and, of course,
 I would be the first one to deliver Scala courses).

>>>
>>> Awesome idea.
>>>
>>> Would be great to establish some kind of curriculum with joint teaching
>>> material to be able to offer courses worldwide.
>>>
>>>


 Luc

   On Mon, Jun 8, 2009 at 5:40 PM, David Pollak <
 feeder.of.the.be...@gmail.com> wrote:

>  A big congratulations to the authors as well as the whole Scala
> community... 

[Lift] Re: Switch to Scala 2.7.5 for 1.1 ?

[Jorge Ortiz]

In general I thought the plan for 1.1 was to compile against 2.8.

If anything we might want a 1.0.1 against 2.7.5.

--j

On Wed, Jun 3, 2009 at 1:26 PM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> Hi,
> I wonder if we should switch to Scala 2.7.5. I do not know whether the
> actor fixes are relevant as Lift has got its own actor library now. But for
> users of the Scala IDE for Eclipse (like me) it might be beneficial, because
> the Scala IDE ships with 2.7.5.
>
> Cheers
> Heiko
> --
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: www.scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to 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: JTA

[Jorge Ortiz]

I, too, would like to see Transactions be monadic.

--j

On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
wrote:

> Jonas,
>
> i applaud the effort. i agree with DPP sentiments regarding annotations.
> That said, i feel pretty comfortable that transactions fit entirely in a
> monadic context. Since LINQ demonstrates that query fits into monadic
> context, and there's already at least one Scala implementation of 
> LINQ,
> might i suggest that you come up with a monadic presentation first and then
> map the sugar to that. My guess is that the sugar will be informed by the
> monadic presentation.
>
> To be suggestive... think of a context with a Tx object, TxCtxt, as like an
> Option widget. Then you do stuff inside a transaction via
>
> for ( myTransactedWidget <- TxCtxt if  ) yield {
>  }
>
> If you implement flatMap, yada, on TxCtxt you can have fun with nested
> transaction semantics. The point is that this should just work with a
> LINQ-like presentation of query.
>
> Best wishes,
>
> --greg
>
>
> On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér  wrote:
>
>>
>> I'll go for closures. Much simpler and less intrusive into Lift.
>> The current impl is based on Atomikos and Hibernate, I'll start with
>> pushing that in and we can make it pluggable later.
>> For example for Hibernate one need to add a line to the hibernate
>> config to register the
>> org.hibernate.transaction.TransactionManagerLookup class in order to
>> make Hibernate aware of our TX manager.
>>
>> Should I fork the github repo and submit patches or how do you guys work?
>>
>> /Jonas
>>
>>
>> 2009/5/29 Derek Chen-Becker :
>> > I'd vote for closures. We use annotations for JPA because we have to,
>> but
>> > IMHO closures provide a nicer semantic approach because they
>> syntactically
>> > enclose the block where the action is occurring.
>> >
>> > Derek
>> >
>> > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér  wrote:
>> >>
>> >> No perf difference. The annotations are turned into the same exact
>> >> closures.
>> >>
>> >> 2009/5/29 Timothy Perrett :
>> >> >
>> >> >
>> >> > Are there any performance implications considering closures vs
>> >> > annotations?
>> >> > Agreed that closures are more "lift like" however.
>> >> >
>> >> > Cheers, Tim
>> >> >
>> >> > On 29/05/2009 10:21, "marius d."  wrote:
>> >> >
>> >> >>
>> >> >> I think that would be really good. But I'd rather not use
>> annotations.
>> >> >> Personally I find closures approach a much better fit here.
>> >> >>
>> >> >> withTxRequired {
>> >> >>   ... // do transational stuff
>> >> >>
>> >> >> }
>> >> >>
>> >> >>
>> >> >> Br's,
>> >> >> Marius
>> >> >>
>> >> >> On May 29, 11:55 am, Jonas Bonér  wrote:
>> >> >>> Hi guys.
>> >> >>>
>> >> >>> I have been talking with David Pollak the rest of the lift team
>> about
>> >> >>> adding JTA to Lift. I have implemented that for a product written
>> in
>> >> >>> Scala some time ago. Now some of that code is OSS
>> >> >>> at:http://github.com/jboner/skalman/tree
>> >> >>>
>> >> >>> We used using two different APIs.
>> >> >>> 1. Annotations (would require Lift to support proxied objects, e.g.
>> >> >>> grab them from a factory):
>> >> >>>
>> >> >>> @TransactionAttribute(REQUIRED)
>> >> >>> def transactionalMethod = { ... }
>> >> >>>
>> >> >>> 2. Call-by-name:
>> >> >>>
>> >> >>> withTxRequired {
>> >> >>>   ... // do transational stuff
>> >> >>>
>> >> >>> }
>> >> >>>
>> >> >>> But I don't know what fits Lift and would like to know how you guys
>> >> >>> would like to have JTA integrated.
>> >> >>> At which level? Which APIs? Etc.
>> >> >>>
>> >> >>> --
>> >> >>> Jonas Bonér
>> >> >>>
>> >> >>> twitter: @jboner
>> >> >>> blog:http://jonasboner.com
>> >> >>> work:  http://crisp.se
>> >> >>> work:  http://scalablesolutions.se
>> >> >>> code:  http://github.com/jboner
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Jonas Bonér
>> >>
>> >> twitter: @jboner
>> >> blog:http://jonasboner.com
>> >> work:   http://crisp.se
>> >> work:   http://scalablesolutions.se
>> >> code:   http://github.com/jboner
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>>
>> --
>> Jonas Bonér
>>
>> twitter: @jboner
>> blog:http://jonasboner.com
>> work:   http://crisp.se
>> work:   http://scalablesolutions.se
>> code:   http://github.com/jboner
>>
>>
>>
>
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 1219 NW 83rd St
> Seattle, WA 98117
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.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
-~--~~~~--~~--~--~---

[Lift] Re: **IMPORTANT** Lift 1.1-SNAPSHOT now compiled against Scala 2.7.4

[Jorge Ortiz]

I had nothing to do with it. David beat me to it.

--j

On Sat, Apr 25, 2009 at 11:34 AM, Timothy Perrett
wrote:

>
> Sweet! Well done Jorge / David for getting this out so quickly with
> the announcement of 2.7.4
> >
>

--~--~-~--~~~---~--~~
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: directives versus snippets

[Jorge Ortiz]

Huh?

lift: snippet, surround, embed, ignore, comet, children, a, form, loc, and
with-param are all built-in in liftTagProcessing. Yes, they're overrideable,
but imo it'd be nicer if they were Just A Snippet, like, say, lift:msgs.

lift:bind is just bad naming. it's not actually a directive, it's just what
lift:surround looks for to bind at. should probably be called surround:bind
or something with a different namespace.

--j

On Fri, Apr 10, 2009 at 1:26 PM, David Pollak  wrote:

> Bob,
> They are actually the same thing.  Lift's processing directives are simply
> built-in snippets.  You can, if you dare, override their functionality. :-)
>
> Thanks,
>
> David
>
> On Fri, Apr 10, 2009 at 11:23 AM, bob  wrote:
>
>>
>> if I see , it could mean one of two things: a directive,
>> e.g.,  or  or shorthand for a snippet, eg
>>  represents 
>>
>> i guess I would like to see these disambiguated a shorthand for
>> snippets that doesn't overlap with the directive namespace.
>>
>> some possible solutions:
>>
>> 1.  would be the directive and  would be the
>> snippet. please don't get hung up on my use of dot. it is only an
>> example, and not an actual suggestion.
>>
>> 2.  maps to a real class, not some internal code, much the
>> way  maps to net.liftweb.builtin.snippets.Msgs  (thanks
>> Jorge)
>>
>> 3.  is the directive, and  is the snippet
>>
>> comments?
>>
>> thanks, bob
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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] Google App Engine

[Jorge Ortiz]

Google App Engine just released support for Java/Scala. I just sent in
my laptop for repairs and won't get it back for a while.

Anyone want to try Lift on GAE and report back?

--j

--~--~-~--~~~---~--~~
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: Advice on Ramping Up

[Jorge Ortiz]

Aside: I think the preferred abbreviation for Programming in Scala is PinS,
not PiS.

Just fyi,

--j

On Fri, Apr 3, 2009 at 4:15 PM, Timothy Perrett wrote:

>
>
> My advice, if your generally / vaugly familiar with Scala from reading PiS
> (that truly is a very unfortunate acronym!) just dive into making a lift
> app, then go from there.
>
> One of the best things about Lift is the community - if you have questions,
> chances are its either already in the group archive from one of our many
> debates, or in the lift book, or if not, just ask on the mailing list and
> someone will no doubt help you right quick!
>
> Good luck!
>
> Tim
>
>
> On 03/04/2009 23:01, "Charles F. Munat"  wrote:
>
> >
> > I'd suggest that you start working in Lift, then when you encounter
> > something that doesn't make sense to you, refer to the PiS book
> > (unfortunate acronym). It helps if you have the PDF version because you
> > can search. The index is OK, but often insufficient.
> >
> > This is the approach I used to get started, though eventually I went
> > back and read most of the book sequentially (I still have a couple of
> > chapters to go). Take a look also at DPP's book and the online Lift
> > book, both easily searchable.
> >
> > If you want to jump ahead in the book, I'd recommend the following:
> >
> > 15: Case Classes and Pattern Matching
> > 16: Working with Lists
> > 23: For Expressions Revisited
> >
> > Lists, for expressions, case classes, and pattern matching are used *all
> > over the place* in Lift. You can't be too familiar with these.
> >
> > Then maybe:
> >
> > 19: Type Parameterization
> > 21: Implicit Conversions and Parameters
> >
> > You don't need to understand those thoroughly, but having some
> > familiarity with them will help with debugging and understanding what
> > the heck is going on.
> >
> > If you have time, you could also read the following to fill in a few
> gaps:
> >
> > 22: Implementing Lists
> > 26: Working with XML
> >
> > And if you're going to use Comet, you should probably read:
> >
> > 30: Actors and Concurrency
> >
> > But again, you can dive in and then reference these chapters as
> necessary.
> >
> > Chas.
> >
> > lmorroni wrote:
> >> Hi,
> >> I am a Java programmer that is interested in learning Lift.  I have
> >> just finished the first six chapters of Programming in Scala.  I
> >> wonder what people's opinions are on how much of this book I need to
> >> read before diving into Lift.  I attempted to dive into Lift without
> >> reading anything on Scala and that worked great until I wanted to
> >> start reviewing the Lift libraries :)
> >> Maybe there are some chapters in this book that I can skip?  I think
> >> the book is really well written and I have followed everything so
> >> far.  I just would rather get rolling on Lift sooner rather than
> >> later.
> >> Larry
> >>
> >>>
> >
> > >
> >
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Newbie Scala syntax question re: parameterized types with bounds

[Jorge Ortiz]

On Fri, Apr 3, 2009 at 12:53 PM, David Pollak  wrote:

>
>
> On Wed, Apr 1, 2009 at 8:06 PM, Kris Nuttycombe  > wrote:
>
>>
>> Something that occurred to me recently along these lines - perhaps
>> someone can disabuse me of this notion. In Java, such recursive types
>> are necessary because you don't have abstract types. To refer to the
>> implementation type in the declaring class you have to use the
>> self-type.
>>
>> But in Scala, what application would not be satisfied by:
>>
>> trait Mapper {
>>   type T <: Mapper
>> }
>>
>> class User extends Mapper {
>>   type T = User
>> }
>>
>> Is it just that the restriction on T is not sufficiently narrow?
>
>
> No... becayse you can say:
>
> class User extends Mapper {
>   type T = Address
> }
>
> I think this captures things, but I'm not 100% sure (and self-types weren't
> around when I did Mapper):
>
> trait Mapper[T <: Mapper] {
>   self: T =>
> }
>

This can be expressed as:

  trait Mapper {
type T >: this.type <: Mapper
  }

  class User extends Mapper {
type T = User
  }

Actually, this might be sufficient:

  trait Mapper {
type T = this.type
  }

  class User extends Mapper

Actually, that's too specific, because then:

  object MetaUser extends User {
def create: T = new User // oops, MetaUser.T == MetaUser.type != User
  }

But I think the first suggestion still works:

  trait Mapper {
type T >: this.type <: Mapper
  }

  class User extends Mapper {
type T = User
  }

  object MetaUser extends User {
def create: T = new User
  }

W, types are fun...

It might be a good idea to user these for Mapper* stuff, but Mapped* stuff
would maybe get too verbose with type T = ... syntax versus [T] syntax.

--j


>>
>> Kris
>>
>> On Fri, Mar 27, 2009 at 5:26 PM, Alex Boisvert 
>> wrote:
>> > Or said another way,
>> >
>> > MappedTextarea[ T <: Mapper[T] ]
>> >
>> > declares a type parameter T and fixes the upper bound of the
>> MappedTextarea
>> > type parameter to Mapper[T], which means that the type passed to
>> > MappedTextArea must be a subtype of Mapper.
>> >
>> > I, too, found this notation confusing at first and wished I could write
>> > MappedTextarea[ <: Mapper[T] ] directly but declaring the T before its
>> use
>> > is necessary to disambiguate it from existing class names.
>> >
>> > alex
>> >
>> >
>> >
>> > On Fri, Mar 27, 2009 at 1:52 PM, Stefan Scott <
>> stefanscottal...@gmail.com>
>> > wrote:
>> >>
>> >> Hi -
>> >>
>> >> Sorry to be asking a Scala syntax question here in the Lift group, but
>> >> I figured somebody here would know, since this Scala syntax occurs
>> >> quite a bit in the Lift source code.
>> >>
>> >> When reading some of the Lift source I come across a particular Scala
>> >> "idiom" involving parameterized types with bounds, whose semantics I'm
>> >> unsure of.
>> >>
>> >> For example:
>> >>
>> >> class MappedTextarea[ T <: Mapper[ T ] ] ( owner : T, maxLen: Int )
>> >> extends
>> >>  MappedString[ T ]( owner, maxLen ) { ... }
>> >>
>> >> What I'm unsure about here is the part where it says:
>> >>
>> >> T <: Mapper[ T ]
>> >>
>> >> At first, this made no sense to me - how could a type T be a subtype
>> >> of type Mapper[ T ] ?
>> >>
>> >> Then I guessed that maybe the two occurrences of T are unrelated to
>> >> each other - ie, class MappedTextarea is parameterized over a type T,
>> >> which must be a subtype of a type Mapper[ T ] -- where the second T is
>> >> actually in a separate scope so that it has nothing to do with the
>> >> first T.
>> >>
>> >> Is that what this really means?
>> >>
>> >> And, if that's really the case, then I guess the other occurrences of
>> >> T later in the text:
>> >>
>> >> owner : T
>> >> MappedString[ T ]
>> >>
>> >> are also referring to the first occurrence of T -- the type T which is
>> >> upper-bounded by type Mapper[ T ].
>> >>
>> >> Finally, does this mean that the above code could also have been
>> >> written equivalently as follows:
>> >>
>> >> class MappedTextarea[ T <: Mapper[ U ] ] ( owner : T, maxLen: Int )
>> >> extends
>> >>  MappedString[ T ]( owner, maxLen ) { ... }
>> >>
>> >> using U instead of T for the type parameter that's in a separate
>> >> scope?
>> >>
>> >> Thanks for any help.
>> >>
>> >> - Stefan Scott
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: Proposed URL Shortening widget

[Jorge Ortiz]

What about easily turning any lift app into a url shortener service?

Wouldn't be too hard...

Granted, some services (bit.ly) add statistics, visualization, conversation
tracking, etc. which aren't just url shortening.

--j

On Thu, Apr 2, 2009 at 12:13 PM, Tim Perrett wrote:

>
> Guys,
>
> I've been contemplating doing this for a while and am now finding
> myself with a bunch of free time tomorrow and a need to write some
> code.
>
> So, I want to make a widget that shortens URL's in an extendable
> way... Im thinking of having something like:
>
> trait URLReductionProvider { ... }
>
> object TinyURL extends URLReductionProvider
> object IsGd extends URLReductionProvider
> object BitLy extends URLReductionProvider
>
> You get the general idea...
>
> So, im thinking of implementing the actual URL fetching stuff as a
> partial function so that users could do:
>
> def reductionResult = {
>  case Full(result) => // result is the URL, insert into database etc
>  case _ => // something went wrong
> }
>
> My question is however, if i make this actor based, could someone
> implement it so rather than writing there URL to database in a
> separate thread to the main one, would it be possible for them to say,
> use a JsCmd and return that to update the browser? Im guessing not
> unless it was a CometActor right.
>
> This then got me thinking, do you guys thing this is worth doing actor
> based, or is it just ok to make a blocking call to the provider?
> (tinyurl or is.gd etc)
>
> Cheers, Tim
> >
>

--~--~-~--~~~---~--~~
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: The Lift 1.1 list

[Jorge Ortiz]

I also propose we start thinking seriously about 2.8.

In particular, 2.8 will probably add support for named and default
arguments. This places extra burdens on library and framework designers, as
method -argument- names will be just as much a part of a library/framework's
API as class, method, and field names. It also means that decisions about
the order of arguments, whether arguments have a default, and whether
methods are overloaded need to be made or revisited.

For our 1.0 branch, this means cleaning up argument names before releasing a
2.8 version. Order of arguments should not be changed, nor should we remove
any overloaded method versions.

For our 1.1 branch, I propose we do a holistic review of API decisions with
regards to arguments, argument names, argument order, defaults, and
overloading.

--j

On Wed, Apr 1, 2009 at 9:11 AM, David Pollak
wrote:

> Folks,
>
> I think we've got our Lift 1.1 list.  If anyone has anything to add, please
> speak up now.
>
>- Improved documentation: better VScalaDoc coverage as well as better
>tutorial and cook-book documentation.
>- Improved J2EE support including JTA and Portlets.
>- Finish Record/Field code with backing store including JDBC, JPA and
>Goat Rodeo (what's Goat Rodeo? http://goatrodeo.org)
>- Improved client-side JavaScript support and better JavaScript
>abstractions.
>- Client/Server data synchronization (integrated with Record/Field)
>- Improved support for REST.
>- Improved performance including caching templates when running in
>production mode.
>- OSGi support.
>- Improved testing framework and better testing support when running in
>"test" mode.
>- Implement Servlet 3.0 support.
>- HTML 5 and Web Sockets support and integration with Kaazing's Web
>Sockets server.  Also, sensing which browser is making the request and
>performing optimizations based on that browser's characteristics
>(specifically, Chrome and Firefox 3.1 support)
>
> We will have bug-fix releases of 1.0 along the way and we'll have a release
> off the 1.0 branch when Scala 2.8 is released.
>
> Feedback is welcome in the next 3 days.
>
> 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
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: The Lift 1.1 list

[Jorge Ortiz]

I propose we migrate to Joda Time for 1.1.

In particular, I propose that Record ditch Java Date/Time entirely in favor
of Joda Time. Since migrating from Mapper to Record will involve a port
anyway, what's one more breaking change among friends?

Lift's other uses of Date/Time should be deprecated in favor of Joda Time
alternatives.

Mapper should continue to support Date/Time.

--j

On Wed, Apr 1, 2009 at 9:11 AM, David Pollak
wrote:

> Folks,
>
> I think we've got our Lift 1.1 list.  If anyone has anything to add, please
> speak up now.
>
>- Improved documentation: better VScalaDoc coverage as well as better
>tutorial and cook-book documentation.
>- Improved J2EE support including JTA and Portlets.
>- Finish Record/Field code with backing store including JDBC, JPA and
>Goat Rodeo (what's Goat Rodeo? http://goatrodeo.org)
>- Improved client-side JavaScript support and better JavaScript
>abstractions.
>- Client/Server data synchronization (integrated with Record/Field)
>- Improved support for REST.
>- Improved performance including caching templates when running in
>production mode.
>- OSGi support.
>- Improved testing framework and better testing support when running in
>"test" mode.
>- Implement Servlet 3.0 support.
>- HTML 5 and Web Sockets support and integration with Kaazing's Web
>Sockets server.  Also, sensing which browser is making the request and
>performing optimizations based on that browser's characteristics
>(specifically, Chrome and Firefox 3.1 support)
>
> We will have bug-fix releases of 1.0 along the way and we'll have a release
> off the 1.0 branch when Scala 2.8 is released.
>
> Feedback is welcome in the next 3 days.
>
> 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
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: MappedDateTime - Do we have a Date? Or is it a timestamp?

[Jorge Ortiz]

I was on IRC trying to help Clemens with this. The name (MappedDateTime),
targetSQLType (java.sql.Types.TIMESTAMP), and type (extends
MappedField[java.util.Date, _]) of this class suggests millisecond precision
(java.sql.Timestamp and java.util.Date have millisecond precision). However,
methods jdbcFriendly and real_convertToJDBCFriendly use java.sql.Date, which
has only day precision.

If the intent is day precision, then calling the class DateTime is probably
misleading. If the intent is millisecond precision, then we have a bug.



Which brings up the larger issue of the brokennes of the Java Date/Time API.
Java 7 will hopefully be getting a newer/better one, but for those of us
stuck on Java 5/6, Joda Time is much preferable to the native Date/Time API.
It more clearly represents foundational concepts like instants (March 31,
2009 at 12:15.000pm UTC), partials (March 3 or 7:15pm), intervals (the space
between two instants), durations (1000 milliseconds), periods (1 month), and
chronologies (calendar systems). It's also completely immutable (oh, you
didn't know java.util.Calendar isn't thread-safe? you're lucky to have never
had to track down that bug).



Sigh... it's probably too big of a breaking change to rip out Java Date/Time
from Mapper and Helpers and replace it with Joda Time, but one can dream...

--j

On Tue, Mar 31, 2009 at 11:58 AM, Clemens Oertel
wrote:

>
> While trying to figure out why my MappedDateTime fields get stored in
> the DB with all the time info set to 0, I noticed the following:
>
> MappedDateTime (v. 1.0) "claims" to be a TimeStamp: def targetSQLType
> = Types.TIMESTAMP. However, it uses java.sql.Date for its JDBC-
> friendly converted version, not java.sql.TimeStamp. If I read the
> java.sql.Date documentation correctly, java.sql.Date does set all time
> information to 0, since the SQL DATE type only stores dates, by no
> times.
>
> Any comment whether this might have something to do with me losing my
> time would be appreciated.
>
> Best,
> Clemens
>
> >
>

--~--~-~--~~~---~--~~
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: Lift Web, why no download of a zipped archive on the website?

[Jorge Ortiz]

If you want the sources, GitHub makes them available here:

http://github.com/dpp/liftweb/downloads

If you want the binaries...

We'll, you'll want to use Maven anyway. Just get that, really.

--j

On Thu, Mar 19, 2009 at 1:34 PM, BerlinBrown  wrote:

>
> http://liftweb.net/download.html
>
> Call me old fashion, but why can't there simply be a download on the
> download page?
> >
>

--~--~-~--~~~---~--~~
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: Decoupling Lifts Template System

[Jorge Ortiz]

I hadn't thought about localization. That makes things a bit trickier.

Part of my goal was to make methods that allow you to easily access template
functionality programmatically. For example:

  def lift_surround(template: Box[String], at: Box[String])(child: NodeSeq):
NodeSeq
  def lift_snippet(stype: String)(child: NodeSeq): NodeSeq
  def lift_embed(what: String): NodeSeq
  def lift_comet(ctype: String, name: String)(child: NodeSeq): NodeSeq

Another goal was to be able to use templates without the rest of Lift. I
really just wanted the XML munging (templates, snippets, etc). Didn't think
too much about localization, views, etc.

In a lot of ways all this stuff is either a NodeSeq or a NodeSeq => NodeSeq.
I feel like there's some nice abstraction that would make everything pretty
but somehow I'm missing it...

My lowest priority would be to make template systems pluggable (i.e., use
some other template system with Lift). I have no desire to use this
personally, but part of the work involved for the first two goals means
extricating Lift's templates from the core of Lift. Making the template
system pluggable might just fall out of that.

--j

On Thu, Mar 19, 2009 at 3:39 PM, TylerWeir  wrote:

>
> I thought Jorge was talking about this.  Maybe he'll jump in.
>
> On Mar 19, 3:58 pm, David Pollak 
> wrote:
> > It would be very tough because the templating system is all about the
> > current state which is all about S and LiftRules.
> >
> > On Mar 19, 2009 12:41 PM, "Tim Perrett"  wrote:
> >
> > Guys,
> >
> > What would it take to decouple Lifts template system? Specifically, im
> > interested in reusing a bunch of the localization and view
> > componentry.
> >
> > I know that wa back there was talk of doing this. For instance,
> > lets say that you wanted filesystem view storage, rather than views
> > being held in the WAR... right now, you have to rebuild the wheel to
> > keep the lift functionality (like selecting templates based on locale
> > ISO code) as lift currently only looks for resources based on the
> > context root.
> >
> > Anyway... what are people's thoughts? I appreciate this is a fairly
> > big task, but anyone want to bang it out for 1.1?
> >
> > Cheers, Tim
> >
>

--~--~-~--~~~---~--~~
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: FieldType and ForeignType

[Jorge Ortiz]

Argh. Good call. I don't know as I was debugging through IRC, but it was
probably 2.7.2 since he was using the todo example site from the Lift
workshop.

And I told him to upgrade to Lift 1.0. That's going to cause problems. Oh
well.

--j

On Tue, Mar 17, 2009 at 8:23 PM, David Pollak  wrote:

> What version of Scala?
>
>
> On Tue, Mar 17, 2009 at 5:45 PM, Jorge Ortiz wrote:
>
>> And if they're useful, can subclasses of MappedForeignKey define them more
>> exactly?
>>
>> Errors looked like this:
>>
>> [WARNING] 
>> C:\workspace\liftapp\src\main\scala\com\liftworkshop\model\ToDo.scala:
>>
>> 16: error: object creation impossible, since type ForeignType in trait 
>> MappedFor
>> eignKey with bounds >: Nothing <: 
>> net.liftweb.mapper.KeyedMapper[Long,my.liftapp
>> .model.User] is not defined
>> [WARNING]   object owner extends MappedLongForeignKey( this , User )
>>
>>
>> [WARNING]  ^
>>
>>
>> [WARNING] 
>> C:\workspace\liftapp\src\main\scala\com\liftworkshop\model\ToDo.scala:
>> 16: error: object creation impossible, since type FieldType in trait 
>> MappedForei
>>
>> gnKey with bounds >: Nothing <: Long is not defined
>> [WARNING]   object owner extends MappedLongForeignKey( this , User )
>> [WARNING]  ^
>>
>>
>> --j
>>
>>
>> On Tue, Mar 17, 2009 at 5:42 PM, Jorge Ortiz wrote:
>>
>>> Anyone know what these two types:
>>>
>>>   type FieldType <: KeyType
>>>   type ForeignType <: KeyedMapper[KeyType, Other]
>>>
>>> in trait MappedForeignKey are doing?
>>>
>>> They're never fully defined and never used, but somehow were causing
>>> compile problems in someone's code.
>>>
>>> If they're useless, can they be axed?
>>>
>>> --j
>>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: FieldType and ForeignType

[Jorge Ortiz]

And if they're useful, can subclasses of MappedForeignKey define them more
exactly?

Errors looked like this:

[WARNING] C:\workspace\liftapp\src\main\scala\com\liftworkshop\model\ToDo.scala:
16: error: object creation impossible, since type ForeignType in trait MappedFor
eignKey with bounds >: Nothing <: net.liftweb.mapper.KeyedMapper[Long,my.liftapp
.model.User] is not defined
[WARNING]   object owner extends MappedLongForeignKey( this , User )
[WARNING]  ^


[WARNING] C:\workspace\liftapp\src\main\scala\com\liftworkshop\model\ToDo.scala:
16: error: object creation impossible, since type FieldType in trait MappedForei
gnKey with bounds >: Nothing <: Long is not defined
[WARNING]   object owner extends MappedLongForeignKey( this , User )
[WARNING]  ^


--j

On Tue, Mar 17, 2009 at 5:42 PM, Jorge Ortiz  wrote:

> Anyone know what these two types:
>
>   type FieldType <: KeyType
>   type ForeignType <: KeyedMapper[KeyType, Other]
>
> in trait MappedForeignKey are doing?
>
> They're never fully defined and never used, but somehow were causing
> compile problems in someone's code.
>
> If they're useless, can they be axed?
>
> --j
>

--~--~-~--~~~---~--~~
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] FieldType and ForeignType

[Jorge Ortiz]

Anyone know what these two types:

  type FieldType <: KeyType
  type ForeignType <: KeyedMapper[KeyType, Other]

in trait MappedForeignKey are doing?

They're never fully defined and never used, but somehow were causing compile
problems in someone's code.

If they're useless, can they be axed?

--j

--~--~-~--~~~---~--~~
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: Custom Boot Class

[Jorge Ortiz]

Thanks Derek!

--j

On Mon, Mar 16, 2009 at 8:33 AM, Derek Chen-Becker wrote:

> Just confirmed. Changing you web.xml to:
>
> 
>
>  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd";>
>
> 
>
> 
>   LiftFilter
>   Lift Filter
>   The Filter that intercepts lift calls
>   net.liftweb.http.LiftFilter
>   
> bootloader
> bootstrap.liftweb.Brat
>   
> 
>
>
> 
>   LiftFilter
>   /*
> 
>
> 
>
> Fixes it. I'll fix the book.
>
> Derek
>
>
> On Mon, Mar 16, 2009 at 9:19 AM, Derek Chen-Becker 
> wrote:
>
>> I think we might have an error in the book. The example you give uses
>> context-param, but I think it needs to be an init-param within the filter
>> portion of the web.xml.
>>
>> Derek
>>
>>
>> On Mon, Mar 16, 2009 at 9:04 AM, Viktor Klang wrote:
>>
>>> No, it was working when we switched to the filter. :/
>>>
>>>
>>> On Mon, Mar 16, 2009 at 2:58 PM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
>>>> I wonder if this is something that broke when we moved to a Filter...
>>>>
>>>> Derek
>>>>
>>>>
>>>> On Mon, Mar 16, 2009 at 7:02 AM, Jorge Ortiz wrote:
>>>>
>>>>> I get the same error, unfortunately.
>>>>>
>>>>> --j
>>>>>
>>>>>
>>>>> On Mon, Mar 16, 2009 at 4:48 AM, Sergey Andreev 
>>>>> wrote:
>>>>>
>>>>>> Jorge,
>>>>>>
>>>>>> I am using a custom Boot class and it works just fine. I believe that
>>>>>> if you create a Brat.scala and put your class there, it will solve the
>>>>>> problem
>>>>>>
>>>>>> Regards,
>>>>>> Sergey
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 16, 2009 at 1:31 PM, Jorge Ortiz 
>>>>>> wrote:
>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> I'm trying to specify a custom Boot class, as per Chapter 3 of the
>>>>>>> Lift Book. To my web.xml I've added:
>>>>>>>
>>>>>>>   
>>>>>>> bootloader
>>>>>>> bootstrap.liftweb.Brat
>>>>>>>   
>>>>>>>
>>>>>>> and in Boot.scala I've commented out the regular Boot class and added
>>>>>>> a Brat class with identical implementation, except it extends Bootable.
>>>>>>>
>>>>>>>   class Brat extends Bootable { ... }
>>>>>>>
>>>>>>> Unfortunately, I'm getting a:
>>>>>>>
>>>>>>>   ERROR - Failed to Boot
>>>>>>>   java.lang.ClassNotFoundException: bootstrap.liftweb.Boot
>>>>>>>
>>>>>>> Attached is the zipped project.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --j
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>> Senior Systems Analyst
>>>
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Custom Boot Class

[Jorge Ortiz]

I get the same error, unfortunately.

--j

On Mon, Mar 16, 2009 at 4:48 AM, Sergey Andreev  wrote:

> Jorge,
>
> I am using a custom Boot class and it works just fine. I believe that if
> you create a Brat.scala and put your class there, it will solve the problem
>
> Regards,
> Sergey
>
>
> On Mon, Mar 16, 2009 at 1:31 PM, Jorge Ortiz wrote:
>
>> Folks,
>>
>> I'm trying to specify a custom Boot class, as per Chapter 3 of the Lift
>> Book. To my web.xml I've added:
>>
>>   
>> bootloader
>> bootstrap.liftweb.Brat
>>   
>>
>> and in Boot.scala I've commented out the regular Boot class and added a
>> Brat class with identical implementation, except it extends Bootable.
>>
>>   class Brat extends Bootable { ... }
>>
>> Unfortunately, I'm getting a:
>>
>>   ERROR - Failed to Boot
>>   java.lang.ClassNotFoundException: bootstrap.liftweb.Boot
>>
>> Attached is the zipped project.
>>
>> Thanks,
>>
>> --j
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Why does HelloWorld index.html contain a snippet rather than a complete XHTML page?

[Jorge Ortiz]

Yes, if index.xhtml is a compliant XML (preferably XHTML) document, it will
just be served up as-is. The  tags define transformations that
are applied to your document before it is served up.

--j

On Fri, Mar 13, 2009 at 3:40 PM, Marc Boschma

> wrote:

>
> Hi Mal,
>
> That aspect of the lift templating approach also warped my head for a
> while, having seen so many examples of the opposite approach (PHP,
> JSP, etc)...
>
> There is a certain part of me that still is unsettled about it, but I
> can see the advantages of it.
>
> Marc
> Ps. can the files such as index.html in the examples be full XML
> compliant documents?
>
> On 13/03/2009, at 3:30 PM, mal3 wrote:
>
> >
> > Why does HelloWorld index.html contain a snippet rather than a
> > complete XHTML page?
> >
> > When I first saw the HelloWorld example I thought there must be a
> > mistake,
> > because the index.html file contains a snippet, while default.html
> > contains
> > what looked more like a complete XHTML page.
> >
> > Why doesn't lift initially reference a complete XHTML page and then
> > pull in the snippet(s)?
> >
> > Is it to make it difficult/impossible for logic to creep into the
> > view?
> >
> > Mal.
> >
> > >
>
>
> >
>

--~--~-~--~~~---~--~~
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: Proposed localization change to S

[Jorge Ortiz]

Nulls are really bad form in idiomatic Scala. If nulls are just treated as
the empty string, why can't the user just pass in the empty string ""? It's
less typing, and it's more clear how it'll be handled.

--j

On Fri, Mar 6, 2009 at 11:41 PM, Derek Chen-Becker wrote:

> I think that adding an overload for loc(String,String) that maps to
> loc(String,NodeSeq) with null testing provides simplicity for the user (not
> having to explicitly wrap everything in Text() unless you have specific need
> for it). At the risk of making this a little more complex but adding some
> flexibility, how about
>
> def loc(key : String, default : => String) =
> loc(str).openOr(Text(Box.!!(default).openOr("")))
>
> I'm not sure what we really want to return if the provided default is null.
> I was also wondering if we want to Log a failed lookup key so that you could
> easily determine that you missed some l10n properties. That could look like:
>
> def loc(key : String, default : => String) = loc(str).openOr({
>   Log.warn({() => "Failed lookup of " + key + " for locale " + S.locale})
>   Text(Box.!!(default).openOr(""))
> }
>
> Cheers,
>
> Derek
>
>
> On Fri, Mar 6, 2009 at 4:57 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 6, 2009 at 3:52 PM, Timothy Perrett 
>> wrote:
>>
>>> Isn't the danger here that Text() will explode if for some reason default
>>> was null (e.g Reading from a DB)?
>>>
>>> It's not a massive issue, as people should be diligent about supplying
>>> defaults but it's just a though.
>>>
>>
>> You can always add null testing.
>> - Show quoted text -
>>
>>
>>>
>>> Cheers, Tim
>>>
>>> Sent from my iPhone
>>>
>>> On 6 Mar 2009, at 18:32, Derek Chen-Becker 
>>> wrote:
>>>
>>> It would be a little cleaner if there was a helper overload:
>>>
>>> def loc (key : String, default : String) = loc(key, Text(default))
>>>
>>> Derek
>>>
>>> On Fri, Mar 6, 2009 at 12:16 PM, Timothy Perrett <
>>> timo...@getintheloop.eu> wrote:
>>>

 I've just been looking at some of the other method overloads in S and
 it appears we already have:

 S.loc(String, NodeSeq)

 This is exactly what I need anyway - wondering if there is any need to
 override S.? with another method now?

 Cheers, Tim

 On Mar 6, 5:03 pm, Timothy Perrett  wrote:
 > Sounds cool - I'll make the change and commit it.
 >
 > Cheers, Tim
 >
 > On 06/03/2009 16:56, "marius d."  wrote:
 >
 >
 >
 > > +1 for overloading '? '
 >
 > > On Mar 6, 4:52 pm, Derek Chen-Becker  wrote:
 > >> I think this is a reasonable addition, but I would use
 >
 > >> def ?(key : String, defaultKey : String) = ...
 >
 > >> That way changing the default text just doesn't require changes to
 code.
 >
 > >> Derek
 >
 > >> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett
  wrote:
 >
 > >>> Guys,
 >
 > >>> I have a situation where I want to localize a bunch of dynamic
 texts,
 > >>> however the current behavior of S.? is to return the input text if
 its
 > >>> found in a resource bundle. Whilst I see the rational for this, I
 have
 > >>> another situation where I want to pass a key, and if it doesn't
 find
 > >>> it, display something else (the english version). Id rather not
 use
 > >>> the english text as the translation key, as if the english text
 > >>> changes, my database translations will break (not good!)
 >
 > >>> I can achieve the functionality needed right by doing something
 like:
 >
 > >>>S.loc(item.localization_key.toString + ".name") match {
 > >>>  case Full(t) => t
 > >>>  case _ => Text(doc.name.toString)
 > >>>}
 >
 > >>> But it would be nice if we could have a utility method in S which
 > >>> allowed you do do:
 >
 > >>> ?("my.localization.key", defaultText.toString)
 >
 > >>> Thoughts?
 >
 > >>> Cheers, Tim


>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>> - Show quoted text -
>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to 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: Record and JSON

[Jorge Ortiz]

And I forgot the link:

http://paste.pocoo.org/show/106757/

--j

On Fri, Mar 6, 2009 at 12:11 PM, Jorge Ortiz  wrote:

> Hey Folks,
>
> I wrote a Json AST and parser/serializer for unrelated reasons yesterday.
> This could be the basis of a Record <--> Json tool.
>
> --j
>
>
> On Wed, Mar 4, 2009 at 9:11 AM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Wed, Mar 4, 2009 at 9:08 AM, Marius  wrote:
>>
>>>
>>> Hi,
>>>
>>> I was thinking that it might be useful to be able to obtain a JSON
>>> representation of a Record and also from a JSON construct to create a
>>> Record.
>>>
>>> Record defines now:
>>>
>>> def suplementalJs(ob: Box[KeyObfuscator]): List[(String, JsExp)] = Nil
>>>
>>> but that's not very intuitive ... not to mention not implemented yet.
>>>
>>> Thoughts ?
>>
>>
>> I've been needing bi-directional JSON support to allow for the creation of
>> complex JSON data structures.
>>
>> So, my thought is I have a need, but not a solution. :-)
>>
>>
>>>
>>>
>>> Br's,
>>> Marius
>>>
>>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Record and JSON

[Jorge Ortiz]

Hey Folks,

I wrote a Json AST and parser/serializer for unrelated reasons yesterday.
This could be the basis of a Record <--> Json tool.

--j

On Wed, Mar 4, 2009 at 9:11 AM, David Pollak
wrote:

>
>
> On Wed, Mar 4, 2009 at 9:08 AM, Marius  wrote:
>
>>
>> Hi,
>>
>> I was thinking that it might be useful to be able to obtain a JSON
>> representation of a Record and also from a JSON construct to create a
>> Record.
>>
>> Record defines now:
>>
>> def suplementalJs(ob: Box[KeyObfuscator]): List[(String, JsExp)] = Nil
>>
>> but that's not very intuitive ... not to mention not implemented yet.
>>
>> Thoughts ?
>
>
> I've been needing bi-directional JSON support to allow for the creation of
> complex JSON data structures.
>
> So, my thought is I have a need, but not a solution. :-)
>
>
>>
>>
>> Br's,
>> Marius
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
>
> >
>

--~--~-~--~~~---~--~~
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: Incomplete Site: Missing JavaDoc

[Jorge Ortiz]

The ScalaDocs are there. They're just hard to find. And they're split up by
module.

For example:
http://scala-tools.org/mvnsites/liftweb/lift-util/scaladocs/index.html
http://scala-tools.org/mvnsites/liftweb/lift-webkit/scaladocs/index.html
http://scala-tools.org/mvnsites/liftweb/lift-mapper/scaladocs/index.html
etc

Yes, this is sub-optimal. Yes, it's being worked on.

Cheers,

--j

On Tue, Mar 3, 2009 at 10:15 PM, Paul Stickney  wrote:

>
> I don't mean to be incredibly picky, but the LiftWeb site is /NOT/
> doing any justice to the LiftWeb framework.
>
> At the very least I would expect working online JavaDoc.
> (http://scala-tools.org/mvnsites/liftweb/ right now appears to be much
> nothing)
>
> Even throwing an older/"less pretty" javadoc (I know I've seen this
> somewhere before) back up would be a better solution than this limbo
> that makes LiftWeb appear unloved :(
>
> >
>

--~--~-~--~~~---~--~~
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: Tracking the latest with maven.. but not too quickly

[Jorge Ortiz]

You can run Maven in offline mode with the -o flag. That should stop it from
fetching anything.

--j

On Tue, Mar 3, 2009 at 5:34 PM, Lee Mighdoll  wrote:

> I've a local copy of the lift sources that I'd like to build and debug my
> app against.  So I currently reference the 1.1-SNAPSHOT artifact in my
> application's pom.xml.
>
> But maven seems to pull stuff down from the net more often than I'd like.
> I'd like my snapshot not to change until I git pull the latest lift version
> manually.  What's the best way to do this?
>
> I was thinking perhaps one way would be to locally modify the version in
> all the lift pom.xml files to 1.1-SNAPSHOT.local.  Or maybe there's some
> configuration option?  Or perhaps I should setup a local maven repository?
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Issue with http://liftweb.net site design (IE7 / Opera 9.63)

[Jorge Ortiz]

Done.

--j

On Sat, Feb 28, 2009 at 3:15 AM, Tim Perrett wrote:

>
> Guys,
>
> I've just committed the CSS patches for liftweb.net - I've also
> updated some of the content.
>
> Can someone get that onto the live box please?
>
> I've checked it in Opera, FF, Safari and IE7
>
> Thanks
>
> Tim
> >
>

--~--~-~--~~~---~--~~
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: ORM Framework

[Jorge Ortiz]

I've used Mapper on desktop apps that don't do http. You lose a lot of the
features but it's still usable and sometimes even convenient.

YMMV,

--j

On Sun, Feb 22, 2009 at 4:23 PM, David Pollak  wrote:

>
>
> On Sun, Feb 22, 2009 at 3:45 PM, Paulo Cheque wrote:
>
>>
>> Thanks by the fast answer David, and congratulations by the good work!
>>
>> I think this relationship is very strange (domain + http), is there
>> any idea to change this in the future?
>
>
> Lift's Mapper stuff relies of classes in the HTTP framework for access
> control, form generation, etc.  It would significantly detract from the
> Mapper classes to remove this kind of functionality.  Plus, Lift's OR Mapper
> stuff is nice for simple projects (like ActiveRecord), it's not meant to
> replace the functionality of a JPA solution (caching, etc.)
>
> So, no, there's no plan to remove the dependency between mapper and webkit.
>
>
>>
>>
>> Thanks in advance again
>> []s
>> Paulo
>>
>>
>>
>> On Sun, Feb 22, 2009 at 8:24 PM, David Pollak
>>  wrote:
>> > Paulo,
>> > Lift's Mapper depends on the HTTP framework.  I would suggest using JPA
>> as a
>> > stand-alone alternative.
>> > Thanks,
>> > David
>> >
>> > On Sun, Feb 22, 2009 at 11:04 AM, Paulo Cheque 
>> > wrote:
>> >>
>> >> Like GORM in Grails, it is possible to use the ORM framework of Lift
>> >> separately?? There is any tutorial or documentation avaiable?
>> >>
>> >> Thanks in advance
>> >>
>> >> []s
>> >> Paulo
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Lift, the simply functional web framework http://liftweb.net
>> > Beginning Scala http://www.apress.com/book/view/1430219890
>> > Follow me: http://twitter.com/dpp
>> > Git some: http://github.com/dpp
>> >
>> > >
>> >
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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] UPDATED jQuery to 1.3.2 (eom)

[Jorge Ortiz]

--j

--~--~-~--~~~---~--~~
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: populate DB table upon creation

[Jorge Ortiz]

Your tables will be created during the call to Schemifier.schemify.

If you want to add data to the tables, your best bet is to do so in
Boot.scala after the call to schemify.

--j

On Fri, Feb 20, 2009 at 9:18 AM, DavidV  wrote:

>
> I wondering how to populate rows of a DB table upon it's creation.
> First, where in the lift code are tables created?  Is it in trait
> BaseMapper's dbAddTable method?  I have an Array[String] I would like
> to add to the table when it is being created.  Which method can I
> override to achieve this and how should I do so?
>
> Thanks!
> -David
>
> >
>

--~--~-~--~~~---~--~~
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 round of thanks to Marius for better GC

[Jorge Ortiz]

I still see some lift:when attributes in Lift output. Is this expected? (I
seem to remember them being around long before the gc code went in.)

--j

On Thu, Feb 19, 2009 at 6:29 PM, David Pollak  wrote:

> Folks,
> Marius made some patches to Lift's GC support today.  He removed the
> lift:gc tag so we don't trip over the Firefox namespace issue.
>
> I've done some initial testing (and made a few minor updates).
>
> Please do a mvn -U clean install and let us know how well the new code
> works.
>
> Please also do tests like navigating to a page with form elements on it,
> waiting 45 minutes and then making sure the form can be submitted.
>
> 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
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: Weird Mapper type error

[Jorge Ortiz]

Committed the fix to lift-archetype-basic (to set a good example)

--j

On Thu, Feb 19, 2009 at 9:10 AM, David Pollak  wrote:

>
>
> On Thu, Feb 19, 2009 at 6:49 AM, Derek Chen-Becker 
> wrote:
>
>> Shouldn't it be
>>
>> override def fieldOrder: List[BaseOwnedMappedField[Transaction]] = txtime
>> :: amount :: summary :: Nil
>>
>> I did try that and it gave the same error. In any case, List(...) works.
>
>
> This is because the :: (cons) operation does inference on each cons
> element, rather than the List as a whole.  At some point, it gets confused.
> Please use List().
>
>
>>
>>
>> Derek
>>
>>
>> On Thu, Feb 19, 2009 at 2:35 AM, Jorge Ortiz wrote:
>>
>>> Yup, this is a type inference bug. If I'm not mistaken then
>>>
>>> override def fieldOrder: BaseOwnedMappedField[Transaction] = txtime
>>> :: amount :: summary :: Nil
>>>
>>> should also work.
>>>
>>> In any case, I'd probably just stick with the List(...) syntax.
>>>
>>> --j
>>>
>>>
>>> On Wed, Feb 18, 2009 at 10:23 PM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
>>>> 0.11-SNAPSHOT, and I'm writing up some example code for the book. I have
>>>> the following class/object:
>>>>
>>>> class Transaction extends LongKeyedMapper[Transaction] with IdPK {
>>>>   def getSingleton = Transaction
>>>>
>>>>   object account extends MappedLongForeignKey(this, Account) {
>>>> override def dbIndexed_? = true
>>>>   }
>>>>
>>>>   object txtime extends MappedDateTime(this)
>>>>
>>>>   // The amount has up to 16 digits and 2 decimal places
>>>>   object amount extends MappedDecimal(this, MathContext.DECIMAL64, 2)
>>>>
>>>>   // Holds a brief description of the transaction
>>>>   object summary extends MappedString(this, 100)
>>>>
>>>>   object notes extends MappedTextarea(this, 1000) {
>>>> override def textareaCols = 60
>>>> override def textareaRows = 8
>>>>   }
>>>>
>>>>   def tags = TransactionTag.findAll(By(TransactionTag.transaction,
>>>> this.id))
>>>> }
>>>>
>>>> object Transaction extends Transaction with
>>>> LongKeyedMetaMapper[Transaction] {
>>>>   override def fieldOrder = txtime :: amount :: summary :: Nil
>>>> }
>>>>
>>>> The compile error I get is:
>>>>
>>>> [WARNING]
>>>> /home/software/pocketchangeapp/PocketChange/src/main/scala/com/pocketchangeapp/model/Transaction.scala:35:
>>>> error: inferred type arguments [net.liftweb.mapper.MappedField[_ >: _1 with
>>>> java.util.Date <: java.io.Serializable,
>>>> com.pocketchangeapp.model.Transaction]] do not conform to method ::'s type
>>>> parameter bounds [B >: net.liftweb.mapper.MappedField[_ >: String with
>>>> BigDecimal <: java.io.Serializable,
>>>> com.pocketchangeapp.model.Transaction]{def jdbcFriendly(String):
>>>> java.io.Serializable}]
>>>> [WARNING]   override def fieldOrder = txtime :: amount :: summary :: Nil
>>>> [WARNING]^
>>>> [WARNING] one error found
>>>>
>>>> If I remove the "summary" element from the fieldOrder list then it
>>>> compiles fine. Likewise, if I remove txtime and put summary and notes into
>>>> the list it compiles fine. I'm trying to get my head around all of the
>>>> nested type bounds in the error message but I'm not seeing anything obvious
>>>> other than the weird "String with BigDecimal" bound. I tried using an
>>>> explicit type for fieldOrder but that doesn't work either.
>>>>
>>>> I finally tried changing fieldOrder to:
>>>>
>>>> override def fieldOrder = List(txtime, amount, summary, notes)
>>>>
>>>> That compiles fine. Have I found a type inferencing bug, or have I just
>>>> done something incredibly stupid somewhere? Feel free to critique the 
>>>> class,
>>>> too.
>>>>
>>>> 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
> Git some: http://github.com/dpp
>
>
> >
>

--~--~-~--~~~---~--~~
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: Weird Mapper type error

[Jorge Ortiz]

Yup, this is a type inference bug. If I'm not mistaken then

override def fieldOrder: BaseOwnedMappedField[Transaction] = txtime ::
amount :: summary :: Nil

should also work.

In any case, I'd probably just stick with the List(...) syntax.

--j

On Wed, Feb 18, 2009 at 10:23 PM, Derek Chen-Becker
wrote:

> 0.11-SNAPSHOT, and I'm writing up some example code for the book. I have
> the following class/object:
>
> class Transaction extends LongKeyedMapper[Transaction] with IdPK {
>   def getSingleton = Transaction
>
>   object account extends MappedLongForeignKey(this, Account) {
> override def dbIndexed_? = true
>   }
>
>   object txtime extends MappedDateTime(this)
>
>   // The amount has up to 16 digits and 2 decimal places
>   object amount extends MappedDecimal(this, MathContext.DECIMAL64, 2)
>
>   // Holds a brief description of the transaction
>   object summary extends MappedString(this, 100)
>
>   object notes extends MappedTextarea(this, 1000) {
> override def textareaCols = 60
> override def textareaRows = 8
>   }
>
>   def tags = TransactionTag.findAll(By(TransactionTag.transaction, this.id
> ))
> }
>
> object Transaction extends Transaction with
> LongKeyedMetaMapper[Transaction] {
>   override def fieldOrder = txtime :: amount :: summary :: Nil
> }
>
> The compile error I get is:
>
> [WARNING]
> /home/software/pocketchangeapp/PocketChange/src/main/scala/com/pocketchangeapp/model/Transaction.scala:35:
> error: inferred type arguments [net.liftweb.mapper.MappedField[_ >: _1 with
> java.util.Date <: java.io.Serializable,
> com.pocketchangeapp.model.Transaction]] do not conform to method ::'s type
> parameter bounds [B >: net.liftweb.mapper.MappedField[_ >: String with
> BigDecimal <: java.io.Serializable,
> com.pocketchangeapp.model.Transaction]{def jdbcFriendly(String):
> java.io.Serializable}]
> [WARNING]   override def fieldOrder = txtime :: amount :: summary :: Nil
> [WARNING]^
> [WARNING] one error found
>
> If I remove the "summary" element from the fieldOrder list then it compiles
> fine. Likewise, if I remove txtime and put summary and notes into the list
> it compiles fine. I'm trying to get my head around all of the nested type
> bounds in the error message but I'm not seeing anything obvious other than
> the weird "String with BigDecimal" bound. I tried using an explicit type for
> fieldOrder but that doesn't work either.
>
> I finally tried changing fieldOrder to:
>
> override def fieldOrder = List(txtime, amount, summary, notes)
>
> That compiles fine. Have I found a type inferencing bug, or have I just
> done something incredibly stupid somewhere? Feel free to critique the class,
> too.
>
> 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: Truncate?

[Jorge Ortiz]

Yeah, a 1.1 branch seems like a good idea.

--j

On Wed, Feb 18, 2009 at 5:20 PM, Tim Perrett  wrote:

>
> Will do.
>
> Shall I create a 1.1 branch of lift so we can continue dev whilst the
> 1.0 feature freeze is on?
>
> Cheers, Tim
>
> On Feb 19, 12:50 am, David Pollak 
> wrote:
> > We don't have one.
> > Please write one up and add it to Helpers for 1.1.
> >
> > On Wed, Feb 18, 2009 at 4:46 PM, Tim Perrett 
> wrote:
> >
> > > Guys,
> >
> > > Just a quick one... looking for a similar method to:
> >
> > >http://api.rubyonrails.org/classes/ActionView/Helpers/TextHelper.html.
> ..
> >
> > > I know i could knock one up, but just wanted to check nothing like
> > > this exists already as it seems like a fairly util type task. I had a
> > > look but couldn't see anything in master.
> >
> > > Cheers, Tim
> >
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
> >
>

--~--~-~--~~~---~--~~
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: Fwd: [jquery-dev] Re: Namespace failure

[Jorge Ortiz]

This might be a bit of a pain to deal with, but something like:

  

Of course, you'd want to append to the 'class' attribute, not replace it
entirely.

--j

On Mon, Feb 16, 2009 at 1:49 PM, David Pollak  wrote:

> what would the raw XHTML look like?
> Also, we can't rely on jQuery to scrape because we have to support other
> libraries (e.g., YUI) without jQuery.
>
>
> On Mon, Feb 16, 2009 at 1:45 PM, Viktor Klang wrote:
>
>> How about adding a class-attribute called "gc" to everything that's
>> supposedly collectible?
>> Then doing a scrape using jQuery(".gc") would be just as feasible.
>>
>> Would it solve the problem or can it be extended to solve it fully?
>>
>>
>> On Mon, Feb 16, 2009 at 10:37 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Feb 16, 2009 at 1:36 PM, Jorge Ortiz wrote:
>>>
>>>> Can lift:gc be renamed lift_gc until the bug is addressed?
>>>
>>>
>>> lift_gc is not a valid attribute in XHTML as far as I know, so browsers
>>> would reject any element containing that attribute. :-(
>>>
>>>
>>>>
>>>>
>>>> On Mon, Feb 16, 2009 at 9:20 AM, David Pollak <
>>>> feeder.of.the.be...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Feb 16, 2009 at 9:04 AM, Tim Perrett wrote:
>>>>>
>>>>>>
>>>>>> What's the impact overall?
>>>>>
>>>>>
>>>>> The impact is: use innerHTML directly rather than going through
>>>>> jQuery's HTML re-writing.
>>>>>
>>>>>
>>>>>> Is this a result of upgrade to JQuery
>>>>>> 1.3.1?
>>>>>
>>>>>
>>>>> No.  This is a latent Firefox bug and has to do with how jQuery
>>>>> sanitizes HTML.  The problem existed in prior versions of jQuery, but is 
>>>>> now
>>>>> an issue because of the lift:gc stuff.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks, Tim
>>>>>>
>>>>>> On Feb 16, 4:51 pm, David Pollak 
>>>>>> wrote:
>>>>>> > Folks,
>>>>>> > It turns out that there are issues with jQuery's methods that
>>>>>> insert/replace
>>>>>> > HTML and using XHTML on Firefox.  Sigh.
>>>>>> >
>>>>>> > We should be aware of this.  using $("...").html(stuff) will likely
>>>>>> fail if
>>>>>> > any of the elements in stuff have namespaces.
>>>>>> >
>>>>>> > Sorry.
>>>>>> >
>>>>>> > David
>>>>>> >
>>>>>> > -- Forwarded message --
>>>>>> > From: John Resig 
>>>>>> > Date: Sun, Feb 15, 2009 at 8:31 PM
>>>>>> > Subject: [jquery-dev] Re: Namespace failure
>>>>>> > To: jquery-...@googlegroups.com
>>>>>> >
>>>>>> > Anko -
>>>>>> >
>>>>>> > You're welcome to file a bug on XHTML support - let me know when you
>>>>>> > do. I have it penciled in the Roadmap for jQuery 1.4 - but it's
>>>>>> going
>>>>>> > to require a lot of work (basic things like innerHTML aren't
>>>>>> > guaranteed to work, for example) - not to mention that things like
>>>>>> > attributes and expandos are handled very differently.
>>>>>> >
>>>>>> > I took some very basic steps of converting our test suite to run
>>>>>> under
>>>>>> > the proper mimetype and wasn't terribly pleased with the result
>>>>>> (lots
>>>>>> > of failures). I'll definitely revisit it at some point, though.
>>>>>> Right
>>>>>> > now the only component guaranteed I'm sure that passes is the
>>>>>> selector
>>>>>> > engine. I'd like to have 100% passing in all components for 1.4.
>>>>>> >
>>>>>> > http://dev.jquery.com/browser/trunk/jquery/test/xhtml.php
>>>>>> >
>>>>>>

[Lift] Re: Fwd: [jquery-dev] Re: Namespace failure

[Jorge Ortiz]

Can lift:gc be renamed lift_gc until the bug is addressed?

On Mon, Feb 16, 2009 at 9:20 AM, David Pollak  wrote:

>
>
> On Mon, Feb 16, 2009 at 9:04 AM, Tim Perrett  wrote:
>
>>
>> What's the impact overall?
>
>
> The impact is: use innerHTML directly rather than going through jQuery's
> HTML re-writing.
>
>
>> Is this a result of upgrade to JQuery
>> 1.3.1?
>
>
> No.  This is a latent Firefox bug and has to do with how jQuery sanitizes
> HTML.  The problem existed in prior versions of jQuery, but is now an issue
> because of the lift:gc stuff.
>
>
>>
>>
>> Thanks, Tim
>>
>> On Feb 16, 4:51 pm, David Pollak 
>> wrote:
>> > Folks,
>> > It turns out that there are issues with jQuery's methods that
>> insert/replace
>> > HTML and using XHTML on Firefox.  Sigh.
>> >
>> > We should be aware of this.  using $("...").html(stuff) will likely fail
>> if
>> > any of the elements in stuff have namespaces.
>> >
>> > Sorry.
>> >
>> > David
>> >
>> > -- Forwarded message --
>> > From: John Resig 
>> > Date: Sun, Feb 15, 2009 at 8:31 PM
>> > Subject: [jquery-dev] Re: Namespace failure
>> > To: jquery-...@googlegroups.com
>> >
>> > Anko -
>> >
>> > You're welcome to file a bug on XHTML support - let me know when you
>> > do. I have it penciled in the Roadmap for jQuery 1.4 - but it's going
>> > to require a lot of work (basic things like innerHTML aren't
>> > guaranteed to work, for example) - not to mention that things like
>> > attributes and expandos are handled very differently.
>> >
>> > I took some very basic steps of converting our test suite to run under
>> > the proper mimetype and wasn't terribly pleased with the result (lots
>> > of failures). I'll definitely revisit it at some point, though. Right
>> > now the only component guaranteed I'm sure that passes is the selector
>> > engine. I'd like to have 100% passing in all components for 1.4.
>> >
>> > http://dev.jquery.com/browser/trunk/jquery/test/xhtml.php
>> >
>> > --John
>> >
>> > On Sun, Feb 15, 2009 at 9:24 PM, Anko Painting 
>> wrote:
>> >
>> > > Is there a ticket associated with this bug? I'm dealing with the same
>> > > issue myself.
>> >
>> > > It's frustrating because i need to serve as application/xhtml+xml so
>> > > that I can put svg on the page.
>> >
>> > > On Feb 14, 12:52 am, John Resig  wrote:
>> > >> Correct - you have to do it with the mimetype - which forces it in to
>> > >> the XML mode where everything becomes 'fun'.
>> >
>> > >> --John
>> >
>> > >> On Fri, Feb 13, 2009 at 9:37 AM, David Zhou 
>> wrote:
>> >
>> > >> >http://media.nodnod.net/test.htmlworksfor me.  Is it because I'm
>> not
>> > >> > serving the page as application/xhtml+xml?
>> >
>> > >> > -- dz
>> >
>> > >> > On Fri, Feb 13, 2009 at 9:31 AM, Dave Methvin <
>> dave.meth...@gmail.com>
>> > wrote:
>> >
>> > >> >> Me too.
>> >
>> > >> >> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/
>> > >> >> 2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
>> >
>> > --
>> > Lift, the simply functional web frameworkhttp://liftweb.net
>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > Follow me:http://twitter.com/dpp
>> > Git some:http://github.com/dpp
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
>
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: thanks

[Jorge Ortiz]

On Thu, Feb 12, 2009 at 2:54 PM, Oliver  wrote:

>
> Thanks for all the help and support over the last few months. During
> that time, I've developed several
> Lift applications that are now successfully running in production at
> the company I work for.
>
> One of the things that has impressed me is the community spirit of the
> group.  I've had pretty much
> all my questions answered and problems fixed very quickly. This gave
> me confidence to push the
> adoption of the framework.
>
> I haven't always agreed with some of the design decisions in Lift, but
> that's true of any framework. I bet
> even a framework founder doesn't like everything about it.  Anyway
> sometimes programmers have to agree
> to disagree.
>
> I now find myself in the position of having to consider Slinky as an
> alternative to Lift. This brings up
> questions in my mind about community, support and maturity.  I'm not
> willing to let go of Lift's
> xhtml templating paradigm, so I can see some interesting discussions ahead.


One of the projects I keep putting off is to extract Lift's templating
system into a component that could be used as a stand-alone library. If this
is something you'd be interested in, let me know and I'll try to prioritize
it.

cheers
> Oliver
>
> >
>

--~--~-~--~~~---~--~~
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: IMPORTANT: Library Upgrades

[Jorge Ortiz]

Ok, two more upgrades. Do note that Blueprint changed it's directory layout.
If you're using the  snippet you should be fine though.

Blueprint CSS
0.6 -> 0.8

YUI
2.5.1 -> 2.6.0

--j

On Thu, Feb 12, 2009 at 11:58 AM, Jorge Ortiz  wrote:

> You're right, I completely forgot about Blueprint and YUI. I'll get those
> right away.
>
> Although it seems like the latest version of Blueprint still has issues
> with Opera, IE 6, and IE 5.5 (!!!). See:
> http://wiki.github.com/joshuaclayton/blueprint-css/browser-compatibility-list
>
> --j
>
>
> On Thu, Feb 12, 2009 at 11:00 AM, Joachim A.  > wrote:
>
>>
>> Jorge,
>> thanks a lot for that (I especially like the JQuery 1.3.1 update).
>>
>> Is it possible to update to the latest blueprint css version? 0.8 was
>> released
>> 2009-02-06. I noticed some type/font problem in Opera with the version
>> shipped
>> with Lift.
>>
>> Joachim
>>
>> > I've upgraded the dependencies for all of the Lift components and sample
>> > projects. I used the latest backward-compatible version that was
>> available
>> > on public Maven repositories. (See below for the complete list.) PLEASE
>> > CHECK YOUR APPS to make sure nothing breaks. You only have a couple of
>> > weeks to get bug reports in before our major 1.0 release.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: IMPORTANT: Library Upgrades

[Jorge Ortiz]

You're right, I completely forgot about Blueprint and YUI. I'll get those
right away.

Although it seems like the latest version of Blueprint still has issues with
Opera, IE 6, and IE 5.5 (!!!). See:
http://wiki.github.com/joshuaclayton/blueprint-css/browser-compatibility-list

--j

On Thu, Feb 12, 2009 at 11:00 AM, Joachim A.
wrote:

>
> Jorge,
> thanks a lot for that (I especially like the JQuery 1.3.1 update).
>
> Is it possible to update to the latest blueprint css version? 0.8 was
> released
> 2009-02-06. I noticed some type/font problem in Opera with the version
> shipped
> with Lift.
>
> Joachim
>
> > I've upgraded the dependencies for all of the Lift components and sample
> > projects. I used the latest backward-compatible version that was
> available
> > on public Maven repositories. (See below for the complete list.) PLEASE
> > CHECK YOUR APPS to make sure nothing breaks. You only have a couple of
> > weeks to get bug reports in before our major 1.0 release.
>
> >
>

--~--~-~--~~~---~--~~
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] IMPORTANT: Library Upgrades

[Jorge Ortiz]

I've upgraded the dependencies for all of the Lift components and sample
projects. I used the latest backward-compatible version that was available
on public Maven repositories. (See below for the complete list.) PLEASE
CHECK YOUR APPS to make sure nothing breaks. You only have a couple of weeks
to get bug reports in before our major 1.0 release.

--j

JQuery
1.2.6 -> 1.3.1

javax.servlet
2.4 -> 2.5

Derby
10.2.2.0 -> 10.4.2.0

JUnit
3.8.1/4.4 -> 4.5

MySQL Connector/Java
5.0.4 -> 5.1.6

Specs
1.4.0/1.4.3-SNAPSHOT -> 1.4.3

Scalatest
0.9.3 -> 0.9.4

SLF4J
1.5.0 -> 1.5.6

Log4J
1.2.12 -> 1.2.14

H2
1.0.63 -> 1.0.79

PostgreSQL JDBC
8.2-507.jdbc3 -> 8.3-603.jdbc3

RabbitMQ Client
1.2.0 -> 1.3.0

Apache HttpClient
4.0-beta1 -> 4.0-beta2

commons-fileupload
1.2 -> 1.2.1

commons-collections
3.2 -> 3.2.1

commons-httpclient
3.0.1 -> 3.1

Smack + Smackx
3.0.4 -> 3.1.0

hibernate-entitymanager
3.3.1.ga -> 3.3.2.GA

cglib
2.1_3 -> 2.2

objenesis
1.0 -> 1.1

--~--~-~--~~~---~--~~
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: *** BREAKING CHANGES ***

[Jorge Ortiz]

Try (without the = sign):

LiftRules.exceptionHandler.prepend {
   case (mode, state, ex) => RedirectResponse("/error")
}

--j

On Mon, Feb 9, 2009 at 10:47 PM, Oliver  wrote:

>
> If I try to use the following, I get a reassignment to Val error - any
> ideas?
>
> LiftRules.exceptionHandler.prepend = {
>case (mode, state, ex) => RedirectResponse("/error")
> }
>
> On Wed, Dec 24, 2008 at 5:41 AM, Marius  wrote:
> >
> > Folks,
> >
> > I just committed a couple of changes that may impact your application.
> >
> > 1. LiftRules.logAndReturnExceptionToBrowser and
> > LiftRules.browserResponseToException have been removed. These were two
> > different variables that did pretty much the same thing in fact the
> > first ultimately called the former. These have been replaced with:
> >
> >
> > var exceptionHandler = RulesSeq[ExceptionHandlerPF]
> >
> > having
> >
> > type ExceptionHandlerPF = PartialFunction[(Props.RunModes.Value, Req,
> > Throwable), LiftResponse]
> >
> > By default a partial function is appended and it is the same code that
> > used to be for LiftRules.browserResponseToException.
> >
> > So up until now probably your application was using something like:
> >
> > LiftRules.logAndReturnExceptionToBrowser = {
> >case (state, ex) => RedirectResponse("/error")
> > }
> >
> > now this turns into:
> >
> > LiftRules.exceptionHandler.prepend = {
> >case (mode, state, ex) => RedirectResponse("/error")
> > }
> >
> >
> > 2. More unification of Ajax notices with "static" notices. So far to
> > apply styling information (css classes etc) to Ajax notices we used
> > three LiftRules variables:
> >
> >  var ajaxNoticeMeta: Can[AjaxMessageMeta]
> >  var ajaxWarningMeta: Can[AjaxMessageMeta]
> >  var ajaxErrorMeta: Can[AjaxMessageMeta]
> >
> > the motivation was that in order for Lift to send down the correct
> > style information for Ajax/Comet notices it needed to maintain this
> > information. Now I finally found time to do it. The above variables
> > are gone. Instead the same styling information that you use for
> > lift:msgs and lift:msg snippets will be applied for AJax and Comet
> > notices. The styling information is captured when these snippets are
> > executed and used whenever you're using notices for AJax response or
> > from a Comet actor.
> >
> >
> > Br's,
> > Marius
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to 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: Using Quaere in Scala

[Jorge Ortiz]

You may want to look at this
http://szeiger.de/blog/2008/12/21/a-type-safe-database-query-dsl-for-scala/

--j

On Thu, Feb 5, 2009 at 11:21 AM, Meredith Gregory
wrote:

> Scalads and lasses and Lifted,
> Does anyone have any experience with using Quaere under Scala? In
> particular, i'm wondering if anyone has already done implementations for
> flatMap, etc? This would seem a quick and relatively painless way to get
> type safety on top of a nearly LINQ implementation that lacks some type
> safety.
>
> Best wishes,
>
> --greg
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 806 55th St NE
> Seattle, WA 98105
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.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
-~--~~~~--~~--~--~---

[Lift] Fwd: [scala] Jane Street Summer Program

[Jorge Ortiz]

If you're a student, Jane Street Capital can give you money to work on
functional programming for a summer...

--j

-- Forwarded message --
From: James Iry 
Date: Mon, Feb 2, 2009 at 9:36 AM
Subject: [scala] Jane Street Summer Program
To: Scala list 


This caught my eye and might be interesting to some Scalars out there.  This
year they aren't just focusing on OCaml.

=

The Jane Street Summer Project is aimed at encouraging growth in the
functional programming community by funding students over the summer to work
on open-source projects in various functional programming languages (with a
focus on our favorite language, OCaml). We do that by funding students and
faculty to work together over the summer to create software that makes it
easier for people who are using functional languages as an ends rather than
a means.

The JSSP is funded by Jane Street Capital . We make
extensive use of OCaml at Jane Street , and
it's in our interest to see the FP community thrive. Plus, we think it will
be fun.

For more detailed information, check out the faq!
http://ocaml.janestreet.com/?q=node/57

--~--~-~--~~~---~--~~
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: JPA is killing me. Enumeration hell.

[Jorge Ortiz]

Glad it worked.

I'll see what can be done about preventing this kind of bug in the future.

--j

On Thu, Jan 22, 2009 at 4:58 PM, Charles F. Munat  wrote:

>
> Thank you! Thank you! Thank you! Thank you! Thank you!
>
> That worked. I should've seen it though as I'd already made that fix on
> other sites. I don't know how I missed it. Tired, I guess.
>
> Pressure off now for a moment at least.
>
> Chas.
>
> Jorge Ortiz wrote:
> > Ahh, I see what the problem might be. There was another change to
> EnumvType:
> >
> > Replace this line:
> >   return et.valueOf(value)
> > With this line:
> >   return et.valueOf(value).getOrElse(null)
> >
> > I'm sorry this is causing you so much trouble Chas. I made changes to
> > classes in JPADemo and didn't realize they were used as template code
> > for other projects.
> >
> > Perhaps these classes should be rolled into a lift-jpa module so that
> > everyone can share the same code?
> >
> > --j
> >
> > On Thu, Jan 22, 2009 at 3:16 PM, Charles F. Munat  > <mailto:c...@munat.com>> wrote:
> >
> >
> > I have an entity thus:
> >
> > @Entity
> > @Table{val name = "cocktails"}
> > class Cocktail extends BaseEntity {
> >   @Id
> >   @GeneratedValue{val strategy = GenerationType.AUTO}
> >   var id : Long = _
> >
> >   var name : String = ""
> >
> >   var description : String = ""
> >
> >   var ingredients : String = ""
> >
> >   @Column{val name = "file_name"}
> >   var fileName : String = ""
> >
> >   @Column{val name = "is_archived"}
> >   var isArchived : Boolean = false
> >
> >   @Type{val `type` = "com.xxx.model.CocktailGroupType"}
> >   @Column{val name="cocktail_group"}
> >   var cocktailGroup: CocktailGroup.Value = CocktailGroup.Originals
> > }
> >
> >
> >
> > Which uses this enumeration:
> >
> > object CocktailGroup extends Enumeration with Enumv {
> >   val Originals = Value("Originals")
> >   val Contemporaries = Value("Contemporaries")
> >   val Classics = Value("Classics")
> >   val Others = Value("Others")
> > }
> >
> > class CocktailGroupType extends EnumvType(CocktailGroup) {}
> >
> >
> >
> > Which is queried thus in orm.xml:
> >
> > 
> >   
> > 
> >
> >
> >
> > And called from CocktailOps.scala:
> >
> > 120: val cocktails = Model.createNamedQuery[Cocktail](
> >"findCocktailsByGroup",
> >"cocktailGroup" -> "Originals").findAll
> >
> >
> >
> > Using Enumv:
> >
> > trait Enumv  {
> >
> >   this: Enumeration =>
> >
> >   private var nameDescriptionMap =
> > scala.collection.mutable.Map[String, String]()
> >
> >   def Value(name: String, desc: String) : Value = {
> > nameDescriptionMap += (name -> desc)
> > new Val(name)
> >   }
> >
> >   def getDescriptionOrName(ev: this.Value) = {
> > try {
> >   nameDescriptionMap(""+ev)
> > } catch {
> >   case e: NoSuchElementException => ev.toString
> > }
> >   }
> >
> >   def getNameDescriptionList =  this.elements.toList.map(
> > v => (v.toString, getDescriptionOrName(v) ) ).toList
> > }
> >
> >
> >
> > And EnumvType:
> >
> > abstract class EnumvType(val et: Enumeration with EnumTrait)
> >   extends UserType {
> >
> >   val SQL_TYPES = Array({Types.VARCHAR})
> >
> >   override def sqlTypes() = SQL_TYPES
> >
> >   override def returnedClass = classOf[et.Value]
> >
> >   override def equals(x: Object, y: Object): Boolean = {
> > return x == y
> >   }
> >
> >   override def hashCode(x: Object) = x.hashCode
> >
> >   override def nullSafeGet(resultSet: ResultSet,
> >names: Array[String],
> >owner: Object): Object = {
> > val value = resultSet.getString(names(0))
> > if (resultSet.wasNull()) return null
> > else {
> >  

[Lift] Re: JPA is killing me. Enumeration hell.

[Jorge Ortiz]

Ahh, I see what the problem might be. There was another change to EnumvType:

Replace this line:
  return et.valueOf(value)
With this line:
  return et.valueOf(value).getOrElse(null)

I'm sorry this is causing you so much trouble Chas. I made changes to
classes in JPADemo and didn't realize they were used as template code for
other projects.

Perhaps these classes should be rolled into a lift-jpa module so that
everyone can share the same code?

--j

On Thu, Jan 22, 2009 at 3:16 PM, Charles F. Munat  wrote:

>
> I have an entity thus:
>
> @Entity
> @Table{val name = "cocktails"}
> class Cocktail extends BaseEntity {
>   @Id
>   @GeneratedValue{val strategy = GenerationType.AUTO}
>   var id : Long = _
>
>   var name : String = ""
>
>   var description : String = ""
>
>   var ingredients : String = ""
>
>   @Column{val name = "file_name"}
>   var fileName : String = ""
>
>   @Column{val name = "is_archived"}
>   var isArchived : Boolean = false
>
>   @Type{val `type` = "com.xxx.model.CocktailGroupType"}
>   @Column{val name="cocktail_group"}
>   var cocktailGroup: CocktailGroup.Value = CocktailGroup.Originals
> }
>
>
>
> Which uses this enumeration:
>
> object CocktailGroup extends Enumeration with Enumv {
>   val Originals = Value("Originals")
>   val Contemporaries = Value("Contemporaries")
>   val Classics = Value("Classics")
>   val Others = Value("Others")
> }
>
> class CocktailGroupType extends EnumvType(CocktailGroup) {}
>
>
>
> Which is queried thus in orm.xml:
>
> 
>   
> 
>
>
>
> And called from CocktailOps.scala:
>
> 120: val cocktails = Model.createNamedQuery[Cocktail](
>"findCocktailsByGroup",
>"cocktailGroup" -> "Originals").findAll
>
>
>
> Using Enumv:
>
> trait Enumv  {
>
>   this: Enumeration =>
>
>   private var nameDescriptionMap =
> scala.collection.mutable.Map[String, String]()
>
>   def Value(name: String, desc: String) : Value = {
> nameDescriptionMap += (name -> desc)
> new Val(name)
>   }
>
>   def getDescriptionOrName(ev: this.Value) = {
> try {
>   nameDescriptionMap(""+ev)
> } catch {
>   case e: NoSuchElementException => ev.toString
> }
>   }
>
>   def getNameDescriptionList =  this.elements.toList.map(
> v => (v.toString, getDescriptionOrName(v) ) ).toList
> }
>
>
>
> And EnumvType:
>
> abstract class EnumvType(val et: Enumeration with EnumTrait)
>   extends UserType {
>
>   val SQL_TYPES = Array({Types.VARCHAR})
>
>   override def sqlTypes() = SQL_TYPES
>
>   override def returnedClass = classOf[et.Value]
>
>   override def equals(x: Object, y: Object): Boolean = {
> return x == y
>   }
>
>   override def hashCode(x: Object) = x.hashCode
>
>   override def nullSafeGet(resultSet: ResultSet,
>names: Array[String],
>owner: Object): Object = {
> val value = resultSet.getString(names(0))
> if (resultSet.wasNull()) return null
> else {
>   return et.valueOf(value)
> }
>   }
>
>   override def nullSafeSet(statement: PreparedStatement,
>value: Object,
>index: Int): Unit = {
> if (value == null) {
>   statement.setNull(index, Types.VARCHAR)
> } else {
>   val en = value.toString
>   statement.setString(index, en)
> }
>   }
>
>   override def deepCopy(value: Object): Object = value
>
>   override def isMutable() = false
>
>   override def disassemble(value: Object) =
> value.asInstanceOf[Serializable]
>
>   override def assemble(cached: Serializable, owner: Object):
> Serializable = cached
>
>   override def replace(original: Object,
>target: Object,
>owner: Object) = original
>
> }
>
>
> Which gets me this error:
>
> Exception occured while processing /drinks/
>
> Message: javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: could not set a field value by
> reflection setter of com.xxx.model.Cocktail.cocktailGroup
>
>  
> org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:630)
>org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:75)
>com.xxx.model.ScalaQuery.getResultList(JPA.scala:82)
>com.xxx.model.ScalaQuery.findAll(JPA.scala:77)
>com.xxx.snippet.CocktailOps.originals(CocktailOps.scala:120)
>
>
>
>
> I have tried everything I can think of. This used to work before the
> recent switch to 2.7.3. Can anyone spot the problem?
>
> Thanks. Website down. Am really screwed here.
>
> Chas.
>
> >
>

--~--~-~--~~~---~--~~
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: JPA is killing me. Enumeration hell.

[Jorge Ortiz]

I don't really know much about JPA, but just a quick observation on the code
you posted:

Your code has line:
  abstract class EnumvType(val et: Enumeration with EnumTrait) extends
UserType {
whereas JPA Demo has line:
  abstract class EnumvType(val et: Enumeration with Enumv) extends UserType
{

I don't know what your EnumTrait is, or whether it might be causing the
problem, but it's worth noting.

One thing I can do is release a version of 0.10 that compiles against Scala
2.7.2 and rolls back the minor changes made to Lift to compile against
2.7.2. But I don't know how David et al feel about this.

--j

On Thu, Jan 22, 2009 at 3:16 PM, Charles F. Munat  wrote:

>
> I have an entity thus:
>
> @Entity
> @Table{val name = "cocktails"}
> class Cocktail extends BaseEntity {
>   @Id
>   @GeneratedValue{val strategy = GenerationType.AUTO}
>   var id : Long = _
>
>   var name : String = ""
>
>   var description : String = ""
>
>   var ingredients : String = ""
>
>   @Column{val name = "file_name"}
>   var fileName : String = ""
>
>   @Column{val name = "is_archived"}
>   var isArchived : Boolean = false
>
>   @Type{val `type` = "com.xxx.model.CocktailGroupType"}
>   @Column{val name="cocktail_group"}
>   var cocktailGroup: CocktailGroup.Value = CocktailGroup.Originals
> }
>
>
>
> Which uses this enumeration:
>
> object CocktailGroup extends Enumeration with Enumv {
>   val Originals = Value("Originals")
>   val Contemporaries = Value("Contemporaries")
>   val Classics = Value("Classics")
>   val Others = Value("Others")
> }
>
> class CocktailGroupType extends EnumvType(CocktailGroup) {}
>
>
>
> Which is queried thus in orm.xml:
>
> 
>   
> 
>
>
>
> And called from CocktailOps.scala:
>
> 120: val cocktails = Model.createNamedQuery[Cocktail](
>"findCocktailsByGroup",
>"cocktailGroup" -> "Originals").findAll
>
>
>
> Using Enumv:
>
> trait Enumv  {
>
>   this: Enumeration =>
>
>   private var nameDescriptionMap =
> scala.collection.mutable.Map[String, String]()
>
>   def Value(name: String, desc: String) : Value = {
> nameDescriptionMap += (name -> desc)
> new Val(name)
>   }
>
>   def getDescriptionOrName(ev: this.Value) = {
> try {
>   nameDescriptionMap(""+ev)
> } catch {
>   case e: NoSuchElementException => ev.toString
> }
>   }
>
>   def getNameDescriptionList =  this.elements.toList.map(
> v => (v.toString, getDescriptionOrName(v) ) ).toList
> }
>
>
>
> And EnumvType:
>
> abstract class EnumvType(val et: Enumeration with EnumTrait)
>   extends UserType {
>
>   val SQL_TYPES = Array({Types.VARCHAR})
>
>   override def sqlTypes() = SQL_TYPES
>
>   override def returnedClass = classOf[et.Value]
>
>   override def equals(x: Object, y: Object): Boolean = {
> return x == y
>   }
>
>   override def hashCode(x: Object) = x.hashCode
>
>   override def nullSafeGet(resultSet: ResultSet,
>names: Array[String],
>owner: Object): Object = {
> val value = resultSet.getString(names(0))
> if (resultSet.wasNull()) return null
> else {
>   return et.valueOf(value)
> }
>   }
>
>   override def nullSafeSet(statement: PreparedStatement,
>value: Object,
>index: Int): Unit = {
> if (value == null) {
>   statement.setNull(index, Types.VARCHAR)
> } else {
>   val en = value.toString
>   statement.setString(index, en)
> }
>   }
>
>   override def deepCopy(value: Object): Object = value
>
>   override def isMutable() = false
>
>   override def disassemble(value: Object) =
> value.asInstanceOf[Serializable]
>
>   override def assemble(cached: Serializable, owner: Object):
> Serializable = cached
>
>   override def replace(original: Object,
>target: Object,
>owner: Object) = original
>
> }
>
>
> Which gets me this error:
>
> Exception occured while processing /drinks/
>
> Message: javax.persistence.PersistenceException:
> org.hibernate.PropertyAccessException: could not set a field value by
> reflection setter of com.xxx.model.Cocktail.cocktailGroup
>
>  
> org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:630)
>org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:75)
>com.xxx.model.ScalaQuery.getResultList(JPA.scala:82)
>com.xxx.model.ScalaQuery.findAll(JPA.scala:77)
>com.xxx.snippet.CocktailOps.originals(CocktailOps.scala:120)
>
>
>
>
> I have tried everything I can think of. This used to work before the
> recent switch to 2.7.3. Can anyone spot the problem?
>
> Thanks. Website down. Am really screwed here.
>
> Chas.
>
> >
>

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

[Lift] Re: Heartbeat

[Jorge Ortiz]

Summary:

DPP: I can haz heartbeat?
Marius: Heartbeat? I dunno... that sounds ugly...
DPP: It comes with GC too!
Marius: Oh hellz yeah!

--j

On Thu, Jan 22, 2009 at 10:30 AM, Marius  wrote:

>
>
>
> On Jan 22, 8:20 pm, David Pollak 
> wrote:
> > On Thu, Jan 22, 2009 at 9:35 AM, Marius  wrote:
> >
> > > On Jan 22, 7:17 pm, David Pollak 
> > > wrote:
> > > > On Thu, Jan 22, 2009 at 9:12 AM, Marius 
> wrote:
> >
> > > > > Hmmm ... personally I'm not that thrilled about it. Can't we have
> an
> > > > > internal keep-alive mechanism that keeps the HTTP session not to
> > > > > expire? ... I wonder if just getting the HttpSession reference
> > > > > periodically and just don't do much with it would make the
> container
> > > > > to not expire the session.(Haven;t tried it though)
> >
> > > > > What if we do not rely on HTTP session at all? ... and use our own
> > > > > session cookie&url rewriting? ... the downside would be risk for
> the
> > > > > users to store stuff directly on the HTTP session but I wonder if
> > > > > anyone really does that in practice. LiftSession is most often
> used.
> >
> > > > > The reason I'm not very excited about it is that browsers have
> limited
> > > > > parallel channels (2, 4, 8 etc.) shared between all tabs (AFAIK)
> After
> > > > > that AJax requests are queued.
> >
> > > > Yep.  Lift's comet stuff works around this limit.
> >
> > > > The heartbeat will be once every 30/60/90 seconds and it should be a
> > > short
> > > > message that will fit into 1 or 2 MTUs (packets) so the time to send
> and
> > > > service will be quick.
> >
> > > > The reason for the heartbeat is not simply to keep the session alive,
> but
> > > to
> > > > keep sub-session data alive (what things on the page relate to
> > > server-side
> > > > state... functions bound to HTML elements).  Knowing what pages are
> open
> > > > with what HTML elements allows Lift to garbage collect unreferenced
> > > > functions.
> >
> > >  ... but when you are saying "to garbage collect unreferenced
> > > functions." do you mean the mapped functions?
> >
> > Yes.
> >
> > > Just asking cause I'm
> > > not aware of a mechanism that actually cleans up mapped functions as
> > > they are are cleared when session terminates.
> >
> > There is no mechanism, but there needs to be a mechanism before we call
> Lift
> > 1.0.  It's been on my list of over a year and I've explored different
> > alternatives and reviewed what different frameworks do.  The best I can
> come
> > up with is a garbage collection scheme that works like the JVM's GC.  You
> > have to know what's in the browser and you have to know what page the
> > browser is on.  In Seaside, every URL has a sub-session token.  I really
> > despise this approach because it makes URLs look ugly and if we did this,
> > Charles (and others) would come after us with a meat ax or worse.
>
> Oh for sure :) !
>
> > We could
> > re-write the URLs just before they're submitted, but it still doesn't
> answer
> > the question about page modification after a full page load.
> >
> > So, at the end of the day, I think Lift needs to have a constant
> inventory
> > of what's on the page and GC stuff that hasn't been seen on any page in
> the
> > last few minutes.  Thus, the heartbeat.
> >
> > > But maybe I'm missing
> > > something here ...
> >
> > No... you're missing nothing.  I was brief and circumspec in my question
> and
> > you're drilling into the issue.  Drilling is good.
>
> Now I'm good. Thank you Dave !
>
> >
> > Thanks,
> >
> > David
> >
> >
> >
> >
> >
> > > > > Br's,
> > > > > Marius
> >
> > > > > On Jan 22, 1:52 am, David Pollak 
> > > > > wrote:
> > > > > > Folks,
> >
> > > > > > I've been working on some state related stuff in Lift.  It would
> be
> > > very
> > > > > > helpful to have a heartbeat that goes from the browser to the
> server
> > > > > every
> > > > > > 30 seconds or so.  If you've got a Comet component on the page,
> the
> > > > > > heartbeat will be part of the comet request.
> >
> > > > > > The benefits to this kind of mechanism includes never having an
> idle
> > > > > session
> > > > > > time out.
> >
> > > > > > Any objections?
> >
> > > > > > Thanks,
> >
> > > > > > David
> >
> > > > > > --
> > > > > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > > > > Collaborative Task Managementhttp://much4.us
> > > > > > Follow me:http://twitter.com/dpp
> > > > > > Git some:http://github.com/dpp
> >
> > > > --
> > > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > > Collaborative Task Managementhttp://much4.us
> > > > Follow me:http://twitter.com/dpp
> > > > Git some:http://github.com/dpp
> >
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Collaborative Task Managementhttp://much4.us
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" grou

[Lift] Re: Writing tests for actors

[Jorge Ortiz]

Hey Tim,

Testing concurrent code is an Open Problem. That said, keeping pairs of
(Message, Response) where you send an actor a Message and get a Response is
not a bad idea.

However, I see two problems with this approach. Fist, with many uses of
actors, when you send a message you don't expect a response. Second, it's
not clear whether you're not really testing the concurrency of the actors.
Actors can dead/livelock just like threads can, and often these bad states
are only observed when particular actions happen at particular times and the
scheduler just happens to cycle through actors in just the wrong order to
make everything lock up. Just like with threads, there no real good way to
-guarantee- that you've avoided these problems other than looking at your
design and going "Hmmm...".

Since there are no guarantees, the best we can do is to stress test and
check if things break. The best approach I can think of is to test your
actors by hitting them with messages that mimic real world conditions. For
this it's best to use more actors, to simulate many things happening to your
system at the same time. You can test for correctness guarantees (after this
sequence of actions, this should be the state of the world) and for
performance guarantees (total throughput, average response time, etc).

HTH,

--j

On Fri, Jan 16, 2009 at 8:16 PM, timshawn  wrote:

>
> Hello Lifters,
>
> I'm pretty new at programming with actors, and right now I am starting
> to write an app on lift for a web-based game, which uses cometactor
> and actors in general.
> I was wondering if anyone can give me advice on how to write tests for
> actors, especially testing multiple actors that interact with each
> other.
> I was thinking maybe keeping a Map where the keys are the case classes
> for messages, and the values are the valid responses/thunks that can
> contain assertions, iterating through and sending them to the actors
> under test.
>
> Does this sound reasonable? can you think of another way of doing it?
> How have you done it in your apps?
>
> Thanks!
> Tim
> >
>

--~--~-~--~~~---~--~~
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: Can only throw throwable objects?

[Jorge Ortiz]

Sorry, one paragraph there was misleading. Enumv didn't go anywhere, it's
still around. However, it did lose it's valueOf method because it conflicted
with Enumeration's new valueOf method.

The new version looks like this:
http://github.com/dpp/liftweb/blob/67a89ceafa6d7f86028eccfe8958b20c30ec1b3f/sites/JPADemo/JPADemo-spa/src/main/scala/net/liftweb/jpademo/model/Enumv.scala

--j

On Sun, Jan 18, 2009 at 11:06 AM, Jorge Ortiz  wrote:

> Yes, sorry. Scala 2.7.3 added a method to Enumeration with type signature:
> valueOf(String): Option[Value]
>
> We previously had a trait Enumv in net.liftweb.jpademo.model which had a
> helper method for enumerations with type signature:
> valueOf(String): Value // returns null if not found
>
> Because of the name conflict, the method in JPADemo was removed in favor of
> using the standard library's method, but it also means the return type
> changed from Value to Option[Value].
>
> Sorry there was no announcement about this breaking change.
>
> --j
>
>
> On Sat, Jan 17, 2009 at 1:54 PM, Charles F. Munat  wrote:
>
>>
>> Ah. Wrong version of Scala. Good catch.
>>
>> Now I have an error that says: error overriding method valueOf in class
>> Enumeration.
>>
>> But when I add "override" to the valueOf def in EnumV (I'm using the JPA
>> example), I get the following:
>>
>> error: method valueOf overrides nothing
>> [WARNING]   override def valueOf(str: String) =
>> this.elements.toList.filter(_.toString == str) match {
>>
>> I'm getting this on every site on which I use an enumeration (which is
>> all five of them). Did something change in Enumeration between 2.7.2 and
>> 2.7.3?
>>
>> Chas.
>>
>> Marius wrote:
>> > You have a java.lang.VerifyError ... meaning that you have internal
>> > class inconsistencies. Perhaps using different versions of lift and
>> > lift-utils?
>> >
>> > On Jan 17, 11:04 pm, "Charles F. Munat"  wrote:
>> >> Any idea what's causing this?
>> >>
>> >> [INFO] Starting jetty 6.1H.14.1 ...
>> >> 2009-01-17 12:48:04.545::INFO:  jetty-6.1H.14.1
>> >> 2009-01-17 12:48:04.828::INFO:  No Transaction manager found - if your
>> >> webapp requires one, please configure one.
>> >> 2009-01-17 12:48:05.272::WARN:  failed LiftFilter
>> >> java.lang.VerifyError: (class: net/liftweb/util/EmptyBox, method:
>> >> open_$bang signature: ()Ljava/lang/Object;) Can only throw Throwable
>> objects
>> >> at net.liftweb.http.LiftRules$.(LiftRules.scala:171)
>> >> at net.liftweb.http.LiftRules$.(LiftRules.scala)
>> >> at net.liftweb.http.LiftFilter.init(LiftServlet.scala:516)
>> >> at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
>> >> at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> >> at
>> >>
>> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:620)
>> >> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
>> >> at
>> >>
>> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
>> >> at
>> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
>> >> at
>> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
>> >> at
>> >>
>> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124)
>> >> at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> >> at
>> >>
>> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
>> >> at
>> >>
>> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
>> >> at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> >> at
>> >>
>> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
>> >> at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> >> at
>> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
>> >> at org.mortbay.jetty.Server.doStart(Server.java:222)
>> >> at
>> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> >> at
>> >>
>> org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
>> >> at
>&

[Lift] Re: Can only throw throwable objects?

[Jorge Ortiz]

Yes, sorry. Scala 2.7.3 added a method to Enumeration with type signature:
valueOf(String): Option[Value]

We previously had a trait Enumv in net.liftweb.jpademo.model which had a
helper method for enumerations with type signature:
valueOf(String): Value // returns null if not found

Because of the name conflict, the method in JPADemo was removed in favor of
using the standard library's method, but it also means the return type
changed from Value to Option[Value].

Sorry there was no announcement about this breaking change.

--j

On Sat, Jan 17, 2009 at 1:54 PM, Charles F. Munat  wrote:

>
> Ah. Wrong version of Scala. Good catch.
>
> Now I have an error that says: error overriding method valueOf in class
> Enumeration.
>
> But when I add "override" to the valueOf def in EnumV (I'm using the JPA
> example), I get the following:
>
> error: method valueOf overrides nothing
> [WARNING]   override def valueOf(str: String) =
> this.elements.toList.filter(_.toString == str) match {
>
> I'm getting this on every site on which I use an enumeration (which is
> all five of them). Did something change in Enumeration between 2.7.2 and
> 2.7.3?
>
> Chas.
>
> Marius wrote:
> > You have a java.lang.VerifyError ... meaning that you have internal
> > class inconsistencies. Perhaps using different versions of lift and
> > lift-utils?
> >
> > On Jan 17, 11:04 pm, "Charles F. Munat"  wrote:
> >> Any idea what's causing this?
> >>
> >> [INFO] Starting jetty 6.1H.14.1 ...
> >> 2009-01-17 12:48:04.545::INFO:  jetty-6.1H.14.1
> >> 2009-01-17 12:48:04.828::INFO:  No Transaction manager found - if your
> >> webapp requires one, please configure one.
> >> 2009-01-17 12:48:05.272::WARN:  failed LiftFilter
> >> java.lang.VerifyError: (class: net/liftweb/util/EmptyBox, method:
> >> open_$bang signature: ()Ljava/lang/Object;) Can only throw Throwable
> objects
> >> at net.liftweb.http.LiftRules$.(LiftRules.scala:171)
> >> at net.liftweb.http.LiftRules$.(LiftRules.scala)
> >> at net.liftweb.http.LiftFilter.init(LiftServlet.scala:516)
> >> at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
> >> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> at
> >>
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:620)
> >> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> >> at
> >>
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
> >> at
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> >> at
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
> >> at
> >>
> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124)
> >> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> at
> >>
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> >> at
> >>
> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
> >> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> at
> >>
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> >> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> at
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> >> at org.mortbay.jetty.Server.doStart(Server.java:222)
> >> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> >> at
> >>
> org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
> >> at
> >>
> org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:379)
> >> at
> >>
> org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:321)
> >> at
> >>
> org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:205)
> >> at
> org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
> >> at
> >>
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> >> at
> >>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> >> at
> >>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> >> at
> >>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> >> at
> >>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> >> at
> >>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> >> at
> >>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> >> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
>

[Lift] Re: Lift compiles with 2.7.3.RC2

[Jorge Ortiz]

No, I haven't. I just made sure it compiled and passed tests. I'm traveling
and have little computer time until Monday. I suggest you ask Scala team to
hold off on going final until you run tests.

--j

On Sat, Jan 10, 2009 at 6:50 AM, David Pollak  wrote:

> Jorge,
> Have you done any stress tests to make sure that the Actors memory leak
> thing is fixed?  If not, I'll work some up on Monday.
>
> Thanks,
>
> David
>
>
> On Fri, Jan 9, 2009 at 11:01 PM, Jorge Ortiz wrote:
>
>> I've made two Git branches which compile Lift against Scala 2.7.3-SNAPSHOT
>> and 2.7.3.RC2.
>>
>> As soon as Scala 2.7.3 goes final we'll release Lift 1.0.RC1.
>>
>> --j
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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] Lift compiles with 2.7.3.RC2

[Jorge Ortiz]

I've made two Git branches which compile Lift against Scala 2.7.3-SNAPSHOT
and 2.7.3.RC2.

As soon as Scala 2.7.3 goes final we'll release Lift 1.0.RC1.

--j

--~--~-~--~~~---~--~~
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: AppTest.scala in lift-archetype-basic

[Jorge Ortiz]

Good catch, I've committed your patch.

Thanks Marc!

--j

On Fri, Jan 9, 2009 at 2:55 PM, Marc Boschma

> wrote:

> I've just noticed that the test in AppTest.scala for XML and XHTML etc
> doesn't take into account Html entities...
>
> >
>
>
>
>
> So I suggest the following change (as a diff -c) and attached the full
> file...
>
> --
> *** AppTest.scala.orig  2009-01-10 09:19:45.0 +1100
> --- AppTest.scala   2009-01-10 09:49:47.0 +1100
> ***
> *** 4,9 
> --- 4,10 
>   import _root_.junit.framework._
>   import Assert._
>   import _root_.scala.xml.XML
> + import _root_.net.liftweb.util._
>
>   object AppTest {
> def suite: Test = {
> ***
> *** 36,56 
> def testXml() = {
>   var failed: List[File] = Nil
>
> ! def handled(file: String) =
> !   file.endsWith(".html") || file.endsWith(".xml") ||
> !   file.endsWith(".htm")  || file.endsWith(".xhtml")
>
>   def wellFormed(file: File) {
> if (file.isDirectory)
>   for (f <- file.listFiles) wellFormed(f)
>
> !   if (file.isFile && handled(file.getName)) {
>   try {
> XML.loadFile(file)
>   } catch {
> case e: _root_.org.xml.sax.SAXParseException => failed =
> file :: failed
>   }
> }
>   }
>
>   wellFormed(new File("src/main/webapp"))
> --- 37,65 
> def testXml() = {
>   var failed: List[File] = Nil
>
> ! def handledXml(file: String) =
> !   file.endsWith(".xml")
> !
> ! def handledXHtml(file: String) =
> !   file.endsWith(".html") || file.endsWith(".htm") ||
> file.endsWith(".xhtml")
>
>   def wellFormed(file: File) {
> if (file.isDirectory)
>   for (f <- file.listFiles) wellFormed(f)
>
> !   if (file.isFile && handledXml(file.getName)) {
>   try {
> XML.loadFile(file)
>   } catch {
> case e: _root_.org.xml.sax.SAXParseException => failed =
> file :: failed
>   }
> }
> +   if (file.isFile && handledXHtml(file.getName)) {
> +   PCDataXmlParser(new java.io.FileInputStream(file.getAbsolutePath))
> match {
> + case Full(_) => // file is ok
> + case _ => failed = file :: failed
> +   }
> +   }
>   }
>
>   wellFormed(new File("src/main/webapp"))
>
>
>

--~--~-~--~~~---~--~~
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: Can or Box or something else

[Jorge Ortiz]

And, by the way, squares and triangles are isomorphic (
http://en.wikipedia.org/wiki/Topological_isomorphism).

--j

On Tue, Jan 6, 2009 at 6:44 PM, Tony Morris  wrote:

>
> "related to a combination of Option and Either"
> I'm not sure how I am missing that point since that is exactly the
> code I provided earlier. There is no point, except to assist Oliver in
> looking passed these fancy language tricks.
>
> In a pragmatic and therefore, not very useful way, yes Can is like
> Option. But now that I have subverted what it means for Can to "be
> like" anything I'm going to propose that Can is List - it is either
> empty or has a value (right?). Let's all chime in now with our
> preferred cognitive biases now that we have lost meaning into the
> impractical infection called pragmatism.
>
> A square is like a triangle, but with one extra side. No wait, a
> square is a combination of four triangles. Oh actually, a square is
> like a triangle, except it is not in any way at all.
>
> Don't fall for it Oliver - it's a misintegration.
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> Miles Sabin wrote:
> > On Tue, Jan 6, 2009 at 11:23 PM, Tony Morris 
> > wrote:
> >> No this is a mistake. Can is not an Option. Indeed it is (almost)
> >>  impossible to write Can using Option (if you are familiar with
> >> Peano Arithmetic you will understand the need to qualify with
> >> almost).
> >
> > While you're right in a (very) narrowly technical sense you're
> > missing the point that Lift's Can has functionality that is very
> > closely related to a combination of Option and Either in a
> > touchy-feely pragmatic getting-useful-things-actually-done sort of
> > sense.
> >
> > To prove the point, here,
> >
> > http://www.milessabin.com/misc/Chain.scala
> >
> > is something I put together a while ago which can be used in a very
> >  similar way to Can (at least, I expect that's the case ... I
> > haven't worked with Lift so I can't be sure) but which only exposes
> > Option and Either in it's public interface. It's also sufficiently
> > Monad like to get along nicely with for comprehensions.
> >
> > Given the likelihood of confusion between Can and Option
> > (irrespective the algebraic niceties) I wish Lift had gone for
> > something more like that than a rename to Box.
> >
> > Cheers,
> >
> >
> > Miles
> >
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Can or Box or something else

[Jorge Ortiz]

You're talking about algebraic data types.

The rest of us are discussing classes and inheritance.

When someone says that a Dog "is" an Animal, they clearly don't mean "is
isomorphic to".

--j

On Tue, Jan 6, 2009 at 6:46 PM, Tony Morris  wrote:

>
> Jorge Ortiz wrote:
> > For most people, "is" does not always and exclusively mean
> > "bi-implication". You are free to think this way, if you choose,
> > but please don't impose your Language Police on us.
> >
> > --j
>
> For most people, "is" means "is isomorphic to" when talking about data
> types. Furthermore, you are free to invent your own definition, but it
> is loaded with nothing more than cognitive bias. If Can is Option -
> under a (failed) definition, then Can is also List by precisely the
> same flawed method.
>
> Somehow, I'm not sure it is I who is "missing the point".
>
> I had no intention of this. I'm finished. I hope Oliver has understood.
>
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Can or Box or something else

[Jorge Ortiz]

For most people, "is" does not always and exclusively mean "bi-implication".
You are free to think this way, if you choose, but please don't impose your
Language Police on us.

--j

On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris  wrote:

>
> When talking about data types "is" means "is congruent to" or "is
> isomorphic to". You are not free to use "is" arbitrarily, since if you
> are then Can "is" anything I want it to be.
> Since equivalence can be broken into an implication both ways e.g. A
> -> B and B -> A then it is quite easy to test if "Can is an Option".
>
> def f[A](o: Option[A]): Can[A] // this should be total and bijective
> def g[A](c: Can[A]): Option[A] // this should be total and bijective
>
> The use of => in function signatures means logical implication. Does
> Can imply Option? Yes (you can complete the g function). Does Option
> imply Can? No (you cannot complete the f function). Therefore, Can is
> not an Option. It was not even close (lack of totality in this test is
> catastrophic).
>
> If you want to try to save this notion of "Well Can is a something",
> then I have already pointed out a suggestion. Try to think of others,
> but do not say that Can is an Option - it is not, not even close. Poor
> Oliver was all confuzzled when he popped this one to me the other day.
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> Jorge Ortiz wrote:
> > It depends on what the meaning of "is" is.
> >
> > If Option were not sealed, "Can" could be "implemented" as an
> > Option... by adding Failure and Empty as subclasses of None. In
> > this (OO) sense, a Can is an option.
> >
> > In the algebraic sense, then you're probably right that a Can is
> > not an Option.
> >
> > --j
> >
> > On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris  > <mailto:tonymor...@gmail.com>> wrote:
> >
> >
> > No this is a mistake. Can is not an Option. Indeed it is (almost)
> > impossible to write Can using Option (if you are familiar with
> > Peano Arithmetic you will understand the need to qualify with
> > almost). There is an arrow from forall A. Can[A] to Option[A] but
> > not from forall A. Option[A] to Can[A] (easily) - try it for
> > yourself. To suggest that Can is an Option (or "an Option with more
> > features" or "an Either") is a mistake of misintegration (Peikoff
> > DIM Hypothesis). Indeed the Can algebra has nothing to do with
> > Option (except for the aforementioned function). There is no
> > isomorphism between Can and Option - they are not the same, not
> > even close.
> >
> > Here is a bit of code for fun. Note the bijective function using
> > Either alone:
> >
> > sealed trait T[+A] { val e: Either[(String, T[Throwable],
> > List[(String, Throwable)], Either[A, Unit]]
> >
> > // bijection to e val c: Can[A] = e match { case Left(m, e, c) =>
> > Failure(m, e, // Can makes the mistake of using a data constructor
> > as a type. // Unfortunately Scala permits this. c map toFailure)
> > case Right(e) => e match { case Left(a) => Full(a) case Right(_) =>
> > Empty } } }
> >
> > object T { // construct with Either or Can }
> >
> > -- Tony Morris http://tmorris.net/
> >
> > S, K and I ought to be enough for anybody.
> >
> >
> > David Pollak wrote:
> >> It's an Option.
> >>
> >> It contains a value or it doesn't. In the case that it does not
> >> contain a value, it may contain out of band information. This is
> >> not any different from None which contains information. It
> >> contains the information that it lacks information.
> >>
> >> Sure, you can write Option[T] as Either[T, Nothing], but the
> >> value of only having on type is lost.
> >>
> >> On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
> > mailto:tonymor...@gmail.com>
> >> <mailto:tonymor...@gmail.com <mailto:tonymor...@gmail.com>>>
> > wrote:
> >>
> >>
> >> Right, that's what Oliver said and I was reinforcing it with
> >> deductive reasoning. It is also not Option. It is something else
> >> altogether. Nevertheless, an isomorphism can easily be written
> > with
> >> Either alone (ignoring bottoms). So in some loose sense "it is an
> >>  Either".
> >>
> >> -- Tony Morris http://tmorris.net/
> >>
> >> S, K and I ought t

[Lift] Re: Can or Box or something else

[Jorge Ortiz]

It depends on what the meaning of "is" is.

If Option were not sealed, "Can" could be "implemented" as an Option... by
adding Failure and Empty as subclasses of None. In this (OO) sense, a Can is
an option.

In the algebraic sense, then you're probably right that a Can is not an
Option.

--j

On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris  wrote:

>
> No this is a mistake. Can is not an Option. Indeed it is (almost)
> impossible to write Can using Option (if you are familiar with Peano
> Arithmetic you will understand the need to qualify with almost). There
> is an arrow from forall A. Can[A] to Option[A] but not from forall A.
> Option[A] to Can[A] (easily) - try it for yourself. To suggest that
> Can is an Option (or "an Option with more features" or "an Either") is
> a mistake of misintegration (Peikoff DIM Hypothesis). Indeed the Can
> algebra has nothing to do with Option (except for the aforementioned
> function). There is no isomorphism between Can and Option - they are
> not the same, not even close.
>
> Here is a bit of code for fun. Note the bijective function using
> Either alone:
>
> sealed trait T[+A] {
> val e: Either[(String, T[Throwable], List[(String, Throwable)],
> Either[A, Unit]]
>
> // bijection to e
> val c: Can[A] = e match {
> case Left(m, e, c) => Failure(m, e,
> // Can makes the mistake of using a data constructor as a type.
> // Unfortunately Scala permits this.
> c map toFailure)
> case Right(e) => e match {
> case Left(a) => Full(a)
> case Right(_) => Empty
> }
> }
> }
>
> object T {
> // construct with Either or Can
> }
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> David Pollak wrote:
> > It's an Option.
> >
> > It contains a value or it doesn't. In the case that it does not
> > contain a value, it may contain out of band information. This is
> > not any different from None which contains information. It
> > contains the information that it lacks information.
> >
> > Sure, you can write Option[T] as Either[T, Nothing], but the value
> > of only having on type is lost.
> >
> > On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris  > > wrote:
> >
> >
> > Right, that's what Oliver said and I was reinforcing it with
> > deductive reasoning. It is also not Option. It is something else
> > altogether. Nevertheless, an isomorphism can easily be written with
> > Either alone (ignoring bottoms). So in some loose sense "it is an
> > Either".
> >
> > -- Tony Morris http://tmorris.net/
> >
> > S, K and I ought to be enough for anybody.
> >
> >
> > David Pollak wrote:
> >> Tony,
> >>
> >> Can (now Box) is not an Either.
> >>
> >> David
> >>
> >> On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
> > mailto:tonymor...@gmail.com>
> >> >>
> > wrote:
> >>
> >>
> >> Can is not an Option and to call it so in any way is an error of
> >> misintegration. Indeed it would be an error to "replace Option
> > with
> >> Can" - they are completely different algebras. Either is kinded *
> >> -> * -> * so cannot possible be isomorphic and cannot possibly
> > have
> >> map, flatMap etc (though it can have a bifunctor map being
> >> covariant in both type arguments). However, Either.LeftProjection
> >> and Either.RightProjection are kinded * -> * and are both
> > covariant
> >> functors and monads, hence map, flatMap etc. are available. e.g.
> >> for(x <- either.left) ... is valid, try it.
> >>
> >> Of mild interest, it is possible to construct an isomorphism
> > to Can
> >> using both Either and Option. Indeed, it is possible to construct
> >> an isomorphism to Option using Either e.g. forall A. Option[A] ≡
> >> Either [Unit, A] so it is possible using Either alone. I'll
> >> leave both as reader exercises.
> >>
> >>
> >> On Dec 21 2008, 5:15 am, Oliver Lambert  > 
> >> >> wrote:
> >>> Ok so Can is not either an Either or an Option, its a Can. I
> >> kind of
> >>> wondered when I first used Can, and it was described as an
> >> enhanced
> >>> Option, why it wasn't called something like Option+ with
> >> None, Some
> >>> and Failure.
> >>>
> >>> On 21/12/2008, at 5:47 AM, David Pollak wrote:
> >>>
>  Can has map, flatMap, filter etc. So it can be used in a for
>  comphrension. I don't believe Either has those methods.
> >> Further,
>  Can has a bunch of helpers to turn Empty into Failure
> >>>
>  On Dec 20, 2008 10:33 AM, "Oliver Lambert"  > 
> >> >> wrote:
> >>>
>  Is Can a little less like Option and more like scala.Either,
> >> where
>  the left side is used to indicate failure? On 21/12/2008, at
>  1:43 AM, David Pollak wrote: > Folks, > >
> >> Over the
>  year that Lift has had Can[T...
> >>
> >>
> >>
> >>
> >>
> >> -- Lift, the simply functional web framework http://liftweb.net
> >> Collaborative Task Managemen

[Lift] Re: query about current status of MySQL support

[Jorge Ortiz]

I would highly recommend Aqua Data Studio

--j

On Sun, Jan 4, 2009 at 11:47 PM, Matt Harrington wrote:

>
> On Sun, Jan 4, 2009 at 8:14 PM, O'Rorke Paul  wrote:
>
> > An advantage of MySQL on the Mac is that there is a free, reasonably
> > nice GUI database tool (CocoaMySQL).
> > I could use Derby if I had a similar (preferably free) user
> > interface.  There is one in NetBeans but I don't think there is one in
> > eclipse.
>
> I think David already answered your question about MySQL, but to
> interface with Derby you just need any database utility which speaks
> JDBC.  There are several to choose from, both standalone varieties and
> Eclipse plugins such as this one:
>
>
> http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-379.html
>
> I haven't tried that one myself though.
>
> I'm lead to believe that this app is popular:
>
> http://www.minq.se/products/dbvis/
>
> I personally just use the clients in NetBeans or IntelliJ IDEA.
>
> Matt
>
> >
>

--~--~-~--~~~---~--~~
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: *** Minor breaking change *** - Lift HTTP authentication

[Jorge Ortiz]

Why Box[List[Role]] instead of just List[Role]?

Is there a semantic difference between Empty and Full(Nil)?

--j

On Mon, Dec 29, 2008 at 7:33 AM, Marius  wrote:

>
> Hi,
>
> If you use so far the HTTP authentication support in Lift, you code
> would likely break. So far we could assign a single role to user by
> using userRoleRequestVar. This has been changed from:
>
> object userRole extends RequestVar[Box[Role]](Empty)
>
> to
>
> object userRoles extends RequestVar[Box[List[Role]]](Empty)
>
> In your authentication function you can say:
>
> userRoles(Full(AuthRole("useradmin", "siteadmin"))) or
> userRoles(Full(AuthRole("useradmin")))
>
>
> Br's,
> Marius
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to 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: Can or Box or something else

[Jorge Ortiz]

"Promise" has a specific technical meaning in the context of concurrency.
See: http://en.wikipedia.org/wiki/Futures_and_promises

--j

On Sun, Dec 28, 2008 at 2:46 PM, stephen goldbaum <
stephen.goldb...@gmail.com> wrote:

>
> One last suggestion...  Promise with Fulfilled, Empty, and Broken (my
> other suggestion of Blond, Brunette and Redhead didn't seem to make
> it...).
>
> >
>

--~--~-~--~~~---~--~~
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: todo_steps feedback

[Jorge Ortiz]

> Not that I am aware of, but then I am in Australia and these days almost
> anything could be mucking about with my internet connectivity, but I
> digress...
>

Bit of a sore point, eh? At least in Australia they tell you about the
mucking. In the US that's all "state secrets" or somesuch. It's so secret
that not even the legislature or the judiciary can know about it, but I
digress...

--j

--~--~-~--~~~---~--~~
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: Fwd: [scala-announce] Scala 2.7.3 RC1

[Jorge Ortiz]

It takes a day or so for hudson to pick up new Scala releases (I think
DavidB had a bad experience with a -final release that wasn't really final),
but as soon scala-tools.org picks it up I'm on it.

--j

On Tue, Dec 23, 2008 at 11:11 AM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

> Jorge,
>
> You on the 2.7.3 branch of Lift?
>
> Ideally, we can have 2.7.3 be the 0.10 release on Jan 2.
>
> Thanks,
>
> David
>
>
> -- Forwarded message --
> From: Antonio Cunei 
> Date: Tue, Dec 23, 2008 at 5:43 AM
> Subject: [scala-announce] Scala 2.7.3 RC1
> To: sc...@listes.epfl.ch, scala-annou...@listes.epfl.ch
>
>
> Just in time for Christmas, here is the first release candidate of our
> new Scala distribution: Scala 2.7.3 RC1. This new version is mainly
> intended as a maintenance release: it fixes a number of bugs and
> improves on various aspects of the existing code. There are no new
> features, however; they are being added instead to a new development
> branch, currently in its early stages, that will become the next major
> Scala release sometime next year. If no particular problems are found
> with this first release candidate, a final Scala 2.7.3 release should
> follow in a few weeks.
>
> You can download Scala 2.7.3.RC1, as usual, from our Download Page:
> http://www.scala-lang.org/downloads. An updated Scala plugin for
> Eclipse is also available (see http://www.scala-lang.org/node/94).
>
>  WHAT IS NEW? -
>
> There are no new features, as this is essentially a maintenance release;
> however, many bug fixes and other improvements are available in this
> version, including:
>
>  * fixes for bugs #1460, #1467, #1461, #1464, #1454,
>#1382, #1374, #1402, #1379, #1375, #1241, #1263,
>#1235, #547, #1404, #1390, #1329, #1329, #1367,
>#1323, #1306, #1294, #1249, #508, #1206, #1267,
>#1289, #1271, #998, #1232, #1167, #1315, #820,
>#1083, #1257, #1264, #1358, #1514, #1541
>  * fixed IntMap and LongMap.getOrElse
>  * several optimisation fixes (dead-code elimination)
>  * scaladoc fixes
>  * deepToString fixes
>  * fixed Queue.enqueue
>  * ScalaSwing fixes and improvements
>  * optimisation to Range.foreach (#1297)
>  * fixed EOF problem with RegexParsers.phrase
>  * fixed a problem with files vs. URLs on Windows.
>  * fixed problem with partest-created compilers not finding
>scala package.
>  * fix for testing.Show on .NET
>  * fixes for Windows platform
>  * fixed bug where fsc sometimes fails to start
>  * fix memory leak in handling GC of actors
>  * remove race condition when linking/unlinking actors
>  * thread pool in actor runtime now uses Thread.getState()
>instead of timestamps on JVM 1.5, yielding substantial
>performance improvements
>  * improve actor scheduling on JVM 1.4
>  * fixes to BigDecimal
>  * improvements to JVM 1.4 support
>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: Can or Box or something else

[Jorge Ortiz]

If you want to use ? in your own code, you can always do:

  type ?[T] = Can[T]

  var s: ?[String] = Empty
  s = Full("Hello, world!")

You can put it somewhere and import it anywhere you want to use it.

That said, I think it'd be a really bad idea to do this in Lift's source.
Scala gets enough crap about operators already, we shouldn't be adding any
more, especially not one for something so widely used as Can.

--j

2008/12/21 Marius 

>
> Personally I kind of like ? name ... although I feel many people will
> not. Going further having Full and Empty extending ? may "lift"quite a
> few eyebrows :)
>
> BTW I totally agree that Result is not ok.
>
> Br's,
> Marius
>
> On Dec 21, 7:45 pm, "David Bernard" 
> wrote:
> > current signature :
> >   def doStuff(arg1 : Can[Foo], arg2 : Toto) : Can[Bar]
> >
> > With Result:
> >   def doStuff(arg1 : Result[Foo], arg2 : Toto) : Result[Bar]
> > Result could be good but is not, when used for argument and not for
> "result"
> >
> > more I think about it, more I thought ? was not so wrong/joke. In the
> > Nice language (a old competitor to scala) ? was used to mark value to
> > be potentially null
> >
> > var myVar1 : ?String //myVar1 could be null
> > var myVar2 : String //myVar2 is never null
> >
> > With ?:
> >   def doStuff(arg1 : ?[Foo], arg2 : Toto) : ?[Bar]
> >
> > On Sun, Dec 21, 2008 at 17:42, Mateusz Fiołka 
> wrote:
> > > Result +1
> >
> > > Quite short, only one selfexplaining imo and describes the purpose it
> serves
> > > well. The only downsides of this name is +3 characters and the fact
> that the
> > > class could be used also as non result but for other purpose.
> >
> > > On Sun, Dec 21, 2008 at 3:32 PM, Derek Chen-Becker <
> dchenbec...@gmail.com>
> > > wrote:
> >
> > >> I think that the previously mentioned "Box" would be the only other
> thing
> > >> that has
> >
> > >> The same semantic meaning of "container". Well, as Tim pointed out
> this is
> > >> a US thing for Can...
> > >> The same brevity. I agree with David that commonly used constructs
> should
> > >> be short
> >
> > >> If it was going to change at all, this would be it.
> >
> > >> Derek
> >
> > >> On Sat, Dec 20, 2008 at 11:13 PM, Josh Suereth <
> joshua.suer...@gmail.com>
> > >> wrote:
> >
> > >>> On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert 
> wrote:
> >
> >  Yup, when you chose the original name, you did a good job - why
> second
> >  guess yourself now. Can we just leave it the way it is.
> >
> > >>> Pun intended
> >
> > >>> As to my vote (if I'm allowed one)...
> >
> > >>> Can was slightly confusing, but looking at it vs Option makes a lot
> of
> > >>> sense.  Option is also slightly confusing, because I expected it to
> behave
> > >>> like Either.   Either is a great name, as you can tell what it's
> doing.
> >
> > >>> Result seems ok, but I would vote for something more like Storage.
> Can
> > >>> is pretty succinct, and once you know how to use it, it's not hard to
> > >>> remember the convention.
> >
> > >>> So I'd swing on the side of sticking with Can unless a really good
> name
> > >>> is discovered.
> >
>

--~--~-~--~~~---~--~~
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] Github pages

[Jorge Ortiz]

http://github.com/blog/272-github-pages

--j

--~--~-~--~~~---~--~~
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: behind the scenes with Maven?

[Jorge Ortiz]

Yup, you've about got it right.

As I understand it, Hudson uses Maven to fetch the latest code from Github,
compile, test, and deploy it. (By 'deploy' I mean: put jars, scaladocs, and
archetypes on scala-tools.org)

When commits are made to Github, it takes about an hour for changes to
appear on scala-tools.org

mvn -U forces an update. mvn (without -U) will also periodically check for
updates anyway. mvn -o forces offline (no updates) mode.

--j

On Tue, Dec 16, 2008 at 9:24 PM, Matt Harrington wrote:

>
> A few times over the past week, I've had something of a ghost in the
> machine with Maven.  I haven't spent the time to track things down and
> have just blown away my repository and things resolve themselves.
> However, the next time Maven acts up I want to really figure things
> out.  It'd help if I knew more about what happens behind the scenes
> with 0.10-SNAPSHOT.  Here's a guess:
>
> 1.)  Committers upload to github.org
> 2.)  A machine (named "hudson" maybe?) builds 0.10-SNAPSHOT from the
> github source (how often?)
> 3.)  The compiled artifacts such as lift-mapper are transfered to
> scala-tools.org
> 4.)  Scaladocs are built from step 3 by scala-tools.org
> 5.)  The lift archetypes get updated
>
> Let's say that breaking changes are made in step 1.  That will only
> affect me if I run "mvn -U", right?
>
> ---Matt
>
> >
>

--~--~-~--~~~---~--~~
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: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Jorge Ortiz]

Not to beat a dead horse, but... what's the rationale, again, for throwing
an exception after boot? Is there a real danger to some or all RulesSeqs
being mutable after boot? If some, then those rules should selectively be
protected. Even if they're all dangerous, there are better (i.e., type safe)
ways of protecting RulesSeqs from mutation than just throwing an exception.

Nit-pick: why is 'toList' (which just returns 'rules') defined as
private[http] when 'rules' itself is public?

Also, if RulesSeq are always made up of either Functions or
PartialFunctions, maybe we should enforce that at a type level, and the
helper methods on Seqs of PFs that now exist in the NamedPF object can be
put in the RulesSeq object.

--j

On Sat, Dec 13, 2008 at 2:31 PM, Marius  wrote:

>
> All,
>
> I committed a bunch of changes in LiftRules. In a previous thread
> Jorge suggested the abstraction of LiftRules variables. Lists of
> functions are now abstracted by RulesSeq trait, which contains prepend
> and append functions. Note that if you're calling prepend/append
> functions after boot they will throw an exception. If there are
> compelling reasons not to do this please let us know. This is just a
> mechanism to enforce the use of these functions on startup.
>
> Br's,
> Marius
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to 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: Fwd: [scala-user] Is there a memory leak in 2.7.2 Actors?

[jorge . ortiz]

Can do

On 12/12/08, David Pollak  wrote:
> Folks,
>
> Who has time to do testing, etc. with 2.7.3?
>
> Thanks,
>
> David
>
> -- Forwarded message --
> From: Philipp Haller 
> Date: Fri, Dec 12, 2008 at 6:42 AM
> Subject: Re: [scala-user] Is there a memory leak in 2.7.2 Actors?
> To: David Pollak 
> Cc: scala-user 
>
>
> Hi again,
>
> FYI, I committed a fix in r16750 (2.7.x branch) and r16751 (trunk). It
> looks like we are probably releasing 2.7.3 including this fix some time
> next week (or shortly after).
>
> Cheers,
> Philipp
>
>
> philipp.hal...@epfl.ch wrote:
>> Hi,
>>
>> I found the memory leak. A fix should be ready shortly.
>>
>> Cheers,
>> Philipp
>>
>>
>> Quoting David Pollak :
>>
>>> Folks,
>>>
>>> I've been noticing that Lift apps run out of memory after a certain
>>> period of time.  This is a relatively new thing.  I think I've
>>> traced the problem back to a memory leak in the Actors library.  The
>>>  enclosed program terminates with an out of memory error.
>>>
>>> Am I failing to release the Actors in some way or is there a memory leak?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> import scala.actors._
>>> import Actor._
>>>
>>> object ActorWatcher extends Actor {
>>>   def act = loop {
>>> react {
>>>   case Exit(actor: Actor, why: Throwable) =>
>>> failureFuncs.foreach(f => f(actor, why))
>>>   case x => println(x)
>>> }
>>>   }
>>>
>>>   private def startAgain(a: Actor, ignore: Throwable) {a.start}
>>>
>>>   private def logActorFailure(actor: Actor, why: Throwable) {
>>> println("The ActorWatcher restarted "+actor+" because "+why)
>>>   }
>>>
>>>   /**
>>>* If there's something to do in addition to starting the actor
>>> up, pre-pend the
>>>* actor to this List
>>>*/
>>>   var failureFuncs: List[(Actor, Throwable) => Unit] = logActorFailure _
> ::
>>>   startAgain _ :: Nil
>>>
>>>   this.start
>>>   this.trapExit = true
>>> }
>>>
>>> case object Start
>>> case object EndMe
>>>
>>> class A extends Actor {
>>> def act = loop {
>>> react {
>>> case Start =>
>>> link(ActorWatcher)
>>> case EndMe =>
>>> unlink(ActorWatcher)
>>> exit()
>>> }
>>> }
>>> }
>>>
>>> object Sloth {
>>> def z(in: Long) = if (in / 1024L == 0L) in
>>> else if (in / (1024L * 1024L) == 0L) (in / 1024L).toString + "K"
>>> else (in / (1024L * 1024L)).toString + "M"
>>> def main(args: Array[String]) {
>>> val rt = Runtime.getRuntime()
>>> for (o <- 1 to 100) {
>>> println("Outer "+o)
>>> //var a: List[Actor] = Nil
>>>  for (i <- 1 to 1) {
>>> val t = new A
>>> //a = t :: a
>>> t.start
>>> t ! Start
>>> t ! EndMe
>>> }
>>> println("Done creating")
>>> // for (act <- a) act ! EndMe
>>> ActorGC.gc()
>>> rt.gc()
>>> println("Free "+z(rt.freeMemory())+" total "+z(rt.totalMemory()))
>>> }
>>> }
>>> }
>>>
>>>
>>> --
>>> Lift, the simply functional web framework http://liftweb.net
>>> Collaborative Task Management http://much4.us
>>> Follow me: http://twitter.com/dpp
>>> Git some: http://github.com/dpp
>>>
>>
>>
>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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: Debugging CometActors?

[Jorge Ortiz]

Yeah, something like that :)

In the absence of props files, where does Log.error go? It's not showing up
in the console...

And even then, something is kinda funky. After my actor dies, ctrl-c won't
fully kill Jetty. I have to kill -9 it from another Terminal to make it
fully die.

--j

On Wed, Dec 10, 2008 at 9:40 PM, David Pollak <[EMAIL PROTECTED]
> wrote:

> You mean like:
>
> object ActorWatcher extends Actor {
>   def act = loop {
> react {
>   case Exit(actor: Actor, why: Throwable) =>
> failureFuncs.foreach(f => tryo(f(actor, why)))
>   case _ =>
> }
>   }
>
>   private def startAgain(a: Actor, ignore: Throwable) {a.start}
>
>   private def logActorFailure(actor: Actor, why: Throwable) {
> Log.error("The ActorWatcher restarted "+actor+" because "+why, why)
>   }
>
>   /**
>* If there's something to do in addition to starting the actor up,
> pre-pend the
>* actor to this List
>*/
>   var failureFuncs: List[(Actor, Throwable) => Unit] = logActorFailure _ ::
>   startAgain _ :: Nil
>
>   this.start
>   this.trapExit = true
> }
>
>
> Which CometActors link themselves to on startup?
>
> On Wed, Dec 10, 2008 at 7:32 PM, Jorge Ortiz <[EMAIL PROTECTED]>wrote:
>
>> Is there a good way to debug CometActors? Right now if a CometActor throws
>> an exception, it gets swallowed silently, kills the actor, and Lift hangs
>> waiting for a response from the now-dead actor until the timeout kicks in.
>>
>> If there aren't any debug mechanisms, are there any objections to me
>> committing some code that will catch exceptions thrown by the actor and
>> logging them for debugging purposes?
>>
>> --j
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Debugging CometActors?

[Jorge Ortiz]

Is there a good way to debug CometActors? Right now if a CometActor throws
an exception, it gets swallowed silently, kills the actor, and Lift hangs
waiting for a response from the now-dead actor until the timeout kicks in.

If there aren't any debug mechanisms, are there any objections to me
committing some code that will catch exceptions thrown by the actor and
logging them for debugging purposes?

--j

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: maven problem - can't make ToDo example work - or even get off the ground.

[Jorge Ortiz]

You need to cd into the project directory

  cd todo

--j

On Wed, Dec 10, 2008 at 5:30 PM, mike beckerle <[EMAIL PROTECTED]> wrote:

>
> Lifters,
>
> I tried to follow David Pollack's ToDo example to start trying out
> lift.
>
> It dies on me before we even get started. I am running maven 2.0.9 on
> Ubuntu.
>
> Any help resolving this greatly appreciated.
>
> The first big mvn command succeeds:
>
>  mvn archetype:create -U \
>  -DarchetypeGroupId=net.liftweb \
> -DarchetypeArtifactId=lift-archetype-basic \
> -DarchetypeVersion=0.10-SNAPSHOT \
> -DremoteRepositories=http://scala-tools.org/repo-snapshots \
> -DgroupId=com.liftworkshop -DartifactId=todo
>
> The next step fails:
>
> mvn jetty:run
>
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'jetty'.
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
> not exist or no valid version could be found
> [INFO]
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Tue Dec 09 18:54:24 EST 2008
> [INFO] Final Memory: 1M/4M
> [INFO]
> 
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: LiftRules consolidation

[Jorge Ortiz]

I would use a ListBuffer as the underlying representation. I would call the
methods "append" and "prepend" (LiftRules.snippet.append,
LiftRules.dispatch.append, etc.). I would also make them immutable
as-needed. ListBuffer caches toList so that it's very efficient if you don't
append/prepend in between calls to toList.

On Tue, Dec 9, 2008 at 2:20 PM, Marius <[EMAIL PROTECTED]> wrote:

>
> I'm not sure if this is the case ... if we want context dependent
> Snippets then probably using loc snippets is the right place
>
> How about something like:
>
> abstract class RulesSeq[T] {
>  var rules : List[T] = Nil
>
>  private def safe_?(f : => Any) {
>doneBoot match {
>  case false => f
>  case _ => throw new IllegalStateException("Can not modify after
> boot.");
>}
>  }
>
>  def prependRule(r: T) {
>safe_? {
>  rules = r :: rules
>}
>  }
>
>  def appendRule(r: T) {
>safe_? {
>  rules = rules ::: List(r)
>}
>  }
> }
>
> Br's,
> marius
>
> On Dec 9, 10:12 pm, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
> > Hm... I can think of situations where such mutations are useful after
> > Boot (app/prependSnippet comes to mind). Maybe they can be made immutable
> > (.toList) as necessary?
> >
> > --j
> >
> > On Tue, Dec 9, 2008 at 2:01 PM, David Pollak
> > <[EMAIL PROTECTED]>wrote:
> >
> > > And we should freeze the lists after Boot is finished.  The permutation
> > > methods should throw exceptions post-boot
> >
> > > On Dec 9, 2008 11:39 AM, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
> >
> > > Seems like prime opportunity for an abstraction...
> >
> > > Why not make them (*gasp*) mutable data structures with prepend/append
> > > methods?
> >
> > > --j
> >
> > > On Tue, Dec 9, 2008 at 1:35 PM, Marius <[EMAIL PROTECTED]>
> wrote: >
> > > > > Hi. > > Unfortunatel...
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: LiftRules consolidation

[Jorge Ortiz]

ListBuffer has constant time append and prepend methods, as well as constant
time toList. (Except after using toList, the next append/prepend will take
some work.)

--j

On Tue, Dec 9, 2008 at 2:09 PM, Marius <[EMAIL PROTECTED]> wrote:

>
> Sounds good. I'll look into it
>
>
> On Dec 9, 10:01 pm, "David Pollak" <[EMAIL PROTECTED]>
> wrote:
> > And we should freeze the lists after Boot is finished.  The permutation
> > methods should throw exceptions post-boot
> >
> > On Dec 9, 2008 11:39 AM, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
> >
> > Seems like prime opportunity for an abstraction...
> >
> > Why not make them (*gasp*) mutable data structures with prepend/append
> > methods?
> >
> > --j
> >
> > On Tue, Dec 9, 2008 at 1:35 PM, Marius <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi. > > Unfortunatel...
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: LiftRules consolidation

[Jorge Ortiz]

Hm... I can think of situations where such mutations are useful after
Boot (app/prependSnippet comes to mind). Maybe they can be made immutable
(.toList) as necessary?

--j

On Tue, Dec 9, 2008 at 2:01 PM, David Pollak
<[EMAIL PROTECTED]>wrote:

> And we should freeze the lists after Boot is finished.  The permutation
> methods should throw exceptions post-boot
>
> On Dec 9, 2008 11:39 AM, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
>
> Seems like prime opportunity for an abstraction...
>
> Why not make them (*gasp*) mutable data structures with prepend/append
> methods?
>
> --j
>
> On Tue, Dec 9, 2008 at 1:35 PM, Marius <[EMAIL PROTECTED]> wrote: >
> > > Hi. > > Unfortunatel...
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: LiftRules consolidation

[Jorge Ortiz]

Seems like prime opportunity for an abstraction...

Why not make them (*gasp*) mutable data structures with prepend/append
methods?

--j

On Tue, Dec 9, 2008 at 1:35 PM, Marius <[EMAIL PROTECTED]> wrote:

>
> Hi.
>
> Unfortunatelly only some vars that are essentially Lists of something
> are private and prepend/append functions are exposed.
>
> I proposed to do this for ALL List variables.
>
> Br's,
> Marius
> >
>

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

[Lift] Re: How does lift wrap the templates

[Jorge Ortiz]

Think of Either/Left/Right like you think of Option/Some/None or
Can/Full/Empty, except that Right doesn't have to be empty, it can carry
stuff with it.

(You can use Right to denote an error condition, like None or Empty, but you
don't have to.)

--j

On Sat, Dec 6, 2008 at 12:42 PM, Tim Perrett <[EMAIL PROTECTED]> wrote:

>
> A - thats some scala Voodoo - never seen the Either construct
> before!
>
> Thanks Jorge
>
> On Dec 6, 6:39 pm, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
> > Try:
> >
> >   case "badger" :: Nil => Left(() => demo)
> >
> > An Either[A, B] means it can be either a Left[A] or a Right[B].
> >
> > --j
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: How does lift wrap the templates

[Jorge Ortiz]

Try:

  case "badger" :: Nil => Left(() => demo)

An Either[A, B] means it can be either a Left[A] or a Right[B].

--j

On Sat, Dec 6, 2008 at 12:35 PM, Tim Perrett <[EMAIL PROTECTED]> wrote:

>
> Sorry, the code should have been:
>
> object ExampleLoader {
>  def template: LiftRules.ViewDispatchPF = {
> case "badger" :: Nil => () => demo
>  }
>
>  def demo: Can[NodeSeq] = Full()
>
> }
>
>
> [INFO]  found   : () => net.liftweb.util.Can[scala.xml.NodeSeq]
> [INFO]  required: Either[() => net.liftweb.util.Can
> [scala.xml.NodeSeq],net.liftweb.http.LiftView]
> [INFO] case "badger" :: Nil => () => demo
> [INFO]^
>
>
>
> Cheers, Tim
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Record small paradigm shift

[Jorge Ortiz]

I agree. Fields should be perfectly functional by just overriding members.
But it should be mentioned in docs, etc as Lift "best practices" to not add
methods or fields inside of Fields.

--j

On Tue, Dec 2, 2008 at 1:01 PM, Marius <[EMAIL PROTECTED]> wrote:

>
> Quite right ... still I don't quite see why someone would use a Field
> as structural type (.. or as anonymous instance) and define new -
> overridden functions and invoke them later. Field should only override
> functions  to adapt the behavior for the needed situation.
>
> Nevertheless it is a very good observation !
>
> Br's,
> Marius
>
> On Dec 2, 8:51 pm, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
> >   class Foo
> >
> >   // type is singleton type Bar.type
> >   object Bar extends Foo {
> > def exc = (new Exception).printStackTrace
> >   }
> >
> >   // type is structural type Foo{def exc: Unit}
> >   val Baz = new Foo {
> > def exc = (new Exception).printStackTrace
> >   }
> >
> >   // compare:
> >   Bar.exc
> >   Baz.exc
> >
> > Singleton types get their own .class file. Structural types use
> reflection.
> >
> > --j
> >
> > On Tue, Dec 2, 2008 at 12:33 PM, Alex Boisvert <[EMAIL PROTECTED]>
> wrote:
> > > On Tue, Dec 2, 2008 at 10:24 AM, Jorge Ortiz <[EMAIL PROTECTED]
> >wrote:
> >
> > >> If you add (non-overriden) fields to a val, they'll always be invoked
> via
> > >> reflection, which takes a performance hit. Objects, on the other hand,
> > >> define their own class so reflection isn't necessary.
> >
> > > Can you give an example?  I can't picture this from your description.
> >
> > > alex
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Record small paradigm shift

[Jorge Ortiz]

I guess that's a bit misleading. new Foo { ... } gets it's own .class file
too, but at the level of types, it doesn't get it's own type, hence the need
for reflection.

On Tue, Dec 2, 2008 at 12:51 PM, Jorge Ortiz <[EMAIL PROTECTED]> wrote:

>   class Foo
>
>   // type is singleton type Bar.type
>   object Bar extends Foo {
> def exc = (new Exception).printStackTrace
>   }
>
>   // type is structural type Foo{def exc: Unit}
>   val Baz = new Foo {
> def exc = (new Exception).printStackTrace
>   }
>
>   // compare:
>   Bar.exc
>   Baz.exc
>
> Singleton types get their own .class file. Structural types use reflection.
>
> --j
>
>
> On Tue, Dec 2, 2008 at 12:33 PM, Alex Boisvert <[EMAIL PROTECTED]>wrote:
>
>> On Tue, Dec 2, 2008 at 10:24 AM, Jorge Ortiz <[EMAIL PROTECTED]>wrote:
>>
>>> If you add (non-overriden) fields to a val, they'll always be invoked via
>>> reflection, which takes a performance hit. Objects, on the other hand,
>>> define their own class so reflection isn't necessary.
>>
>>
>> Can you give an example?  I can't picture this from your description.
>>
>> alex
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Record small paradigm shift

[Jorge Ortiz]

  class Foo

  // type is singleton type Bar.type
  object Bar extends Foo {
def exc = (new Exception).printStackTrace
  }

  // type is structural type Foo{def exc: Unit}
  val Baz = new Foo {
def exc = (new Exception).printStackTrace
  }

  // compare:
  Bar.exc
  Baz.exc

Singleton types get their own .class file. Structural types use reflection.

--j

On Tue, Dec 2, 2008 at 12:33 PM, Alex Boisvert <[EMAIL PROTECTED]> wrote:

> On Tue, Dec 2, 2008 at 10:24 AM, Jorge Ortiz <[EMAIL PROTECTED]>wrote:
>
>> If you add (non-overriden) fields to a val, they'll always be invoked via
>> reflection, which takes a performance hit. Objects, on the other hand,
>> define their own class so reflection isn't necessary.
>
>
> Can you give an example?  I can't picture this from your description.
>
> alex
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Record small paradigm shift

[Jorge Ortiz]

If you add (non-overriden) fields to a val, they'll always be invoked via
reflection, which takes a performance hit. Objects, on the other hand,
define their own class so reflection isn't necessary.

I don't expect this to be an issue in 99% of situations, but it's another
"gotcha" to be aware of.

--j

On Tue, Dec 2, 2008 at 12:07 PM, Marius <[EMAIL PROTECTED]> wrote:

>
> Hi all,
>
> I just committed some changes so that Record's fields are expressed as
> vals.
>
> For instance
>
> class MyRecord extends Record[MyRecord] {
>
>  def meta = MyRecordMeta
>
>  object firstName extends StringField(this, "John")
>
> }
>
> becomes
>
> class MyRecord extends Record[MyRecord] {
>
>  def meta = MyRecordMeta
>
>  val firstName = new StringField(this, "John")
>
> }
>
> ... a more  "classical" approach.
>
> If there are compelling reasons to use object instead of val please
> share them with us.
>
> P.S.
>
> If you want lifecycle callbacks you can say:
>
> class MyRecord extends Record[MyRecord] with LifecycleCallbacks {
>
>  def meta = MyRecordMeta
>
>  val firstName = new StringField(this, "John")
>
>  override def beforeValidation {
>println("Before validation")
>  }
>
>
> }
>
>
>
>
> Br's,
> Marius
> >
>

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

[Lift] Re: Compile problems with lift

[Jorge Ortiz]

It might be the type checker getting confused.

Try:

  val models: List[MetaMapper] = List(User, Game, GameUser, Hull, Ship,
StarSystem)

You can also call schemify with:

  Schemifier.schemify(true, Log.infoF _, models :_*)

Instead of the foreach stuff

--j

On Mon, Dec 1, 2008 at 3:44 PM, Juha L <[EMAIL PROTECTED]> wrote:

>
> I'm not sure whether it is just me, but I seem to be stumbling on the
> Scala compiler exceptions whatever I do. First there was one when
> creating specs that I mailed earlier, and now I get compile problems
> when I changed Boot-class.
>
> I have changed Boot-class as follows. Idea is to allow different
> database based on runlevel and also cleaning up the tables when doing
> tests. I have tried to change models to List[KeyedMapper[Any, Any]]
> but then I just get different set of exceptions. If I expand models by
> hand to schemify and cleanTables, it works just fine. Should I just
> send report to scala lang -list or am I doing something wrong?
>
> class Boot {
>  def database = ("org.apache.derby.jdbc.EmbeddedDriver",
> "jdbc:derby:liftdb_"+Props.mode.toString.toLowerCase+";create=true")
>
>  def dbVendor = new ConnectionManager {
>def newConnection(name: ConnectionIdentifier): Can[Connection] = {
>  try {
>val (driver, databaseString) = database
>Class.forName(driver)
>Full(DriverManager.getConnection(databaseString))
>  } catch {
>case e : Exception => e.printStackTrace; Empty
>  }
>}
>def releaseConnection(conn: Connection) {conn.close}
>  }
>
>  val models = List(User, Game, GameUser, Hull, Ship, StarSystem)
>
>  def schemify {
>models foreach {
>  m => Schemifier.schemify(true, Log.infoF _, m)
>}
>  }
>
>  def cleanTables {
>models foreach {
>  m => m.bulkDelete_!!()
>}
>  }
>
>  def boot {
>Log.info("Running boot at runmode "+ Props.mode)
>if (!DB.jndiJdbcConnAvailable_?) DB.defineConnectionManager
> (DefaultConnectionIdentifier, dbVendor)
>
>Props.mode match {
>  case Props.RunModes.Development =>
>schemify
>  case Props.RunModes.Test =>
>schemify
>cleanTables
>  case _ =>
>}
> ...
>
>
> I get this kind of stack trace:
>
> [WARNING] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [WARNING]   at scala.tools.nsc.util.HashSet.growTable
> (HashSet.scala:58)
> [WARNING]   at scala.tools.nsc.util.HashSet.addEntry(HashSet.scala:
> 41)
> [WARNING]   at scala.tools.nsc.symtab.Types$class.unique
> (Types.scala:2221)
> [WARNING]   at scala.tools.nsc.symtab.Types$class.mkThisType
> (Types.scala:1910)
> [WARNING]   at scala.tools.nsc.symtab.SymbolTable.mkThisType
> (SymbolTable.scala:12)
> [WARNING]   at scala.tools.nsc.symtab.Symbols$ClassSymbol.thisType
> (Symbols.scala:1540)
> [WARNING]   at scala.tools.nsc.symtab.Types$class.copyRefinedType
> (Types.scala:1986)
> [WARNING]   at scala.tools.nsc.symtab.SymbolTable.copyRefinedType
> (SymbolTable.scala:12)
> [WARNING]   at scala.tools.nsc.symtab.Types$TypeMap.mapOver
> (Types.scala:2324)
> [WARNING]   at scala.tools.nsc.symtab.Types$AsSeenFromMap.apply
> (Types.scala:2708)
> [WARNING]   at scala.tools.nsc.symtab.Types$AsSeenFromMap.apply
> (Types.scala:2575)
> [WARNING]   at scala.tools.nsc.symtab.Types$TypeMap.mapOver
> (Types.scala:2343)
> [WARNING]   at scala.tools.nsc.symtab.Types$AsSeenFromMap.apply
> (Types.scala:2708)
> [WARNING]   at scala.tools.nsc.symtab.Types$Type.asSeenFrom
> (Types.scala:399)
> [WARNING]   at scala.tools.nsc.symtab.Types$Type.memberType
> (Types.scala:429)
> [WARNING]   at scala.tools.nsc.symtab.Types$Type.findMember
> (Types.scala:696)
> [WARNING]   at scala.tools.nsc.symtab.Types$Type.nonPrivateMember
> (Types.scala:378)
> [WARNING]   at scala.tools.nsc.symtab.Types$$anonfun$29.apply
> (Types.scala:3984)
> [WARNING]   at scala.tools.nsc.symtab.Types$$anonfun$29.apply
> (Types.scala:3983)
> [WARNING]   at scala.List.map(List.scala:805)
> [WARNING]   at scala.tools.nsc.symtab.Types$class.lubsym$1
> (Types.scala:3983)
> [WARNING]   at scala.tools.nsc.symtab.Types$$anonfun$31.apply
> (Types.scala:4015)
> [WARNING]   at scala.tools.nsc.symtab.Types$$anonfun$31.apply
> (Types.scala:4010)
> [WARNING]   at scala.List.foreach(List.scala:834)
> [WARNING]   at scala.tools.nsc.symtab.Types$class.lub0$1
> (Types.scala:4010)
> [WARNING]   at scala.tools.nsc.symtab.Types$class.lub(Types.scala:
> 4034)
> [WARNING]   at scala.tools.nsc.symtab.SymbolTable.lub
> (SymbolTable.scala:12)
> [WARNING]   at scala.tools.nsc.symtab.Types$$anonfun$41.apply
> (Types.scala:4180)
> [WARNING]   at scala.tools.nsc.symtab.Types$$anonfun$41.apply
> (Types.scala:4171)
> [WARNING]   at scala.List$.map2(List.scala:326)
> [WARNING]   at scala.tools.nsc.symtab.Types
> $class.mergePrefixAndArgs(Types.scala:4170)
> [WARNING]   at
> scala.tools.nsc.symtab.Symb

[Lift] Re: JPA and Record

[Jorge Ortiz]

Just wanted to chime in real quick...


> type Getter = () => MyType // Can this be by-name in any way?
>

No. By-names are not first-class types. It's gotta be () => MyType

--j

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Upgrading to Manifest[C] from Class[C]

[Jorge Ortiz]

Oops... forgot I was working on a branch.

Pushed now.

--j

On Thu, Nov 27, 2008 at 11:38 PM, Marius <[EMAIL PROTECTED]> wrote:

>
> Nice ! ... is this committed anywhere?
>
> On Nov 28, 4:57 am, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
> > Folks,
> >
> > First, I've deprecated the containsClass method in ClassHelpers. It was
> only
> > being used once in the entire Lift codebase, and it was basically
> equivalent
> > to a very short call to List.exists. If you're using containsClass and
> have
> > some objection to using List.exists instead, let me know and I'll
> > undeprecate it, but otherwise I see no good reason to keep it around.
> >
> > Second, I've updated some of the stuff in net.liftweb.util to take
> advantage
> > of Scala's new Manifests, which provide a cleaner interface. The older
> > methods using Class[C] should still be there and work as they did before.
> >
> > For example, Cans have an "isA" method that takes a Class and returns a
> Full
> > can if the contents of the Can can be cast to that class, or Empty
> > otherwise. To illustrate:
> >
> >   abstract class Base
> >   case object Derived extends Base
> >   case object Incompatible extends Base
> >
> >   Ful(Derived).isA(classOf[Base]) // returns a Full[Base]
> >   Full(Derived).isA(classOf[Incompatible]) // returns an Empty
> >   Empty.isA(classOf[Base])  // returns Empty
> >
> > The new method is called "asA", and has a sligtly different (cleaner)
> > interface:
> >
> >   Full(Derived).asA[Base] // returns a Full[Base]
> >   Full(Derived).asA[Incompatible] // returns an Empty
> >   Empty.asA[Base] // returns an Empty
> >
> > Likewise, the findClass methods in ClassHelpers take a Class[C] to which
> the
> > found class must conform. There are now new findType methods which don't
> > require the Class[C], just a type annotation. So instead of:
> >
> >   findClass(name, where, classOf[CometActor])
> >
> > You can now do:
> >
> >   findType[CometActor](name, where)
> >
> > There were some methods private to Lift that I migrated as well, but
> those
> > shouldn't affect your apps.
> >
> > Thanks,
> >
> > --j
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Upgrading to Manifest[C] from Class[C]

[Jorge Ortiz]

Folks,

First, I've deprecated the containsClass method in ClassHelpers. It was only
being used once in the entire Lift codebase, and it was basically equivalent
to a very short call to List.exists. If you're using containsClass and have
some objection to using List.exists instead, let me know and I'll
undeprecate it, but otherwise I see no good reason to keep it around.

Second, I've updated some of the stuff in net.liftweb.util to take advantage
of Scala's new Manifests, which provide a cleaner interface. The older
methods using Class[C] should still be there and work as they did before.

For example, Cans have an "isA" method that takes a Class and returns a Full
can if the contents of the Can can be cast to that class, or Empty
otherwise. To illustrate:

  abstract class Base
  case object Derived extends Base
  case object Incompatible extends Base

  Ful(Derived).isA(classOf[Base]) // returns a Full[Base]
  Full(Derived).isA(classOf[Incompatible]) // returns an Empty
  Empty.isA(classOf[Base])  // returns Empty

The new method is called "asA", and has a sligtly different (cleaner)
interface:

  Full(Derived).asA[Base] // returns a Full[Base]
  Full(Derived).asA[Incompatible] // returns an Empty
  Empty.asA[Base] // returns an Empty

Likewise, the findClass methods in ClassHelpers take a Class[C] to which the
found class must conform. There are now new findType methods which don't
require the Class[C], just a type annotation. So instead of:

  findClass(name, where, classOf[CometActor])

You can now do:

  findType[CometActor](name, where)

There were some methods private to Lift that I migrated as well, but those
shouldn't affect your apps.

Thanks,

--j

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Testing for well-formed XML

[Jorge Ortiz]

Yeah, I'd love to make this a Maven build plugin. When it comes to Maven I'm
a total dunce though, but I'll look into it.

Any pointers on where to get started?

On Thu, Nov 27, 2008 at 3:59 AM, Josh Suereth <[EMAIL PROTECTED]>wrote:

> Hey, neat idea!   That will definitely help me avoid my own dumb errors.
>
> I'm just throwing this out there, but would it make sense to try to make
> this a Maven build plugin in the future?   That way you could control where
> it runs in the lifecycle if you wanted to.
>
> -Josh
>
>
> On Wed, Nov 26, 2008 at 8:07 PM, Jorge Ortiz <[EMAIL PROTECTED]>wrote:
>
>> Oops, it just test *.htm and *.xhtml files as well. Updated code below.
>>
>> --j
>>
>>   /**
>>* Tests to make sure the project's XML files are well-formed.
>>*
>>* Finds every *.html and *.xml file in src/main/webapp (and its
>>* subdirectories) and tests to make sure they are well-formed.
>>*/
>>   def testXml() = {
>> var failed: List[java.io.File] = Nil
>>
>> def handled(file: String) =
>>   file.endsWith(".html") || file.endsWith(".xml") ||
>>   file.endsWith(".htm")  || file.endsWith(".xhtml")
>>
>> def wellFormed(file: java.io.File) {
>>   if (file.isDirectory)
>> for (f <- file.listFiles) wellFormed(f)
>>
>>   if (file.isFile && handled(file.getName)) {
>> try {
>>   scala.xml.XML.loadFile(file)
>> } catch {
>>   case e: org.xml.sax.SAXParseException => failed = file :: failed
>> }
>>   }
>> }
>>
>> wellFormed(new java.io.File("src/main/webapp"))
>>
>> val numFails = failed.size
>> if (numFails > 0) {
>>   val fileStr = if (numFails == 1) "file" else "files"
>>   val msg = "Malformed XML in " + numFails + " " + fileStr + ": " +
>> failed.mkString(", ")
>>   println(msg)
>>   fail(msg)
>> }
>>   }
>>
>>
>> On Wed, Nov 26, 2008 at 4:58 PM, Jorge Ortiz <[EMAIL PROTECTED]>wrote:
>>
>>> Folks,
>>>
>>> One of the concerns raised at the Lift Workshop on Saturday was that
>>> ill-formed XML files in your templates will fail at run time instead of
>>> compile time, often with cryptic errors.
>>>
>>> To correct for this, I've added a simple test to lift-archetype-basic and
>>> lift-archetype-blank that will test all *.html and *.xml files in your
>>> src/main/webapp directory (and its subdirectories) to make sure they can all
>>> be loaded by Scala's XML parser. If they can't be loaded the test will fail
>>> and notify you which files couldn't be loaded and why.
>>>
>>> These tests run during Maven's 'test' phase. This phase is required
>>> before the 'package', 'install', or 'deploy' phases can run. Unfortunately,
>>> the 'jetty:run' phase only requires 'test-compile', not 'test'. If you want
>>> the test to run before starting Jetty, you'll have to specify it manually:
>>> 'mvn test jetty:run' (or 'mvn install jetty:run', etc).
>>>
>>> The test is available on any new projects created with Lift's archetypes.
>>> To add the test to your own project, the code is included below. It's a
>>> simple JUnit test. If you used a previous version of the archetypes to start
>>> your project, you can throw it into AppTest.scala
>>>
>>> Enjoy,
>>>
>>> --j
>>>
>>>
>>>   /**
>>>* Tests to make sure the project's XML files are well-formed.
>>>*
>>>* Finds every *.html and *.xml file in src/main/webapp (and its
>>>* subdirectories) and tests to make sure they are well-formed.
>>>*/
>>>   def testXml() = {
>>> var failed: List[java.io.File] = Nil
>>>
>>> def wellFormed(file: java.io.File) {
>>>   if (file.isDirectory)
>>> for (f <- file.listFiles) wellFormed(f)
>>>
>>>   if (file.isFile && (file.getName.endsWith(".html") ||
>>> file.getName.endsWith(".xml"))) {
>>> try {
>>>   scala.xml.XML.loadFile(file)
>>> } catch {
>>>   case e: org.xml.sax.SAXParseException => failed = file ::
>>> failed
>>> }
>>>   }
>>> }
>>>
>>> wellFormed(new java.io.File("src/main/webapp"))
>>>
>>> val numFails = failed.size
>>> if (numFails > 0) {
>>>   val fileStr = if (numFails == 1) "file" else "files"
>>>   val msg = "Malformed XML in " + numFails + " " + fileStr + ": " +
>>> failed.mkString(", ")
>>>   println(msg)
>>>   fail(msg)
>>> }
>>>   }
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Testing for well-formed XML

[Jorge Ortiz]

Oops, it just test *.htm and *.xhtml files as well. Updated code below.

--j

  /**
   * Tests to make sure the project's XML files are well-formed.
   *
   * Finds every *.html and *.xml file in src/main/webapp (and its
   * subdirectories) and tests to make sure they are well-formed.
   */
  def testXml() = {
var failed: List[java.io.File] = Nil

def handled(file: String) =
  file.endsWith(".html") || file.endsWith(".xml") ||
  file.endsWith(".htm")  || file.endsWith(".xhtml")

def wellFormed(file: java.io.File) {
  if (file.isDirectory)
for (f <- file.listFiles) wellFormed(f)

  if (file.isFile && handled(file.getName)) {
try {
  scala.xml.XML.loadFile(file)
} catch {
  case e: org.xml.sax.SAXParseException => failed = file :: failed
}
  }
}

wellFormed(new java.io.File("src/main/webapp"))

val numFails = failed.size
if (numFails > 0) {
  val fileStr = if (numFails == 1) "file" else "files"
  val msg = "Malformed XML in " + numFails + " " + fileStr + ": " +
failed.mkString(", ")
  println(msg)
  fail(msg)
}
  }


On Wed, Nov 26, 2008 at 4:58 PM, Jorge Ortiz <[EMAIL PROTECTED]> wrote:

> Folks,
>
> One of the concerns raised at the Lift Workshop on Saturday was that
> ill-formed XML files in your templates will fail at run time instead of
> compile time, often with cryptic errors.
>
> To correct for this, I've added a simple test to lift-archetype-basic and
> lift-archetype-blank that will test all *.html and *.xml files in your
> src/main/webapp directory (and its subdirectories) to make sure they can all
> be loaded by Scala's XML parser. If they can't be loaded the test will fail
> and notify you which files couldn't be loaded and why.
>
> These tests run during Maven's 'test' phase. This phase is required before
> the 'package', 'install', or 'deploy' phases can run. Unfortunately, the
> 'jetty:run' phase only requires 'test-compile', not 'test'. If you want the
> test to run before starting Jetty, you'll have to specify it manually: 'mvn
> test jetty:run' (or 'mvn install jetty:run', etc).
>
> The test is available on any new projects created with Lift's archetypes.
> To add the test to your own project, the code is included below. It's a
> simple JUnit test. If you used a previous version of the archetypes to start
> your project, you can throw it into AppTest.scala
>
> Enjoy,
>
> --j
>
>
>   /**
>* Tests to make sure the project's XML files are well-formed.
>*
>* Finds every *.html and *.xml file in src/main/webapp (and its
>* subdirectories) and tests to make sure they are well-formed.
>*/
>   def testXml() = {
> var failed: List[java.io.File] = Nil
>
> def wellFormed(file: java.io.File) {
>   if (file.isDirectory)
> for (f <- file.listFiles) wellFormed(f)
>
>   if (file.isFile && (file.getName.endsWith(".html") ||
> file.getName.endsWith(".xml"))) {
> try {
>   scala.xml.XML.loadFile(file)
> } catch {
>   case e: org.xml.sax.SAXParseException => failed = file :: failed
> }
>   }
> }
>
> wellFormed(new java.io.File("src/main/webapp"))
>
> val numFails = failed.size
> if (numFails > 0) {
>   val fileStr = if (numFails == 1) "file" else "files"
>   val msg = "Malformed XML in " + numFails + " " + fileStr + ": " +
> failed.mkString(", ")
>   println(msg)
>   fail(msg)
> }
>   }
>
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Testing for well-formed XML

[Jorge Ortiz]

Folks,

One of the concerns raised at the Lift Workshop on Saturday was that
ill-formed XML files in your templates will fail at run time instead of
compile time, often with cryptic errors.

To correct for this, I've added a simple test to lift-archetype-basic and
lift-archetype-blank that will test all *.html and *.xml files in your
src/main/webapp directory (and its subdirectories) to make sure they can all
be loaded by Scala's XML parser. If they can't be loaded the test will fail
and notify you which files couldn't be loaded and why.

These tests run during Maven's 'test' phase. This phase is required before
the 'package', 'install', or 'deploy' phases can run. Unfortunately, the
'jetty:run' phase only requires 'test-compile', not 'test'. If you want the
test to run before starting Jetty, you'll have to specify it manually: 'mvn
test jetty:run' (or 'mvn install jetty:run', etc).

The test is available on any new projects created with Lift's archetypes. To
add the test to your own project, the code is included below. It's a simple
JUnit test. If you used a previous version of the archetypes to start your
project, you can throw it into AppTest.scala

Enjoy,

--j


  /**
   * Tests to make sure the project's XML files are well-formed.
   *
   * Finds every *.html and *.xml file in src/main/webapp (and its
   * subdirectories) and tests to make sure they are well-formed.
   */
  def testXml() = {
var failed: List[java.io.File] = Nil

def wellFormed(file: java.io.File) {
  if (file.isDirectory)
for (f <- file.listFiles) wellFormed(f)

  if (file.isFile && (file.getName.endsWith(".html") ||
file.getName.endsWith(".xml"))) {
try {
  scala.xml.XML.loadFile(file)
} catch {
  case e: org.xml.sax.SAXParseException => failed = file :: failed
}
  }
}

wellFormed(new java.io.File("src/main/webapp"))

val numFails = failed.size
if (numFails > 0) {
  val fileStr = if (numFails == 1) "file" else "files"
  val msg = "Malformed XML in " + numFails + " " + fileStr + ": " +
failed.mkString(", ")
  println(msg)
  fail(msg)
}
  }

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: JsCmd

[Jorge Ortiz]

And David beat me to it... Oh well :)

On Tue, Nov 25, 2008 at 5:04 AM, Jorge Ortiz <[EMAIL PROTECTED]> wrote:

> You're almost there. The second parameter to ajaxCheckbox is a function
> that gets called on the server when the checkbox changes:
>
>   SHtml.ajaxCheckbox(thing.isActive, (toggled: Boolean) =>
> {thing.setActive(toggled); Noop})
>
> The Noop is needed because ajaxCheckbox expects a Boolean => JsCmd
> function. (I can't find a good reason for it needing a JsCmd though...
> Shouldn't it just be Boolean => Any or better yet Boolean => Unit?) Howver,
> you can replace "thing.setActive(toggled)" with whatever code you want to
> run when the checkbox is toggled. Here, "toggled" contains the state of the
> checkbox.
>
> Likewise ajaxSelect:
>
>   val daysOfWeek = List("Monday", "Tuesday", "Wednesday", "Thursday",
> "Friday",
> "Saturday", "Sunday").map(x => (x, x))
>   SHtml.ajaxSelect(daysOfWeek, Full("Monday"), (opt: String) =>
> {thing.setDayOfWeek(opt); Noop})
>
> The second parameter is the default value. The "opt" in the third parameter
> will correspond to the selected day.
>
> --j
>
>
> On Tue, Nov 25, 2008 at 4:11 AM, Charles F. Munat <[EMAIL PROTECTED]> wrote:
>
>>
>> I want to update an attribute on a model object in the database via AJAX
>> when a checkbox is clicked on a page. I presume that ajaxCheckbox is for
>> this purpose.
>>
>> Can anyone quickly give me an example of how it works?
>>
>> If I have an attribute called isActive, how would I create an
>> ajaxCheckbox that would call a method on the server when the checkbox is
>> clicked to set isActive to true or false, depending on the state of the
>> checkbox after the click?
>>
>> bind("mine", xhtml,
>>   "isActive" -> SHtml.ajaxCheckbox(thing.isActive, ???)
>>
>> What about selecting the day of the week from an ajaxSelect and updating
>> dayOfWeek. Or, finally, updating a text field on blur and setting the
>> user_name.
>>
>> Examples would really help.
>>
>> I am pretty desperate to have this done today, and several hours of
>> playing with various combinations has left me befuddled. Doesn't help
>> that it's 4 AM.
>>
>> Any and all help very greatly appreciated.
>>
>> Thanks,
>> Chas.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: JsCmd

[Jorge Ortiz]

You're almost there. The second parameter to ajaxCheckbox is a function that
gets called on the server when the checkbox changes:

  SHtml.ajaxCheckbox(thing.isActive, (toggled: Boolean) =>
{thing.setActive(toggled); Noop})

The Noop is needed because ajaxCheckbox expects a Boolean => JsCmd function.
(I can't find a good reason for it needing a JsCmd though... Shouldn't it
just be Boolean => Any or better yet Boolean => Unit?) Howver, you can
replace "thing.setActive(toggled)" with whatever code you want to run when
the checkbox is toggled. Here, "toggled" contains the state of the checkbox.

Likewise ajaxSelect:

  val daysOfWeek = List("Monday", "Tuesday", "Wednesday", "Thursday",
"Friday",
"Saturday", "Sunday").map(x => (x, x))
  SHtml.ajaxSelect(daysOfWeek, Full("Monday"), (opt: String) =>
{thing.setDayOfWeek(opt); Noop})

The second parameter is the default value. The "opt" in the third parameter
will correspond to the selected day.

--j

On Tue, Nov 25, 2008 at 4:11 AM, Charles F. Munat <[EMAIL PROTECTED]> wrote:

>
> I want to update an attribute on a model object in the database via AJAX
> when a checkbox is clicked on a page. I presume that ajaxCheckbox is for
> this purpose.
>
> Can anyone quickly give me an example of how it works?
>
> If I have an attribute called isActive, how would I create an
> ajaxCheckbox that would call a method on the server when the checkbox is
> clicked to set isActive to true or false, depending on the state of the
> checkbox after the click?
>
> bind("mine", xhtml,
>   "isActive" -> SHtml.ajaxCheckbox(thing.isActive, ???)
>
> What about selecting the day of the week from an ajaxSelect and updating
> dayOfWeek. Or, finally, updating a text field on blur and setting the
> user_name.
>
> Examples would really help.
>
> I am pretty desperate to have this done today, and several hours of
> playing with various combinations has left me befuddled. Doesn't help
> that it's 4 AM.
>
> Any and all help very greatly appreciated.
>
> Thanks,
> Chas.
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Error on compile with 2.7.2

[Jorge Ortiz]

Anytime the compiler throws an exception it's a bug and should be filed.

On Tue, Nov 18, 2008 at 3:23 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote:

>
> One would think so, and maybe it is, but the problem was actually caused
> by two errors in my code: a missing ) and then later an extra ) which
> turned what should have been a compile time error into a runtime error.
>
> That said, do you think there is a problem with the compiler?
>
> Chas.
>
> Jorge Ortiz wrote:
> > That's a bug in the Scala compiler.
> >
> > Try to comment out code and reduce the bug to it's minimal form to file
> > a bug report: http://lampsvn.epfl.ch/trac/scala/
> >
> > --j
> >
> > On Tue, Nov 18, 2008 at 2:44 PM, Charles F. Munat <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >
> > I changed the Scala version to 2.7.2, blew away .m2, did an mvn
> clean,
> > and I now get the error below when I try to compile. I note that none
> of
> > the files concerned are in my app, so I presume this is a Lift
> thing...
> >
> > Any ideas? I'll keep messing with it.
> >
> > [INFO] [compiler:compile]
> > [INFO] Nothing to compile - all classes are up to date
> > [INFO] [scala:compile {execution: default}]
> > [INFO] suggestion: remove the scalaVersion from pom.xml
> > [INFO] Compiling 28 source files to
> > /private/var/www/mine/mine-app/target/classes
> > [WARNING] Exception in thread "main"
> > java.lang.ArrayIndexOutOfBoundsException: 30
> > [WARNING]   at
> > scala.tools.nsc.ast.TreeGen.mkTuple(TreeGen.scala:227)
> > [WARNING]   at
> > scala.tools.nsc.typechecker.Infer$class.actualArgs(Infer.scala:62)
> > [WARNING]   at
> > scala.tools.nsc.Global$analyzer$.actualArgs(Global.scala:284)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer.doTypedApply(Typers.scala:1733)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$tryTypedApply$1$1.apply(Typers.scala:2566)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$tryTypedApply$1$1.apply(Typers.scala:2566)
> > [WARNING]   at
> > scala.tools.nsc.typechecker.Typers$Typer.silent(Typers.scala:588)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer.tryTypedApply$1(Typers.scala:2566)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer.typedApply$1(Typers.scala:2617)
> > [WARNING]   at
> > scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3219)
> > [WARNING]   at
> > scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3323)
> > [WARNING]   at
> > scala.tools.nsc.typechecker.Typers$Typer.typedArg(Typers.scala:1621)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer.typedArgToPoly$1(Typers.scala:1789)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$27.apply(Typers.scala:1798)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$27.apply(Typers.scala:1798)
> > [WARNING]   at scala.List$.map2(List.scala:326)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer.doTypedApply(Typers.scala:1798)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer.typedApply$1(Typers.scala:2619)
> > [WARNING]   at
> > scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3219)
> > [WARNING]   at
> > scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3323)
> > [WARNING]   at
> > scala.tools.nsc.typechecker.Typers$Typer.typedArg(Typers.scala:1621)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$typedArgs$1.apply(Typers.scala:1624)
> > [WARNING]   at
> >
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$typedArgs$1.apply(Typers.scala:1624)
> > [WARNING]   at scala.List$.loop$1(List.scala:293)
> > [WARNING]   at scala.List$.mapConserve(List.scala:310)
> > [WARNING]   at scala.List$.loop$1(List.scala:297)
> > [WARNING]   at scala.List$.mapConserve(List.scala:310)
> > [WARNING]   at scala.List$.loop$1(List.scala:297)
> > [WARNING]   at scala.List$.mapConserve(List.scala:310)
> > [WARNING]   at scala.List$.loop$1(List.scala:297)
> > [WARNING]   at scala.List

[Lift] Re: Error on compile with 2.7.2

[Jorge Ortiz]

That's a bug in the Scala compiler.

Try to comment out code and reduce the bug to it's minimal form to file a
bug report: http://lampsvn.epfl.ch/trac/scala/

--j

On Tue, Nov 18, 2008 at 2:44 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote:

>
> I changed the Scala version to 2.7.2, blew away .m2, did an mvn clean,
> and I now get the error below when I try to compile. I note that none of
> the files concerned are in my app, so I presume this is a Lift thing...
>
> Any ideas? I'll keep messing with it.
>
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [scala:compile {execution: default}]
> [INFO] suggestion: remove the scalaVersion from pom.xml
> [INFO] Compiling 28 source files to
> /private/var/www/mine/mine-app/target/classes
> [WARNING] Exception in thread "main"
> java.lang.ArrayIndexOutOfBoundsException: 30
> [WARNING]   at scala.tools.nsc.ast.TreeGen.mkTuple(TreeGen.scala:227)
> [WARNING]   at
> scala.tools.nsc.typechecker.Infer$class.actualArgs(Infer.scala:62)
> [WARNING]   at
> scala.tools.nsc.Global$analyzer$.actualArgs(Global.scala:284)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.doTypedApply(Typers.scala:1733)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$tryTypedApply$1$1.apply(Typers.scala:2566)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$tryTypedApply$1$1.apply(Typers.scala:2566)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.silent(Typers.scala:588)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.tryTypedApply$1(Typers.scala:2566)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typedApply$1(Typers.scala:2617)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3219)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3323)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typedArg(Typers.scala:1621)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer.typedArgToPoly$1(Typers.scala:1789)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$27.apply(Typers.scala:1798)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$27.apply(Typers.scala:1798)
> [WARNING]   at scala.List$.map2(List.scala:326)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.doTypedApply(Typers.scala:1798)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typedApply$1(Typers.scala:2619)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3219)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3323)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typedArg(Typers.scala:1621)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$typedArgs$1.apply(Typers.scala:1624)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$typedArgs$1.apply(Typers.scala:1624)
> [WARNING]   at scala.List$.loop$1(List.scala:293)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at scala.List$.loop$1(List.scala:297)
> [WARNING]   at scala.List$.mapConserve(List.scala:310)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.typedArgs(Typers.scala:1624)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.doTypedApply(Typers.scala:1727)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$tryTypedApply$1$1.apply(Typers.scala:2566)
> [WARNING]   at
>
> scala.tools.nsc.typechecker.Typers$Typer$$anonfun$tryTypedApply$1$1.apply(Typers.scala:2566)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.silent(Typers.scala:583)
> [WARNING]   at
> scala.tools.nsc.typechecker.Typers$Typer.tryTypedApply$1(Typers.scala:2566)
> [WARNING]   at
> scala.tools.nsc.ty

[Lift] Re: SHtml form inputs and attributes/labels

[Jorge Ortiz]

Oops, it might be:
SHtml.text(user.name, user.name = _) %
  ("size" -> "24") %
  ("maxlength" -> "48") %
  ("id" -> "user_name") %
  ("title" -> "Enter your name")

One or both of those should work.

--j

On Mon, Nov 17, 2008 at 12:27 PM, Jorge Ortiz <[EMAIL PROTECTED]> wrote:

> Try:
>
> SHtml.text(user.name, user.name = _) %
>   ("size", "24") %
>   ("maxlength", "48") %
>   ("id", "user_name") %
>   ("title", "Enter your name")
>
> That should work.
>
> --j
>
> On Mon, Nov 17, 2008 at 12:21 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote:
>
>>
>> I spend a lot of time writing % new UnprefixedAttribute(...) to add
>> attributes to SHtml form elements (input, textarea, select, etc.).
>>
>> It would be nice if the relevant SHtml methods would permit optional
>> extra parameters in the form of tuples where contents are name-value
>> pairs that get translated to attributes. I don't think this would be a
>> breaking change.
>>
>> In other words, instead of:
>>
>> SHtml.text(user.name, user.name = _) %
>>   new UnprefixedAttribute("size", "24",
>> new UnprefixedAttribute("maxlength", "48",
>>   new UnprefixedAttribute("id", "user_name",
>> new UnprefixedAttribute("title", "Enter your name", Null)
>>   )
>> )
>>   )
>>
>> I could do:
>>
>> SHtml.text(user.name, user.name = _,
>>   ("size", "24"),
>>   ("maxlength", "48"),
>>   ("id", "user_name"),
>>   ("title", "Enter your name")
>> )
>>
>> Which is a hell of a lot cleaner and faster, and I don't have to import
>> UnprefixedAttribute and remember the % and the new keywords.
>>
>> Or is this already possible and I'm missing it?
>>
>> I have an online survey with 43 questions on 5 pages involving more than
>> 150 database fields. The snippet is already over 700 lines and growing.
>> It's just unmanageable.
>>
>> Another thing: the  element is a very important part of
>> accessibility to persons with disabilities, but it needs a "for"
>> attribute that references the "id" attribute of the input element (or
>> textarea, etc.). The current SHtml output (unlike Rails) does not
>> generate an id attribute, so they have to be added by hand. Has anyone
>> given any thought to automatically-generated id elements on form fields?
>> Better yet, some way to integrate labels?
>>
>> Ideally, I would do something like this:
>>
>> 
>>
>> Or this:
>>
>> Your name
>>
>> and bind would allow me to generate this:
>>
>> Your name
>> 
>> 
>>
>> What do others think? Is this already possible?
>>
>> Chas.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---