[Lift] Re: HTTP Client?
Is there a way to set the authToken in the instance rather than
globally?
On Sep 23, 12:29 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
> Hey guys,
>
> Ok, i've abstracted it all out into a class which you call a little
> like this:
>
> var paypal: PayPal = new PayPal("sandbox")
> paypal.transactionToken = S.param("tx").openOr("")
> paypal.execute("pdt")
>
> And as your authentication token is global to your account, you can
> specify it by doing:
>
> PayPal.authenticationToken = "dfgdfgdfgdfgdfgdfgd"
>
> which I palced in boot. So far i've only implemented PDT, but have
> allowed for implementing IPN too - which should be a minimal amount of
> work ontop of what i already have.
>
> Thoughts?
>
> 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: HTTP Client?
Yea i'll probably make it the constructor - seems a bit more logical. My plan is to implement IPN, then roll up the IPN and PDT stuff into a maven module and release it Cheers Tim On Oct 1, 5:45 pm, jon <[EMAIL PROTECTED]> wrote: > Is there a way to set the authToken in the instance rather than > globally? --~--~-~--~~~---~--~~ 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: HTTP Client?
On Mon, Sep 29, 2008 at 4:07 PM, Tim Perrett <[EMAIL PROTECTED]> wrote: > > > > Do you mean PayPal's servers make an HTTP request on your server? > > > > Or do you mean that the user's browser is redirected from PayPal's site > to > > your site? > > Of course - PayPal makes a post to our server with all the transaction > information. This is the PayPal IPN system :) Okay... my mistake. Yes, you have to set this up in Boot with a DispatchPf to handle the incoming request. > > > Cheers > > Tim > > > -- 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] Re: HTTP Client?
> Okay... my mistake. Yes, you have to set this up in Boot with a DispatchPf > to handle the incoming request. Thats what I thought - this is why I was asking about ajax_request :-) Do my previous ramblings make any more sense now? 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: HTTP Client?
> Do you mean PayPal's servers make an HTTP request on your server? > > Or do you mean that the user's browser is redirected from PayPal's site to > your site? Of course - PayPal makes a post to our server with all the transaction information. This is the PayPal IPN system :) 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: HTTP Client?
On Mon, Sep 29, 2008 at 3:52 PM, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > Hmmm... I may be misunderstanding what you're saying... but...
> >
> > In the PayPal landing, I'd update the user's state (e.g., credit their
> > account), add something to S.notices and then redirect the browser to
> either
> > "/" or some other page. So, no HTML required on the landing page. Also,
> > this is specific to the PayPal stuff so it shouldn't be referenced in
> Boot.
>
> I think im not being clear. Let me clarify:
>
> When the request comes in from paypal, I want to process that request,
> get the various parameters and then provide some way for the user to
> use those values to do whatever post-processing they require.
Do you mean PayPal's servers make an HTTP request on your server?
Or do you mean that the user's browser is redirected from PayPal's site to
your site?
>
>
> So, without any settings in Boot.scala, how do i handle the request
> from a framework point of view? And provide means for the user to
> customize what happens to those results? Some kind of
>
> PayPal.afterIPN({
> // bunch of processing
> })
>
> Thoughts?
>
> Tim
>
>
>
> >
>
--
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] Re: HTTP Client?
> Hmmm... I may be misunderstanding what you're saying... but...
>
> In the PayPal landing, I'd update the user's state (e.g., credit their
> account), add something to S.notices and then redirect the browser to either
> "/" or some other page. So, no HTML required on the landing page. Also,
> this is specific to the PayPal stuff so it shouldn't be referenced in Boot.
I think im not being clear. Let me clarify:
When the request comes in from paypal, I want to process that request,
get the various parameters and then provide some way for the user to
use those values to do whatever post-processing they require.
So, without any settings in Boot.scala, how do i handle the request
from a framework point of view? And provide means for the user to
customize what happens to those results? Some kind of
PayPal.afterIPN({
// bunch of processing
})
Thoughts?
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: HTTP Client?
On Mon, Sep 29, 2008 at 11:02 AM, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
>
> > You don't have to put this in LiftRules. You can just assign the
> call-back
> > URL to a session-specific handler. The URL will be session-specific,
> will
> > appear just before the hand-off to PayPal and disappear just after the
> > PayPal call-back completes. It can be something fixed (like
> > "/paypal-landing") or something random ("/paypal23948239084902384").
>
> Sure of course :)
>
> One other thing, how would you invoke the actual paypal response
> processing stuff without needing a html fragment calling a snippet?
> Ideally it would be nice if there was a minimal amount of
> configuration needed in boot. But if thats the only way its not a
> problem.
Hmmm... I may be misunderstanding what you're saying... but...
In the PayPal landing, I'd update the user's state (e.g., credit their
account), add something to S.notices and then redirect the browser to either
"/" or some other page. So, no HTML required on the landing page. Also,
this is specific to the PayPal stuff so it shouldn't be referenced in Boot.
>
>
> Cheers
>
> Tim
> >
>
--
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] Re: HTTP Client?
> You don't have to put this in LiftRules. You can just assign the call-back
> URL to a session-specific handler. The URL will be session-specific, will
> appear just before the hand-off to PayPal and disappear just after the
> PayPal call-back completes. It can be something fixed (like
> "/paypal-landing") or something random ("/paypal23948239084902384").
Sure of course :)
One other thing, how would you invoke the actual paypal response
processing stuff without needing a html fragment calling a snippet?
Ideally it would be nice if there was a minimal amount of
configuration needed in boot. But if thats the only way its not a
problem.
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: HTTP Client?
On Fri, Sep 26, 2008 at 2:34 AM, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> Great feedback - thanks guys!
>
> I'll re-jig the PDT stuff to make it more like your suggestions.
>
> Regarding the IPN pay pal stuff - I was having a think about this and
> thought that it would be good to do something along the same lines of
> ajax_requst.
>
> For instance, when you configure IPN you have to specify a location on
> your server where paypal will send the post data regarding the
> transaction - if we had:
>
> //paypal_gateway
>
> Then we could do all the processing and return an object which had all
> the data already assigned onto it. Before I start to right a bunch of
> stuff, what do people think? I don't want to pollute LiftServlet
> unless I really have to - is there someplace else I can put it, or
> would that be most suitable?
You don't have to put this in LiftRules. You can just assign the call-back
URL to a session-specific handler. The URL will be session-specific, will
appear just before the hand-off to PayPal and disappear just after the
PayPal call-back completes. It can be something fixed (like
"/paypal-landing") or something random ("/paypal23948239084902384").
Thanks,
David
>
>
> Cheers
>
> Tim
>
>
>
>
> On Sep 24, 4:48 pm, David Pollak <[EMAIL PROTECTED]> wrote:
> > Kris Nuttycombe wrote:
> > > If you're going to take that approach, why not just make the
> > > constructor or factory method ensure that the object is in a valid
> > > state to begin with? When I write immutable objects, they usually
> > > don't have any setters for that very reason. It doesn't make sense to
> > > me that one would construct a PayPal object in an unusable state.
> >
> > Agreed. The initial "builder" (no longer using the word Constructor per
> > Viktor's suggestion) should vend an object that can be used. Any
> > additional state (e.g., useSSL) should return a new instance of a
> > mutated object.
> >
> > As to Viktor's suggestion, having a bunch of builder methods on an
> > object rather than an explicit constructor is the right way to go. e.g.:
> >
> > trait PayPal {}
> >
> > object PayPal {
> > def apply(): PayPal =
> >
> > }
> > > Kris
> >
> > > On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]> wrote:
> >
> > >> Tim,
> >
> > >> I like the work, but I tend not to like mutable data structures (stuff
> with
> > >> properties that one sets.) I'd structure things such that the PayPal
> > >> object's "setters" return a new, immutable instance of the PayPal
> object, so
> > >> you're code would look like:
> >
> > >> val pp: PayPal = new
> > >> PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
> >
> > >> I'd also update the "execute" method so that it returns another
> immutable
> > >> object that has current state rather than mutating the original PayPal
> > >> object.
> >
> > >> Thanks,
> >
> > >> David
> >
> > >> Tim Perrett wrote:
> >
> > >> Thanks Derek :-) I have commited any code for ages, so its about time
> > >> I did!
> >
> > >> My plan is this - once I get this roll out of the site im doing now
> > >> (which just needs PDT) done, I'll add the IPN functions to it. From
> > >> the docs, it looks pretty straight forward.
> >
> > >> You can configure a whole bunch of options like so:
> >
> > >> /* values can be "sanbox" or "live" */
> > >> var paypal: PayPal = new PayPal("sandbox")
> > >> /* self expanitory */
> > >> paypal.transactionToken = S.param("tx").openOr("")
> > >> /* set if you need to use SSL (changes port and protocol) */
> > >> paypal.useSSL = true
> > >> /* run the paypal transaction - either with a PDT payload or IPN
> > >> payload */
> > >> paypal.execute("pdt")
> >
> > >> Anything else / different way of doing it people think I should build
> > >> in?
> >
> > >> Tim
> >
> > >> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]>
> wrote:
> >
> > >> Tim, you rock :)
> >
>
--
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] Re: HTTP Client?
Hey David, What do you think of my suggestion about creating something similar to ajax_request? I havent put any time into this yet as I wasnt sure if it was a good idea or not. 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: HTTP Client?
On Fri, Sep 26, 2008 at 3:50 PM, Marc Boschma
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> wrote:
>
> Given Lift's focus on security I envisioned that the POST URL would
> contain a random element, to reduce the threat of fake PayPal
> interactions. It is a small risk, but then it is the small risks that
> usually allow a hacker in, eventually.
>
> David said there was support for per session dispatch, which would
> mean that URL could be set up before calling PayPal. Once the session
> ended, or the transaction, you would remove the URL support after
> PayPal responded, or not...
Yes, the call-back will be session-specific. It could be a random URL and
that would be even more secure.
>
>
> I would favour the PayPal support being able to live independently of
> other lift modules, with some (one) StatefulSnippets as an example?
I think using Lift's call-back facilities and independent of Lift are
mutually exclusive. :-(
Thanks,
David
>
>
> Marc
>
> On 26/09/2008, at 7:34 PM, Tim Perrett wrote:
>
> >
> > Great feedback - thanks guys!
> >
> > I'll re-jig the PDT stuff to make it more like your suggestions.
> >
> > Regarding the IPN pay pal stuff - I was having a think about this and
> > thought that it would be good to do something along the same lines of
> > ajax_requst.
> >
> > For instance, when you configure IPN you have to specify a location on
> > your server where paypal will send the post data regarding the
> > transaction - if we had:
> >
> > //paypal_gateway
> >
> > Then we could do all the processing and return an object which had all
> > the data already assigned onto it. Before I start to right a bunch of
> > stuff, what do people think? I don't want to pollute LiftServlet
> > unless I really have to - is there someplace else I can put it, or
> > would that be most suitable?
> >
> > Cheers
> >
> > Tim
> >
> >
> >
> >
> > On Sep 24, 4:48 pm, David Pollak <[EMAIL PROTECTED]> wrote:
> >> Kris Nuttycombe wrote:
> >>> If you're going to take that approach, why not just make the
> >>> constructor or factory method ensure that the object is in a valid
> >>> state to begin with? When I write immutable objects, they usually
> >>> don't have any setters for that very reason. It doesn't make sense
> >>> to
> >>> me that one would construct a PayPal object in an unusable state.
> >>
> >> Agreed. The initial "builder" (no longer using the word
> >> Constructor per
> >> Viktor's suggestion) should vend an object that can be used. Any
> >> additional state (e.g., useSSL) should return a new instance of a
> >> mutated object.
> >>
> >> As to Viktor's suggestion, having a bunch of builder methods on an
> >> object rather than an explicit constructor is the right way to go.
> >> e.g.:
> >>
> >> trait PayPal {}
> >>
> >> object PayPal {
> >> def apply(): PayPal =
> >>
> >> }
> >>> Kris
> >>
> >>> On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]>
> >>> wrote:
> >>
> Tim,
> >>
> I like the work, but I tend not to like mutable data structures
> (stuff with
> properties that one sets.) I'd structure things such that the
> PayPal
> object's "setters" return a new, immutable instance of the PayPal
> object, so
> you're code would look like:
> >>
> val pp: PayPal = new
> PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
> >>
> I'd also update the "execute" method so that it returns another
> immutable
> object that has current state rather than mutating the original
> PayPal
> object.
> >>
> Thanks,
> >>
> David
> >>
> Tim Perrett wrote:
> >>
> Thanks Derek :-) I have commited any code for ages, so its about
> time
> I did!
> >>
> My plan is this - once I get this roll out of the site im doing now
> (which just needs PDT) done, I'll add the IPN functions to it. From
> the docs, it looks pretty straight forward.
> >>
> You can configure a whole bunch of options like so:
> >>
> /* values can be "sanbox" or "live" */
> var paypal: PayPal = new PayPal("sandbox")
> /* self expanitory */
> paypal.transactionToken = S.param("tx").openOr("")
> /* set if you need to use SSL (changes port and protocol) */
> paypal.useSSL = true
> /* run the paypal transaction - either with a PDT payload or
> IPN
> payload */
> paypal.execute("pdt")
> >>
> Anything else / different way of doing it people think I should
> build
> in?
> >>
> Tim
> >>
> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]>
> wrote:
> >>
> Tim, you rock :)
> > >
>
>
> >
>
--
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 Group
[Lift] Re: HTTP Client?
Given Lift's focus on security I envisioned that the POST URL would
contain a random element, to reduce the threat of fake PayPal
interactions. It is a small risk, but then it is the small risks that
usually allow a hacker in, eventually.
David said there was support for per session dispatch, which would
mean that URL could be set up before calling PayPal. Once the session
ended, or the transaction, you would remove the URL support after
PayPal responded, or not...
I would favour the PayPal support being able to live independently of
other lift modules, with some (one) StatefulSnippets as an example?
Marc
On 26/09/2008, at 7:34 PM, Tim Perrett wrote:
>
> Great feedback - thanks guys!
>
> I'll re-jig the PDT stuff to make it more like your suggestions.
>
> Regarding the IPN pay pal stuff - I was having a think about this and
> thought that it would be good to do something along the same lines of
> ajax_requst.
>
> For instance, when you configure IPN you have to specify a location on
> your server where paypal will send the post data regarding the
> transaction - if we had:
>
> //paypal_gateway
>
> Then we could do all the processing and return an object which had all
> the data already assigned onto it. Before I start to right a bunch of
> stuff, what do people think? I don't want to pollute LiftServlet
> unless I really have to - is there someplace else I can put it, or
> would that be most suitable?
>
> Cheers
>
> Tim
>
>
>
>
> On Sep 24, 4:48 pm, David Pollak <[EMAIL PROTECTED]> wrote:
>> Kris Nuttycombe wrote:
>>> If you're going to take that approach, why not just make the
>>> constructor or factory method ensure that the object is in a valid
>>> state to begin with? When I write immutable objects, they usually
>>> don't have any setters for that very reason. It doesn't make sense
>>> to
>>> me that one would construct a PayPal object in an unusable state.
>>
>> Agreed. The initial "builder" (no longer using the word
>> Constructor per
>> Viktor's suggestion) should vend an object that can be used. Any
>> additional state (e.g., useSSL) should return a new instance of a
>> mutated object.
>>
>> As to Viktor's suggestion, having a bunch of builder methods on an
>> object rather than an explicit constructor is the right way to go.
>> e.g.:
>>
>> trait PayPal {}
>>
>> object PayPal {
>> def apply(): PayPal =
>>
>> }
>>> Kris
>>
>>> On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]>
>>> wrote:
>>
Tim,
>>
I like the work, but I tend not to like mutable data structures
(stuff with
properties that one sets.) I'd structure things such that the
PayPal
object's "setters" return a new, immutable instance of the PayPal
object, so
you're code would look like:
>>
val pp: PayPal = new
PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
>>
I'd also update the "execute" method so that it returns another
immutable
object that has current state rather than mutating the original
PayPal
object.
>>
Thanks,
>>
David
>>
Tim Perrett wrote:
>>
Thanks Derek :-) I have commited any code for ages, so its about
time
I did!
>>
My plan is this - once I get this roll out of the site im doing now
(which just needs PDT) done, I'll add the IPN functions to it. From
the docs, it looks pretty straight forward.
>>
You can configure a whole bunch of options like so:
>>
/* values can be "sanbox" or "live" */
var paypal: PayPal = new PayPal("sandbox")
/* self expanitory */
paypal.transactionToken = S.param("tx").openOr("")
/* set if you need to use SSL (changes port and protocol) */
paypal.useSSL = true
/* run the paypal transaction - either with a PDT payload or
IPN
payload */
paypal.execute("pdt")
>>
Anything else / different way of doing it people think I should
build
in?
>>
Tim
>>
On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]>
wrote:
>>
Tim, you rock :)
> >
--~--~-~--~~~---~--~~
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: HTTP Client?
Great feedback - thanks guys!
I'll re-jig the PDT stuff to make it more like your suggestions.
Regarding the IPN pay pal stuff - I was having a think about this and
thought that it would be good to do something along the same lines of
ajax_requst.
For instance, when you configure IPN you have to specify a location on
your server where paypal will send the post data regarding the
transaction - if we had:
//paypal_gateway
Then we could do all the processing and return an object which had all
the data already assigned onto it. Before I start to right a bunch of
stuff, what do people think? I don't want to pollute LiftServlet
unless I really have to - is there someplace else I can put it, or
would that be most suitable?
Cheers
Tim
On Sep 24, 4:48 pm, David Pollak <[EMAIL PROTECTED]> wrote:
> Kris Nuttycombe wrote:
> > If you're going to take that approach, why not just make the
> > constructor or factory method ensure that the object is in a valid
> > state to begin with? When I write immutable objects, they usually
> > don't have any setters for that very reason. It doesn't make sense to
> > me that one would construct a PayPal object in an unusable state.
>
> Agreed. The initial "builder" (no longer using the word Constructor per
> Viktor's suggestion) should vend an object that can be used. Any
> additional state (e.g., useSSL) should return a new instance of a
> mutated object.
>
> As to Viktor's suggestion, having a bunch of builder methods on an
> object rather than an explicit constructor is the right way to go. e.g.:
>
> trait PayPal {}
>
> object PayPal {
> def apply(): PayPal =
>
> }
> > Kris
>
> > On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]> wrote:
>
> >> Tim,
>
> >> I like the work, but I tend not to like mutable data structures (stuff with
> >> properties that one sets.) I'd structure things such that the PayPal
> >> object's "setters" return a new, immutable instance of the PayPal object,
> >> so
> >> you're code would look like:
>
> >> val pp: PayPal = new
> >> PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
>
> >> I'd also update the "execute" method so that it returns another immutable
> >> object that has current state rather than mutating the original PayPal
> >> object.
>
> >> Thanks,
>
> >> David
>
> >> Tim Perrett wrote:
>
> >> Thanks Derek :-) I have commited any code for ages, so its about time
> >> I did!
>
> >> My plan is this - once I get this roll out of the site im doing now
> >> (which just needs PDT) done, I'll add the IPN functions to it. From
> >> the docs, it looks pretty straight forward.
>
> >> You can configure a whole bunch of options like so:
>
> >> /* values can be "sanbox" or "live" */
> >> var paypal: PayPal = new PayPal("sandbox")
> >> /* self expanitory */
> >> paypal.transactionToken = S.param("tx").openOr("")
> >> /* set if you need to use SSL (changes port and protocol) */
> >> paypal.useSSL = true
> >> /* run the paypal transaction - either with a PDT payload or IPN
> >> payload */
> >> paypal.execute("pdt")
>
> >> Anything else / different way of doing it people think I should build
> >> in?
>
> >> Tim
>
> >> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
>
> >> Tim, you rock :)
--~--~-~--~~~---~--~~
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: HTTP Client?
This reminds me -- in Lift, I've frequently seen the pattern of
utilizing a companion object's apply() methods as factories. Perhaps
it's just me, but this seems a little less intuitive than having an
explicitly named constructor method that is in some way descriptive of
the state in which the related object is being created. Is this just a
Scala idiom that I'm going to have to get used to? It seems
particularly strange because the use of apply() in this fashion is not
necessarily consistent; for example, the apply() usage of AnyVar and
its subclasses delegates to setFunc, which mutates an underlying data
structure. I sort of wish I could just call myRequestVar.set(myValue)
instead; that has a lot more semantic meaning to me when I'm scanning
code than does myRequestVar(myValue).
Kris
On Wed, Sep 24, 2008 at 9:48 AM, David Pollak <[EMAIL PROTECTED]> wrote:
>
>
> Kris Nuttycombe wrote:
>
> If you're going to take that approach, why not just make the
> constructor or factory method ensure that the object is in a valid
> state to begin with? When I write immutable objects, they usually
> don't have any setters for that very reason. It doesn't make sense to
> me that one would construct a PayPal object in an unusable state.
>
>
> Agreed. The initial "builder" (no longer using the word Constructor per
> Viktor's suggestion) should vend an object that can be used. Any additional
> state (e.g., useSSL) should return a new instance of a mutated object.
>
> As to Viktor's suggestion, having a bunch of builder methods on an object
> rather than an explicit constructor is the right way to go. e.g.:
>
> trait PayPal {}
>
> object PayPal {
> def apply(): PayPal =
> }
>
> Kris
>
> On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]> wrote:
>
>
> Tim,
>
> I like the work, but I tend not to like mutable data structures (stuff with
> properties that one sets.) I'd structure things such that the PayPal
> object's "setters" return a new, immutable instance of the PayPal object, so
> you're code would look like:
>
> val pp: PayPal = new
> PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
>
> I'd also update the "execute" method so that it returns another immutable
> object that has current state rather than mutating the original PayPal
> object.
>
> Thanks,
>
> David
>
> Tim Perrett wrote:
>
> Thanks Derek :-) I have commited any code for ages, so its about time
> I did!
>
> My plan is this - once I get this roll out of the site im doing now
> (which just needs PDT) done, I'll add the IPN functions to it. From
> the docs, it looks pretty straight forward.
>
> You can configure a whole bunch of options like so:
>
> /* values can be "sanbox" or "live" */
> var paypal: PayPal = new PayPal("sandbox")
> /* self expanitory */
> paypal.transactionToken = S.param("tx").openOr("")
> /* set if you need to use SSL (changes port and protocol) */
> paypal.useSSL = true
> /* run the paypal transaction - either with a PDT payload or IPN
> payload */
> paypal.execute("pdt")
>
> Anything else / different way of doing it people think I should build
> in?
>
> Tim
>
> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
>
>
> Tim, you rock :)
>
>
>
>
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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: HTTP Client?
Kris Nuttycombe wrote:
> If you're going to take that approach, why not just make the
> constructor or factory method ensure that the object is in a valid
> state to begin with? When I write immutable objects, they usually
> don't have any setters for that very reason. It doesn't make sense to
> me that one would construct a PayPal object in an unusable state.
>
Agreed. The initial "builder" (no longer using the word Constructor per
Viktor's suggestion) should vend an object that can be used. Any
additional state (e.g., useSSL) should return a new instance of a
mutated object.
As to Viktor's suggestion, having a bunch of builder methods on an
object rather than an explicit constructor is the right way to go. e.g.:
trait PayPal {}
object PayPal {
def apply(): PayPal =
}
> Kris
>
> On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]> wrote:
>
>> Tim,
>>
>> I like the work, but I tend not to like mutable data structures (stuff with
>> properties that one sets.) I'd structure things such that the PayPal
>> object's "setters" return a new, immutable instance of the PayPal object, so
>> you're code would look like:
>>
>> val pp: PayPal = new
>> PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
>>
>> I'd also update the "execute" method so that it returns another immutable
>> object that has current state rather than mutating the original PayPal
>> object.
>>
>> Thanks,
>>
>> David
>>
>> Tim Perrett wrote:
>>
>> Thanks Derek :-) I have commited any code for ages, so its about time
>> I did!
>>
>> My plan is this - once I get this roll out of the site im doing now
>> (which just needs PDT) done, I'll add the IPN functions to it. From
>> the docs, it looks pretty straight forward.
>>
>> You can configure a whole bunch of options like so:
>>
>> /* values can be "sanbox" or "live" */
>> var paypal: PayPal = new PayPal("sandbox")
>> /* self expanitory */
>> paypal.transactionToken = S.param("tx").openOr("")
>> /* set if you need to use SSL (changes port and protocol) */
>> paypal.useSSL = true
>> /* run the paypal transaction - either with a PDT payload or IPN
>> payload */
>> paypal.execute("pdt")
>>
>> Anything else / different way of doing it people think I should build
>> in?
>>
>> Tim
>>
>> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
>>
>>
>> Tim, you rock :)
>>
>>
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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: HTTP Client?
Also, when writing immutable objects, constructors suck since they do not
encourage object sharing...
On Wed, Sep 24, 2008 at 4:36 PM, Kris Nuttycombe
<[EMAIL PROTECTED]>wrote:
>
> If you're going to take that approach, why not just make the
> constructor or factory method ensure that the object is in a valid
> state to begin with? When I write immutable objects, they usually
> don't have any setters for that very reason. It doesn't make sense to
> me that one would construct a PayPal object in an unusable state.
>
> Kris
>
> On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]> wrote:
> > Tim,
> >
> > I like the work, but I tend not to like mutable data structures (stuff
> with
> > properties that one sets.) I'd structure things such that the PayPal
> > object's "setters" return a new, immutable instance of the PayPal object,
> so
> > you're code would look like:
> >
> > val pp: PayPal = new
> > PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
> >
> > I'd also update the "execute" method so that it returns another immutable
> > object that has current state rather than mutating the original PayPal
> > object.
> >
> > Thanks,
> >
> > David
> >
> > Tim Perrett wrote:
> >
> > Thanks Derek :-) I have commited any code for ages, so its about time
> > I did!
> >
> > My plan is this - once I get this roll out of the site im doing now
> > (which just needs PDT) done, I'll add the IPN functions to it. From
> > the docs, it looks pretty straight forward.
> >
> > You can configure a whole bunch of options like so:
> >
> > /* values can be "sanbox" or "live" */
> > var paypal: PayPal = new PayPal("sandbox")
> > /* self expanitory */
> > paypal.transactionToken = S.param("tx").openOr("")
> > /* set if you need to use SSL (changes port and protocol) */
> > paypal.useSSL = true
> > /* run the paypal transaction - either with a PDT payload or IPN
> > payload */
> > paypal.execute("pdt")
> >
> > Anything else / different way of doing it people think I should build
> > in?
> >
> > Tim
> >
> > On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
> >
> >
> > Tim, you rock :)
> >
> >
> >
> >
> > >
> >
>
> >
>
--
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: HTTP Client?
If you're going to take that approach, why not just make the
constructor or factory method ensure that the object is in a valid
state to begin with? When I write immutable objects, they usually
don't have any setters for that very reason. It doesn't make sense to
me that one would construct a PayPal object in an unusable state.
Kris
On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]> wrote:
> Tim,
>
> I like the work, but I tend not to like mutable data structures (stuff with
> properties that one sets.) I'd structure things such that the PayPal
> object's "setters" return a new, immutable instance of the PayPal object, so
> you're code would look like:
>
> val pp: PayPal = new
> PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
>
> I'd also update the "execute" method so that it returns another immutable
> object that has current state rather than mutating the original PayPal
> object.
>
> Thanks,
>
> David
>
> Tim Perrett wrote:
>
> Thanks Derek :-) I have commited any code for ages, so its about time
> I did!
>
> My plan is this - once I get this roll out of the site im doing now
> (which just needs PDT) done, I'll add the IPN functions to it. From
> the docs, it looks pretty straight forward.
>
> You can configure a whole bunch of options like so:
>
> /* values can be "sanbox" or "live" */
> var paypal: PayPal = new PayPal("sandbox")
> /* self expanitory */
> paypal.transactionToken = S.param("tx").openOr("")
> /* set if you need to use SSL (changes port and protocol) */
> paypal.useSSL = true
> /* run the paypal transaction - either with a PDT payload or IPN
> payload */
> paypal.execute("pdt")
>
> Anything else / different way of doing it people think I should build
> in?
>
> Tim
>
> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
>
>
> Tim, you rock :)
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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: HTTP Client?
Tim,
I like the work, but I tend not to like mutable data structures (stuff
with properties that one sets.) I'd structure things such that the
PayPal object's "setters" return a new, immutable instance of the PayPal
object, so you're code would look like:
val pp: PayPal = new
PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
I'd also update the "execute" method so that it returns another
immutable object that has current state rather than mutating the
original PayPal object.
Thanks,
David
Tim Perrett wrote:
> Thanks Derek :-) I have commited any code for ages, so its about time
> I did!
>
> My plan is this - once I get this roll out of the site im doing now
> (which just needs PDT) done, I'll add the IPN functions to it. From
> the docs, it looks pretty straight forward.
>
> You can configure a whole bunch of options like so:
>
> /* values can be "sanbox" or "live" */
> var paypal: PayPal = new PayPal("sandbox")
> /* self expanitory */
> paypal.transactionToken = S.param("tx").openOr("")
> /* set if you need to use SSL (changes port and protocol) */
> paypal.useSSL = true
> /* run the paypal transaction - either with a PDT payload or IPN
> payload */
> paypal.execute("pdt")
>
> Anything else / different way of doing it people think I should build
> in?
>
> Tim
>
> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
>
>> Tim, you rock :)
>>
>
> >
>
--~--~-~--~~~---~--~~
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: HTTP Client?
Thanks Derek :-) I have commited any code for ages, so its about time
I did!
My plan is this - once I get this roll out of the site im doing now
(which just needs PDT) done, I'll add the IPN functions to it. From
the docs, it looks pretty straight forward.
You can configure a whole bunch of options like so:
/* values can be "sanbox" or "live" */
var paypal: PayPal = new PayPal("sandbox")
/* self expanitory */
paypal.transactionToken = S.param("tx").openOr("")
/* set if you need to use SSL (changes port and protocol) */
paypal.useSSL = true
/* run the paypal transaction - either with a PDT payload or IPN
payload */
paypal.execute("pdt")
Anything else / different way of doing it people think I should build
in?
Tim
On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
> Tim, you rock :)
--~--~-~--~~~---~--~~
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: HTTP Client?
Tim, you rock :)
On Tue, Sep 23, 2008 at 10:29 AM, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> Hey guys,
>
> Ok, i've abstracted it all out into a class which you call a little
> like this:
>
>var paypal: PayPal = new PayPal("sandbox")
>paypal.transactionToken = S.param("tx").openOr("")
>paypal.execute("pdt")
>
> And as your authentication token is global to your account, you can
> specify it by doing:
>
>PayPal.authenticationToken = "dfgdfgdfgdfgdfgdfgd"
>
> which I palced in boot. So far i've only implemented PDT, but have
> allowed for implementing IPN too - which should be a minimal amount of
> work ontop of what i already have.
>
> Thoughts?
>
> 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: HTTP Client?
Hey guys,
Ok, i've abstracted it all out into a class which you call a little
like this:
var paypal: PayPal = new PayPal("sandbox")
paypal.transactionToken = S.param("tx").openOr("")
paypal.execute("pdt")
And as your authentication token is global to your account, you can
specify it by doing:
PayPal.authenticationToken = "dfgdfgdfgdfgdfgdfgd"
which I palced in boot. So far i've only implemented PDT, but have
allowed for implementing IPN too - which should be a minimal amount of
work ontop of what i already have.
Thoughts?
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: HTTP Client?
Tim Perrett wrote: > >> Lift has a little know feature that makes this kind of thing super simple >> and secure. >> >> S.addHighLevelSessionDispatcher(name: String, dispatch: >> LiftRules.DispatchPf) allows you to, on a session-by-session basis, specify >> what to do with a given URL. This allows you to have a PayPal landing page >> on your app (the page that the PayPal session returns to) that has all the >> state related to the purchase. Just before you send the user to PayPal, you >> set up the dispatch for /paypal-complete or something like that. Hand that >> URL to PayPal. When the user comes back, they'll go to that landing page... >> you do whatever magic is necessary to complete the purchase, remove the high >> level dispatch and remove the dispatch. >> >> Make sense? >> > > Wow, sounds groovy - so, you say "Just before you send the user to > PayPal, you set up the dispatch for /paypal-complete or something like > that" - where would you setup the dispatch? Is it a boot.scala > function? > No, because this is a session-specific thing, it cannot be set up inside of boot. It has to be set up while you've got an active session that you're about to redirect to PayPal. > Could you provide a little example of addHighLevelSessionDispatcher ? > Im not 100% clear on where it should be called > Please start working on the PayPal code. Once you have the server-server and server-browser negotiation stuff set up, I'll write the code to do the session-specific stuff. > 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: HTTP Client?
> Lift has a little know feature that makes this kind of thing super simple > and secure. > > S.addHighLevelSessionDispatcher(name: String, dispatch: > LiftRules.DispatchPf) allows you to, on a session-by-session basis, specify > what to do with a given URL. This allows you to have a PayPal landing page > on your app (the page that the PayPal session returns to) that has all the > state related to the purchase. Just before you send the user to PayPal, you > set up the dispatch for /paypal-complete or something like that. Hand that > URL to PayPal. When the user comes back, they'll go to that landing page... > you do whatever magic is necessary to complete the purchase, remove the high > level dispatch and remove the dispatch. > > Make sense? Wow, sounds groovy - so, you say "Just before you send the user to PayPal, you set up the dispatch for /paypal-complete or something like that" - where would you setup the dispatch? Is it a boot.scala function? Could you provide a little example of addHighLevelSessionDispatcher ? Im not 100% clear on where it should be called 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: HTTP Client?
On Tue, Sep 23, 2008 at 5:13 AM, Tim Perrett <[EMAIL PROTECTED]> wrote: > > > > On Sep 23, 12:36 pm, David Pollak <[EMAIL PROTECTED]> wrote: > > I'd love to have a PayPal module in Lift. Are you able to contribute > > this part of your code into the Lift codebase? > > That was my plan! :-D > > Right now im thinking of using bind to post back to the lift app, then > post it on to paypal rather than having a bunch of form variables > which could just be edited with firebug or whatever (particularly the > total amount). Lift has a little know feature that makes this kind of thing super simple and secure. S.addHighLevelSessionDispatcher(name: String, dispatch: LiftRules.DispatchPf) allows you to, on a session-by-session basis, specify what to do with a given URL. This allows you to have a PayPal landing page on your app (the page that the PayPal session returns to) that has all the state related to the purchase. Just before you send the user to PayPal, you set up the dispatch for /paypal-complete or something like that. Hand that URL to PayPal. When the user comes back, they'll go to that landing page... you do whatever magic is necessary to complete the purchase, remove the high level dispatch and remove the dispatch. Make sense? > > > Just trying to figure the best method of sending the post and doing > the PDT stuff > > Cheers > > Tim > > > -- 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] Re: HTTP Client?
On Sep 23, 12:36 pm, David Pollak <[EMAIL PROTECTED]> wrote: > I'd love to have a PayPal module in Lift. Are you able to contribute > this part of your code into the Lift codebase? That was my plan! :-D Right now im thinking of using bind to post back to the lift app, then post it on to paypal rather than having a bunch of form variables which could just be edited with firebug or whatever (particularly the total amount). Just trying to figure the best method of sending the post and doing the PDT stuff 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: HTTP Client?
I'd love to have a PayPal module in Lift. Are you able to contribute this part of your code into the Lift codebase? Tim Perrett wrote: > Hey guys, > > Just a quick one - im putting together a little donation page on a > lift app im building and its using paypal for the donation / buynow > process. With there PDT system you need to make a call back to there > server and I was just wondering if there was a scala HTTP client > kicking around or if I was better off just using something already out > there in java land? > > Cheers > > Tim > > PS: I've never used PayPal before, but it looks to be really simple. > > > --~--~-~--~~~---~--~~ 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: HTTP Client?
Can't you use HTTPConnection? http://java.sun.com/j2se/1.4.2/docs/api/java/net/HttpURLConnection.html Cheers! -Viktor On Tue, Sep 23, 2008 at 12:17 PM, Tim Perrett <[EMAIL PROTECTED]> wrote: > > Hey guys, > > Just a quick one - im putting together a little donation page on a > lift app im building and its using paypal for the donation / buynow > process. With there PDT system you need to make a call back to there > server and I was just wondering if there was a scala HTTP client > kicking around or if I was better off just using something already out > there in java land? > > Cheers > > Tim > > PS: I've never used PayPal before, but it looks to be really simple. > > > -- 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
