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:
>
> /<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?
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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
