[Lift] Re: HTTP Client?

2008-10-01 Thread Tim Perrett 

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?

2008-10-01 Thread jon 

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?

2008-09-29 Thread David Pollak 
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:
 
  /context_path/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 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?

2008-09-29 Thread Tim Perrett 

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?

2008-09-29 Thread David Pollak 
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?

2008-09-29 Thread Tim Perrett 


 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?

2008-09-26 Thread Tim Perrett 

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:

/context_path/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?

2008-09-26 Thread Marc Boschma 

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:

 /context_path/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?

2008-09-24 Thread Viktor Klang 
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?

2008-09-24 Thread David Pollak 


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?

2008-09-23 Thread Tim Perrett 


 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?

2008-09-23 Thread Derek Chen-Becker 
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?

2008-09-23 Thread Tim Perrett 

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?

2008-09-23 Thread David Pollak 
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
-~--~~~~--~~--~--~---