[Lift] Re: LiftRules.logAndReturnExceptionToBrowser doesnt alway work

[Marius]

You already got good advices to your particular problem still an
exception thrown from LoanWrapper-s should be caught by and your
function called. I'll look into it tomorrow.


Br's,
Marius

On 18 Dec, 23:58, Oliver  wrote:
> I was redirecting to an error page using
> LiftRules.logAndReturnExceptionToBrowser, but when I use a LoanWrapper
> to close a EntityManager and an error occurs when closing the entity
> manager, LiftRules.logAndReturnExceptionToBrowser doesn't appear to
> redirect to my error page. Can anyone think of a work around?
>
>         // Output a simple error to the user. Link the error message
> to the screen via the current datetime
>         LiftRules.logAndReturnExceptionToBrowser = {
>                 RedirectResponse("/error);
>         }
>
>         // Set up a LoanWrapper to automatically close a EntityManager
> if its open
>         S.addAround(List(
>                 new LoanWrapper {
>                     def apply[T] (f : => T): T = {
>                         try {
>                             f
>                         } finally {
>                             EM.closeEM // close if open
>                         }
>                     }
>                 }))
>
>     }
--~--~-~--~~~---~--~~
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

[Josh Suereth]

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] Re: LiftRules.logAndReturnExceptionToBrowser doesnt alway work

[Derek Chen-Becker]

The big advantage would be in a situation where you want the transaction to
federate. For example, if you had multiple database connections, plus you
needed to connect to an EJB or Web Service and you wanted them all to be
part of the same transaction, JTA is the way to do it.

Derek

On Sat, Dec 20, 2008 at 3:54 PM, Oliver Lambert  wrote:

>
> What's the big advantage of using JTA over resource local transactions?
>
> On 21/12/2008, at 2:34 AM, Derek Chen-Becker wrote:
>
> Also, if you want lazy transactions it means you can't use JTA; as far as I
> know, a JTA-aware EM wants the transaction to already exist at the time that
> the EM is created. If that's not an issue and you're using resource local
> transactions, transactions are pretty inexpensive since they're essentially
> just turning off JDBC's autocommit.
>
>
> I'll have a look at the JPA demo code to see if anything is changed.
>
> On Sat, Dec 20, 2008 at 8:31 AM, Derek Chen-Becker 
> wrote:
>
>> I would suggest looking at the JPA demo code in liftweb under the sites
>> directory. The JPA.scala and Model.scala have some code in there for
>> handling transactions. There's also a wrapEM method that can help with
>> catching and handling exceptions. I have a branch underway that improves on
>> the code a bit (wip-dcb-jpa-jta), but I'm stuck at the moment because of a
>> weird issue with Jetty JNDI. I may end up just merging some of those changes
>> back into trunk since it looks like it may be a while before that's
>> resolved.
>>
>>
> >
>

--~--~-~--~~~---~--~~
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: LiftRules.logAndReturnExceptionToBrowser doesnt alway work

[Oliver Lambert]

What's the big advantage of using JTA over resource local transactions?

On 21/12/2008, at 2:34 AM, Derek Chen-Becker wrote:

> Also, if you want lazy transactions it means you can't use JTA; as  
> far as I know, a JTA-aware EM wants the transaction to already exist  
> at the time that the EM is created. If that's not an issue and  
> you're using resource local transactions, transactions are pretty  
> inexpensive since they're essentially just turning off JDBC's  
> autocommit.

I'll have a look at the JPA demo code to see if anything is changed.

> On Sat, Dec 20, 2008 at 8:31 AM, Derek Chen-Becker  > wrote:
> I would suggest looking at the JPA demo code in liftweb under the  
> sites directory. The JPA.scala and Model.scala have some code in  
> there for handling transactions. There's also a wrapEM method that  
> can help with catching and handling exceptions. I have a branch  
> underway that improves on the code a bit (wip-dcb-jpa-jta), but I'm  
> stuck at the moment because of a weird issue with Jetty JNDI. I may  
> end up just merging some of those changes back into trunk since it  
> looks like it may be a while before that's resolved.
>

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

[David Pollak]

It took me a long time to understand what an Option what.  Personally, Maybe
(Haskell) makes more sense to me.  Perpetuating Option as a name is, IMHO,
less than optimal.

On Sat, Dec 20, 2008 at 1:08 PM, David Bernard
wrote:

>
> If you want 3 letters "Opt" to show the relation with Option
> If you want less  "?" (question mark) but it's already used by
> i18n/resourses bundles (but it could be changed from ?("my sentence
> key") to $("my sentence key")). I'm haunted by Tony ;)
>
> my 2 cents useless contribution
>
>
> On Sat, Dec 20, 2008 at 21:49, Matt Harrington 
> wrote:
> >
> > On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir  wrote:
> >>
> >> Once people get Can, I think it makes sense, so I think we can leave
> >> it.
> >>
> >> As a replacement, I can't think of a good real-life example of a thing
> >> with a failure indicator that fits the bill. :)
> >>
> >> What about OptionWithFailure, OptionWF, OptWithF?
> >> It's more typing, but it's accurate.
> >>
> >> FailureIndicatingOption?  FIOption?
> >>
> >
> > These are pretty much my thoughts on the issue also.  I like
> > OptionWithFailure the best, but of the suggestions for very short
> > names, Can is a reasonable choice once you see an explanation.
> >
> > Matt
> >
> > >
> >
>
> >
>


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

[David Bernard]

If you want 3 letters "Opt" to show the relation with Option
If you want less  "?" (question mark) but it's already used by
i18n/resourses bundles (but it could be changed from ?("my sentence
key") to $("my sentence key")). I'm haunted by Tony ;)

my 2 cents useless contribution


On Sat, Dec 20, 2008 at 21:49, Matt Harrington  wrote:
>
> On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir  wrote:
>>
>> Once people get Can, I think it makes sense, so I think we can leave
>> it.
>>
>> As a replacement, I can't think of a good real-life example of a thing
>> with a failure indicator that fits the bill. :)
>>
>> What about OptionWithFailure, OptionWF, OptWithF?
>> It's more typing, but it's accurate.
>>
>> FailureIndicatingOption?  FIOption?
>>
>
> These are pretty much my thoughts on the issue also.  I like
> OptionWithFailure the best, but of the suggestions for very short
> names, Can is a reasonable choice once you see an explanation.
>
> 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: Can or Box or something else

[David Pollak]

If I had it to do over, I'd call it Box... but the cost of change seems to
outweigh the benefit of change... Can it is.
Thanks for your input.

On Sat, Dec 20, 2008 at 12:49 PM, Matt Harrington wrote:

>
> On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir  wrote:
> >
> > Once people get Can, I think it makes sense, so I think we can leave
> > it.
> >
> > As a replacement, I can't think of a good real-life example of a thing
> > with a failure indicator that fits the bill. :)
> >
> > What about OptionWithFailure, OptionWF, OptWithF?
> > It's more typing, but it's accurate.
> >
> > FailureIndicatingOption?  FIOption?
> >
>
> These are pretty much my thoughts on the issue also.  I like
> OptionWithFailure the best, but of the suggestions for very short
> names, Can is a reasonable choice once you see an explanation.
>
> Matt
>
> >
>


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

[Matt Harrington]

On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir  wrote:
>
> Once people get Can, I think it makes sense, so I think we can leave
> it.
>
> As a replacement, I can't think of a good real-life example of a thing
> with a failure indicator that fits the bill. :)
>
> What about OptionWithFailure, OptionWF, OptWithF?
> It's more typing, but it's accurate.
>
> FailureIndicatingOption?  FIOption?
>

These are pretty much my thoughts on the issue also.  I like
OptionWithFailure the best, but of the suggestions for very short
names, Can is a reasonable choice once you see an explanation.

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

[Oliver Lambert]

Perhaps we should rename Can to Option and get the Scala guys to  
rename theirs, OptionWithoutFailure :)

On 21/12/2008, at 6:50 AM, Charles F. Munat wrote:

> OptionWithFailure


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

[Charles F. Munat]

Generally, I agree, but not at the expense of understandability. And 
about the only time I have to type it is as a result type when it can't 
be inferred. The rest of the time I'm using Full() or Empty, which are 
nice and short. Even Box, which I think is much better, requires 
explaining. OptionWithFailure probably does not.

And with an IDE and code completion, it's not an issue. I'm more 
interested in reducing boilerplate than forcing type names to the 
shortest possible length.

Just my opinion...

Chas.

David Pollak wrote:
> Because Can is three letters and OptionPlus is 11 and a frequently used 
> construct should be easy on the fingers.
> 
> On Dec 20, 2008 11: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 u...
> 
> You received this message because you are subscribed to the Google
> Groups "Lift" group. To post to ...
> 
> 
> 
> > 

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

[Charles F. Munat]

I agree. I think Box is more cross-cultural and has no confusing 
meanings (e.g. can = possible). But Tyler makes a good point. Really, it 
should be called something like OptionWithFailure. And we should stop 
trying to abbreviate everything (*maybe* OptionWFailure). After all, how 
often do you actually write out "Can"? Usually it's Full() or Empty.

IMO, things should be self-explanatory and documentation should only be 
a fall back. It's generally a bad idea in my experience to rely on 
documentation.

Frankly, I, too, found Can quite confusing, even though I already knew 
what Option did.

Chas.

Marius wrote:
> Between Can, Cup and Box ...Box makes most sense to me ... (I'm not
> going to suggest Bottle :) ...)
> 
> Br's,
> Marius
> 
> On 20 Dec, 18:19, Tim Perrett  wrote:
>> Speaking from personal experience, what I didn't realize to begin with  
>> was that the can was what we in England call a tin, and the  
>> connotation of "you can do something" is conceptually very different  
>> to "a can (tin) contains x" if you follow my meaning...
>>
>> I think the problem can be solved by better docs, and a paper that  
>> explains the rational of can as a container - this would fix the curve  
>> of understanding IMO. What usually happens when noobies ask about can,  
>> is that people are pointed in the direction of Option, but if your new  
>> to scala, that is fairly meaningless also as those comming from java  
>> et al are using to checking for null so don't see why you need a  
>> container.
>>
>> Just my two pence
>>
>> Cheers, Tim
>>
>> Sent from my iPhone
>>
>> On 20 Dec 2008, at 14:43, "David Pollak"  
>>
>>  wrote:
>>> Folks,
>>> Over the year that Lift has had Can[T] as a replacement for Scala's  
>>> Option[T], the name "Can" has required a lot of explaining.
>>> As we make the final push into freezing Lift's APIs, do we want to  
>>> change the name of Can to something else or should we leave it as  
>>> Can.  Alternatives are:
>>> Cup
>>> Box
>>> Both of which can be Full/Empty.
>>> Thanks,
>>> David
>>> PS -- The Scala collections classes are getting a redo for 2.8.  
>>> I've been gently pestering Martin to expand Option to have a Failure  
>>> case.  If this happens (it's not really likely for a couple of  
>>> reasons), Can will be orphaned.
>>> --
>>> 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" 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

[Charles F. Munat]

Yes, but which is it: half empty or half full? You'd think at this stage 
of development we could at least answer that old question.

Chas.

Derek Chen-Becker wrote:
> What about renaming it Glass? Then we could add:
> 
> case class HalfFull[T](data : T) extends Glass[T]
> type HalfEmpty[T] = HalfFull[T]
> 
> ;)
> 
> Derek
> 
> On Sat, Dec 20, 2008 at 8:13 AM, TylerWeir  > wrote:
> 
> 
> Once people get Can, I think it makes sense, so I think we can leave
> it.
> 
> As a replacement, I can't think of a good real-life example of a thing
> with a failure indicator that fits the bill. :)
> 
> What about OptionWithFailure, OptionWF, OptWithF?
> It's more typing, but it's accurate.
> 
> FailureIndicatingOption?  FIOption?
> 
> 
> 
> On Dec 20, 9:43 am, "David Pollak"  >
> wrote:
>  > Folks,
>  >
>  > Over the year that Lift has had Can[T] as a replacement for Scala's
>  > Option[T], the name "Can" has required a lot of explaining.
>  >
>  > As we make the final push into freezing Lift's APIs, do we want
> to change
>  > the name of Can to something else or should we leave it as Can.
>  > Alternatives are:
>  >
>  >- Cup
>  >- Box
>  >
>  > Both of which can be Full/Empty.
>  >
>  > Thanks,
>  >
>  > David
>  >
>  > PS -- The Scala collections classes are getting a redo for 2.8.
>  I've been
>  > gently pestering Martin to expand Option to have a Failure case.
>  If this
>  > happens (it's not really likely for a couple of reasons), Can will be
>  > orphaned.
>  >
>  > --
>  > 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" 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

[Oliver Lambert]

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.

On 21/12/2008, at 6:25 AM, David Pollak wrote:

> Because Can is three letters and OptionPlus is 11 and a frequently  
> used construct should be easy on the fingers.
>
>
> On Dec 20, 2008 11: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 u...
>
> You received this message because you are subscribed to the Google  
> Groups "Lift" group. To post to ...
>
>
>
>
> >


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

[Alex Boisvert]

How about Result?  e.g. something like,

sealed trait Result[+T]
case class Expected(t: T) extends Result[T]
case class Failure[T](msg: String) extends Result[T]
case object Empty extends Result[Nothing]

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

[David Pollak]

Because Can is three letters and OptionPlus is 11 and a frequently used
construct should be easy on the fingers.

On Dec 20, 2008 11: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 u...

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

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

[Oliver Lambert]

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


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

[David Pollak]

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

--~--~-~--~~~---~--~~ You received this
message because you are subs...

--~--~-~--~~~---~--~~
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: url handling

[Oliver Lambert]

No, but as Derek suggests, it sounds a bit like the stateful snippet  
is doing it for me.

On 21/12/2008, at 5:31 AM, Marius wrote:

>
> Yeah but there are 2 overloaded versions. Are you also pasing a
> function to it?
>
> On 20 Dec, 14:31, Oliver Lambert  wrote:
>> Im using a net.liftweb.http.S.redirectTo within a stateful snippet.
>>
>> On 20/12/2008, at 9:40 PM, Marius wrote:
>>
>>
>>
>>> Looks like a function will be executed when this request is  
>>> submitted.
>>
>>> In what conditions are you seeing this? Are you calling S.redirectTo
>>> and pass a function? ... or use RedirectWithState?
>>
>>> Br's,
>>> Marius
>>
>>> On 20 Dec, 05:26, Oliver Lambert  wrote:
 Hi
>>
 I notice lift sometimes lift rewrites the url a little
 e.g. -  
 http://localhost:9090/enterbecomeshttp://localhost:9090/enter?fnVT32K 
 ...
>>
 What are the rules for when this happens?
 Is there anyway to write a lift application where it doesn't  
 happen?
>>
 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: Can or Box or something else

[Marius]

Can is more like Option but richer. Not much like Either.

On 20 Dec, 20:33, 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] as a replacement for Scala's  
> > Option[T], the name "Can" has required a lot of explaining.
>
> > As we make the final push into freezing Lift's APIs, do we want to  
> > change the name of Can to something else or should we leave it as  
> > Can.  Alternatives are:
> > Cup
> > Box
> > Both of which can be Full/Empty.
>
> > Thanks,
>
> > David
>
> > PS -- The Scala collections classes are getting a redo for 2.8.  
> > I've been gently pestering Martin to expand Option to have a Failure  
> > case.  If this happens (it's not really likely for a couple of  
> > reasons), Can will be orphaned.
>
> > --
> > 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" 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: url handling

[Oliver Lambert]

It sounds like the this version is firing. What should I be using?

On 21/12/2008, at 2:36 AM, Derek Chen-Becker wrote:

> Are you sure you're using S.redirectTo? For one, that's not what you  
> want if you want to keep using the same stateful snippet instance.  
> Second, if you're not calling it explicitly (i.e. using just  
> "redirectTo"), the "this" version of redirectTo on StatefulSnippet  
> may be firing.
>
> Derek
>
> On Sat, Dec 20, 2008 at 5:36 AM, Oliver Lambert   
> wrote:
>
> Simple, I would like my url to be called without ?... tacked onto the
> end.
>
> On 20/12/2008, at 10:40 PM, Tim Perrett wrote:
>
> >
> > Oliver,
> >
> > Lift will only create these types of URL when you pass params when
> > creating a link.
> >
> > There is a very sophisticated rewriting engine in lift, so a better
> > question would be what do you want your URL to look like?
> >
> > Thanks, Tim
> >
> > Sent from my iPhone
> >
> > On 20 Dec 2008, at 03:26, Oliver Lambert  wrote:
> >
> >>
> >> Hi
> >>
> >> I notice lift sometimes lift rewrites the url a little
> >>   e.g. -  http://localhost:9090/enter becomes 
> >> http://localhost:9090/enter?fnVT32KHAJRTHI5RNQ2XBY=_
> >>
> >> What are the rules for when this happens?
> >> Is there anyway to write a lift application where it doesn't  
> happen?
> >>
> >> 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] Can or Box or something else

[Oliver Lambert]

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] as a replacement for Scala's  
> Option[T], the name "Can" has required a lot of explaining.
>
> As we make the final push into freezing Lift's APIs, do we want to  
> change the name of Can to something else or should we leave it as  
> Can.  Alternatives are:
> Cup
> Box
> Both of which can be Full/Empty.
>
> Thanks,
>
> David
>
> PS -- The Scala collections classes are getting a redo for 2.8.   
> I've been gently pestering Martin to expand Option to have a Failure  
> case.  If this happens (it's not really likely for a couple of  
> reasons), Can will be orphaned.
>
> -- 
> 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: url handling

[Marius]

Yeah but there are 2 overloaded versions. Are you also pasing a
function to it?

On 20 Dec, 14:31, Oliver Lambert  wrote:
> Im using a net.liftweb.http.S.redirectTo within a stateful snippet.
>
> On 20/12/2008, at 9:40 PM, Marius wrote:
>
>
>
> > Looks like a function will be executed when this request is submitted.
>
> > In what conditions are you seeing this? Are you calling S.redirectTo
> > and pass a function? ... or use RedirectWithState?
>
> > Br's,
> > Marius
>
> > On 20 Dec, 05:26, Oliver Lambert  wrote:
> >> Hi
>
> >> I notice lift sometimes lift rewrites the url a little
> >>     e.g. -  
> >> http://localhost:9090/enterbecomeshttp://localhost:9090/enter?fnVT32K...
>
> >> What are the rules for when this happens?
> >> Is there anyway to write a lift application where it doesn't happen?
>
> >> 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: Can or Box or something else

[Marius]

Between Can, Cup and Box ...Box makes most sense to me ... (I'm not
going to suggest Bottle :) ...)

Br's,
Marius

On 20 Dec, 18:19, Tim Perrett  wrote:
> Speaking from personal experience, what I didn't realize to begin with  
> was that the can was what we in England call a tin, and the  
> connotation of "you can do something" is conceptually very different  
> to "a can (tin) contains x" if you follow my meaning...
>
> I think the problem can be solved by better docs, and a paper that  
> explains the rational of can as a container - this would fix the curve  
> of understanding IMO. What usually happens when noobies ask about can,  
> is that people are pointed in the direction of Option, but if your new  
> to scala, that is fairly meaningless also as those comming from java  
> et al are using to checking for null so don't see why you need a  
> container.
>
> Just my two pence
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 20 Dec 2008, at 14:43, "David Pollak"  
>
>  wrote:
> > Folks,
>
> > Over the year that Lift has had Can[T] as a replacement for Scala's  
> > Option[T], the name "Can" has required a lot of explaining.
>
> > As we make the final push into freezing Lift's APIs, do we want to  
> > change the name of Can to something else or should we leave it as  
> > Can.  Alternatives are:
> > Cup
> > Box
> > Both of which can be Full/Empty.
>
> > Thanks,
>
> > David
>
> > PS -- The Scala collections classes are getting a redo for 2.8.  
> > I've been gently pestering Martin to expand Option to have a Failure  
> > case.  If this happens (it's not really likely for a couple of  
> > reasons), Can will be orphaned.
>
> > --
> > 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" 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] JQuery UI Tabs : JqJE.JqTabs ?

[Joachim A.]

Hi,
I'd like to construct JQuery ui tabs in a snippet.

Does anybody know what the JqJE.JqTabs* object are supposed to do?

After reading the source code I think it's to construct expressions to work 
with tabs. But it's still unclear to me if this is for the JQuery ui tabs and 
if there's a Lift way to create the xhtml for those tabs.

I couldn't find a reference to these methods in the whole Lift code ...

Thanks a lot,
Joachim


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

[Tim Perrett]

Speaking from personal experience, what I didn't realize to begin with  
was that the can was what we in England call a tin, and the  
connotation of "you can do something" is conceptually very different  
to "a can (tin) contains x" if you follow my meaning...

I think the problem can be solved by better docs, and a paper that  
explains the rational of can as a container - this would fix the curve  
of understanding IMO. What usually happens when noobies ask about can,  
is that people are pointed in the direction of Option, but if your new  
to scala, that is fairly meaningless also as those comming from java  
et al are using to checking for null so don't see why you need a  
container.

Just my two pence

Cheers, Tim

Sent from my iPhone

On 20 Dec 2008, at 14:43, "David Pollak"  
 wrote:

> Folks,
>
> Over the year that Lift has had Can[T] as a replacement for Scala's  
> Option[T], the name "Can" has required a lot of explaining.
>
> As we make the final push into freezing Lift's APIs, do we want to  
> change the name of Can to something else or should we leave it as  
> Can.  Alternatives are:
> Cup
> Box
> Both of which can be Full/Empty.
>
> Thanks,
>
> David
>
> PS -- The Scala collections classes are getting a redo for 2.8.   
> I've been gently pestering Martin to expand Option to have a Failure  
> case.  If this happens (it's not really likely for a couple of  
> reasons), Can will be orphaned.
>
> -- 
> 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

[David Pollak]

Funny boy.  :-)

On Dec 20, 2008 7:39 AM, "Derek Chen-Becker"  wrote:

What about renaming it Glass? Then we could add:

case class HalfFull[T](data : T) extends Glass[T]
type HalfEmpty[T] = HalfFull[T]

;)

Derek

On Sat, Dec 20, 2008 at 8:13 AM, TylerWeir  wrote: > >
> Once people get Can...

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

[Derek Chen-Becker]

What about renaming it Glass? Then we could add:

case class HalfFull[T](data : T) extends Glass[T]
type HalfEmpty[T] = HalfFull[T]

;)

Derek

On Sat, Dec 20, 2008 at 8:13 AM, TylerWeir  wrote:

>
> Once people get Can, I think it makes sense, so I think we can leave
> it.
>
> As a replacement, I can't think of a good real-life example of a thing
> with a failure indicator that fits the bill. :)
>
> What about OptionWithFailure, OptionWF, OptWithF?
> It's more typing, but it's accurate.
>
> FailureIndicatingOption?  FIOption?
>
>
>
> On Dec 20, 9:43 am, "David Pollak" 
> wrote:
> > Folks,
> >
> > Over the year that Lift has had Can[T] as a replacement for Scala's
> > Option[T], the name "Can" has required a lot of explaining.
> >
> > As we make the final push into freezing Lift's APIs, do we want to change
> > the name of Can to something else or should we leave it as Can.
> > Alternatives are:
> >
> >- Cup
> >- Box
> >
> > Both of which can be Full/Empty.
> >
> > Thanks,
> >
> > David
> >
> > PS -- The Scala collections classes are getting a redo for 2.8.  I've
> been
> > gently pestering Martin to expand Option to have a Failure case.  If this
> > happens (it's not really likely for a couple of reasons), Can will be
> > orphaned.
> >
> > --
> > 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" 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: url handling

[Derek Chen-Becker]

Are you sure you're using S.redirectTo? For one, that's not what you want if
you want to keep using the same stateful snippet instance. Second, if you're
not calling it explicitly (i.e. using just "redirectTo"), the "this" version
of redirectTo on StatefulSnippet may be firing.

Derek

On Sat, Dec 20, 2008 at 5:36 AM, Oliver Lambert  wrote:

>
> Simple, I would like my url to be called without ?... tacked onto the
> end.
>
> On 20/12/2008, at 10:40 PM, Tim Perrett wrote:
>
> >
> > Oliver,
> >
> > Lift will only create these types of URL when you pass params when
> > creating a link.
> >
> > There is a very sophisticated rewriting engine in lift, so a better
> > question would be what do you want your URL to look like?
> >
> > Thanks, Tim
> >
> > Sent from my iPhone
> >
> > On 20 Dec 2008, at 03:26, Oliver Lambert  wrote:
> >
> >>
> >> Hi
> >>
> >> I notice lift sometimes lift rewrites the url a little
> >>   e.g. -  http://localhost:9090/enter becomes
> http://localhost:9090/enter?fnVT32KHAJRTHI5RNQ2XBY=_
> >>
> >> What are the rules for when this happens?
> >> Is there anyway to write a lift application where it doesn't happen?
> >>
> >> 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: LiftRules.logAndReturnExceptionToBrowser doesnt alway work

[Derek Chen-Becker]

Also, if you want lazy transactions it means you can't use JTA; as far as I
know, a JTA-aware EM wants the transaction to already exist at the time that
the EM is created. If that's not an issue and you're using resource local
transactions, transactions are pretty inexpensive since they're essentially
just turning off JDBC's autocommit.

Derek

On Sat, Dec 20, 2008 at 8:31 AM, Derek Chen-Becker wrote:

> I would suggest looking at the JPA demo code in liftweb under the sites
> directory. The JPA.scala and Model.scala have some code in there for
> handling transactions. There's also a wrapEM method that can help with
> catching and handling exceptions. I have a branch underway that improves on
> the code a bit (wip-dcb-jpa-jta), but I'm stuck at the moment because of a
> weird issue with Jetty JNDI. I may end up just merging some of those changes
> back into trunk since it looks like it may be a while before that's
> resolved.
>
> Derek
>
>
> On Fri, Dec 19, 2008 at 8:13 PM, Oliver Lambert  wrote:
>
>> Ha, very observant - I am relying on it to commit or rollback or do
>> nothing.
>>  I note your recommendation, but I'd rather not have transaction support
>> code littered around.
>> For my application, I want a transaction lazily created  and closed after
>> each request, if it was created.
>> If what I am doing is bad design or coding, Im willing to change it.
>>
>> Oliver
>>
>> On 20/12/2008, at 1:12 AM, Derek Chen-Becker wrote:
>>
>> What kind of error are you getting when the EM closes? As long as you're
>> not relying on the EM.close to commit your transaction (something I'd
>> recommend against anyway) then there really shouldn't be any errors at this
>> point.
>>
>> Derek
>>
>> On Thu, Dec 18, 2008 at 10:00 PM, Oliver  wrote:
>>
>>>
>>> I started on that path, and thought I could redirect with something like
>>>   Full( "some html that redirects to the error page"...
>>> ).asInstanceOf[T]
>>> It feels like a big hack, even if I could get it working and I was a
>>> little worried about creating
>>> a redirection loop.
>>> I've created a static html error page and call it from web.xml for now
>>> - it'll have to do for now.
>>>
>>> On Fri, Dec 19, 2008 at 11:09 AM, David Pollak
>>>  wrote:
>>> > I'd put a try/finally around the EM.closeEM call so that it does not
>>> impact
>>> > the stuff that's being rendered to the browser.  Don't let the
>>> exception in
>>> > the finally block propogate.
>>> >
>>> > On Thu, Dec 18, 2008 at 1:58 PM, Oliver  wrote:
>>> >>
>>> >> I was redirecting to an error page using
>>> >> LiftRules.logAndReturnExceptionToBrowser, but when I use a LoanWrapper
>>> >> to close a EntityManager and an error occurs when closing the entity
>>> >> manager, LiftRules.logAndReturnExceptionToBrowser doesn't appear to
>>> >> redirect to my error page. Can anyone think of a work around?
>>> >>
>>> >>
>>> >>// Output a simple error to the user. Link the error message
>>> >> to the screen via the current datetime
>>> >>LiftRules.logAndReturnExceptionToBrowser = {
>>> >>RedirectResponse("/error);
>>> >>}
>>> >>
>>> >>// Set up a LoanWrapper to automatically close a EntityManager
>>> >> if its open
>>> >>S.addAround(List(
>>> >>new LoanWrapper {
>>> >>def apply[T] (f : => T): T = {
>>> >>try {
>>> >>f
>>> >>} finally {
>>> >>EM.closeEM // close if open
>>> >>}
>>> >>}
>>> >>}))
>>> >>
>>> >>}
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > 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: LiftRules.logAndReturnExceptionToBrowser doesnt alway work

[Derek Chen-Becker]

I would suggest looking at the JPA demo code in liftweb under the sites
directory. The JPA.scala and Model.scala have some code in there for
handling transactions. There's also a wrapEM method that can help with
catching and handling exceptions. I have a branch underway that improves on
the code a bit (wip-dcb-jpa-jta), but I'm stuck at the moment because of a
weird issue with Jetty JNDI. I may end up just merging some of those changes
back into trunk since it looks like it may be a while before that's
resolved.

Derek

On Fri, Dec 19, 2008 at 8:13 PM, Oliver Lambert  wrote:

> Ha, very observant - I am relying on it to commit or rollback or do
> nothing.
>  I note your recommendation, but I'd rather not have transaction support
> code littered around.
> For my application, I want a transaction lazily created  and closed after
> each request, if it was created.
> If what I am doing is bad design or coding, Im willing to change it.
>
> Oliver
>
> On 20/12/2008, at 1:12 AM, Derek Chen-Becker wrote:
>
> What kind of error are you getting when the EM closes? As long as you're
> not relying on the EM.close to commit your transaction (something I'd
> recommend against anyway) then there really shouldn't be any errors at this
> point.
>
> Derek
>
> On Thu, Dec 18, 2008 at 10:00 PM, Oliver  wrote:
>
>>
>> I started on that path, and thought I could redirect with something like
>>   Full( "some html that redirects to the error page"...
>> ).asInstanceOf[T]
>> It feels like a big hack, even if I could get it working and I was a
>> little worried about creating
>> a redirection loop.
>> I've created a static html error page and call it from web.xml for now
>> - it'll have to do for now.
>>
>> On Fri, Dec 19, 2008 at 11:09 AM, David Pollak
>>  wrote:
>> > I'd put a try/finally around the EM.closeEM call so that it does not
>> impact
>> > the stuff that's being rendered to the browser.  Don't let the exception
>> in
>> > the finally block propogate.
>> >
>> > On Thu, Dec 18, 2008 at 1:58 PM, Oliver  wrote:
>> >>
>> >> I was redirecting to an error page using
>> >> LiftRules.logAndReturnExceptionToBrowser, but when I use a LoanWrapper
>> >> to close a EntityManager and an error occurs when closing the entity
>> >> manager, LiftRules.logAndReturnExceptionToBrowser doesn't appear to
>> >> redirect to my error page. Can anyone think of a work around?
>> >>
>> >>
>> >>// Output a simple error to the user. Link the error message
>> >> to the screen via the current datetime
>> >>LiftRules.logAndReturnExceptionToBrowser = {
>> >>RedirectResponse("/error);
>> >>}
>> >>
>> >>// Set up a LoanWrapper to automatically close a EntityManager
>> >> if its open
>> >>S.addAround(List(
>> >>new LoanWrapper {
>> >>def apply[T] (f : => T): T = {
>> >>try {
>> >>f
>> >>} finally {
>> >>EM.closeEM // close if open
>> >>}
>> >>}
>> >>}))
>> >>
>> >>}
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > 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

[TylerWeir]

Once people get Can, I think it makes sense, so I think we can leave
it.

As a replacement, I can't think of a good real-life example of a thing
with a failure indicator that fits the bill. :)

What about OptionWithFailure, OptionWF, OptWithF?
It's more typing, but it's accurate.

FailureIndicatingOption?  FIOption?



On Dec 20, 9:43 am, "David Pollak" 
wrote:
> Folks,
>
> Over the year that Lift has had Can[T] as a replacement for Scala's
> Option[T], the name "Can" has required a lot of explaining.
>
> As we make the final push into freezing Lift's APIs, do we want to change
> the name of Can to something else or should we leave it as Can.
> Alternatives are:
>
>    - Cup
>    - Box
>
> Both of which can be Full/Empty.
>
> Thanks,
>
> David
>
> PS -- The Scala collections classes are getting a redo for 2.8.  I've been
> gently pestering Martin to expand Option to have a Failure case.  If this
> happens (it's not really likely for a couple of reasons), Can will be
> orphaned.
>
> --
> 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" 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] Can or Box or something else

[David Pollak]

Folks,

Over the year that Lift has had Can[T] as a replacement for Scala's
Option[T], the name "Can" has required a lot of explaining.

As we make the final push into freezing Lift's APIs, do we want to change
the name of Can to something else or should we leave it as Can.
Alternatives are:

   - Cup
   - Box

Both of which can be Full/Empty.

Thanks,

David

PS -- The Scala collections classes are getting a redo for 2.8.  I've been
gently pestering Martin to expand Option to have a Failure case.  If this
happens (it's not really likely for a couple of reasons), Can will be
orphaned.

-- 
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: url handling

[Oliver Lambert]

Simple, I would like my url to be called without ?... tacked onto the  
end.

On 20/12/2008, at 10:40 PM, Tim Perrett wrote:

>
> Oliver,
>
> Lift will only create these types of URL when you pass params when
> creating a link.
>
> There is a very sophisticated rewriting engine in lift, so a better
> question would be what do you want your URL to look like?
>
> Thanks, Tim
>
> Sent from my iPhone
>
> On 20 Dec 2008, at 03:26, Oliver Lambert  wrote:
>
>>
>> Hi
>>
>> I notice lift sometimes lift rewrites the url a little
>>   e.g. -  http://localhost:9090/enter becomes 
>> http://localhost:9090/enter?fnVT32KHAJRTHI5RNQ2XBY=_
>>
>> What are the rules for when this happens?
>> Is there anyway to write a lift application where it doesn't happen?
>>
>> 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: url handling

[Oliver Lambert]

Im using a net.liftweb.http.S.redirectTo within a stateful snippet.

On 20/12/2008, at 9:40 PM, Marius wrote:

>
> Looks like a function will be executed when this request is submitted.
>
> In what conditions are you seeing this? Are you calling S.redirectTo
> and pass a function? ... or use RedirectWithState?
>
> Br's,
> Marius
>
> On 20 Dec, 05:26, Oliver Lambert  wrote:
>> Hi
>>
>> I notice lift sometimes lift rewrites the url a little
>> e.g. -  
>> http://localhost:9090/enterbecomeshttp://localhost:9090/enter?fnVT32KHAJRTHI5RNQ2XBY=_
>>
>> What are the rules for when this happens?
>> Is there anyway to write a lift application where it doesn't happen?
>>
>> 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: url handling

[Tim Perrett]

Oliver,

Lift will only create these types of URL when you pass params when  
creating a link.

There is a very sophisticated rewriting engine in lift, so a better  
question would be what do you want your URL to look like?

Thanks, Tim

Sent from my iPhone

On 20 Dec 2008, at 03:26, Oliver Lambert  wrote:

>
> Hi
>
> I notice lift sometimes lift rewrites the url a little
>e.g. -  http://localhost:9090/enter becomes 
> http://localhost:9090/enter?fnVT32KHAJRTHI5RNQ2XBY=_
>
> What are the rules for when this happens?
> Is there anyway to write a lift application where it doesn't happen?
>
> 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: url handling

[Marius]

Looks like a function will be executed when this request is submitted.

In what conditions are you seeing this? Are you calling S.redirectTo
and pass a function? ... or use RedirectWithState?

Br's,
Marius

On 20 Dec, 05:26, Oliver Lambert  wrote:
> Hi
>
> I notice lift sometimes lift rewrites the url a little
>     e.g. -  
> http://localhost:9090/enterbecomeshttp://localhost:9090/enter?fnVT32KHAJRTHI5RNQ2XBY=_
>
> What are the rules for when this happens?
> Is there anyway to write a lift application where it doesn't happen?
>
> 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
-~--~~~~--~~--~--~---