Im not married to the current API, so breaking changes are OK as there
are only a handful of people using this code right now.
To be honest, this whole situation just underlines the need for
mocking in this module of lift... i've been meaning to do it since the
beginning but just never got round to it and lack of general demand.
Just about why they have a different signature... if memory serves
that would be because PaypalTransactionStatus is not supplied for PDT.
So whilst I see your point about them being consistent, im not sure
there is value in having a Box parameter that would always be Empty?
For IPN however, boxing sounds good to me.
Should just be a case of:
Box !! info.paymentStatus
Would you be happy with that? If you could raise a ticket for this
issue i'll patch it tomorrow and commit the code on a branch related
to that ticket. One the code goes through review then it will make it
into the master branch all being well.
Cheers, Tim
On 8 Oct 2009, at 18:52, Ryan Donahue wrote:
> Yeah, I noticed my email got mangled.
>
> It would make sense to me if PaypalIPN.actions and
> PaypalPDT.pdtResponse were consistent.
>
> trait PaypalPDT {
> def pdtResponse: PartialFunction[(PayPalInfo, Req), LiftResponse]
> }
>
> trait PaypalIPN {
> def actions: PartialFunction[(PayPalInfo, Req), Unit]
> }
>
> If matching the status is just too convenient to lose, then how
> about this.
>
> trait PaypalPDT {
> def pdtResponse: PartialFunction[(Box
> [PaypalTransactionStatus.Value], PayPalInfo, Req), LiftResponse]
> }
>
> trait PaypalIPN {
> def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
> PayPalInfo, Req), Unit]
> }
>
> Either would be an API breaking change for the paypal module, but at
> least it'd be caught be the compiler. What do you think?
>
> On Thu, Oct 8, 2009 at 1:33 PM, Timothy Perrett <[email protected]
> > wrote:
>
> The parameters were pretty mangled in your email... Which one would
> you propose is more generic that the current status one we have?
> Alternatively, it sounds to me like we might need to add some kind of
> special case match statement.
>
> Thoughts?
>
> Cheers, tim
>
> On 8 Oct 2009, at 13:14, Ryan Donahue wrote:
>
> >
> > Hi Tim,
> >
> > Looking at "Table 2. Summary of subscription variables" of the page
> > you reference, payment_status is not included for messages with a
> > txn_type of subscr_ signup, subscr_ cancel, subscr_ modify, or
> > subscr_eot.
> >
> > This matches the results I see in testing with PayPal Sandbox.
> > Neither subscr_signup or subscr_cancel include the payment_status.
> > Below are the parameters from two messages I have received (they
> > contain fake user info generated by PayPal Sandbox, so no security/
> > privacy concerns).
> >
> > params from subscr_signup message:
> > btn_id -> List(1070963), test_ipn -> List(1), charset -> List
> > (windows-1252), address_country -> List(United States), item_name ->
> > List(Pro Account), recurring -> List(1), address_state -> List(CA),
> > amount3 -> List(9.99), address_street -> List(1 Main St),
> > verify_sign -
> >> List(Ab4im9HUsk1pOL1dlUXJxEoipQcaAJQqV047JE2KENGFX4meCETo.KLt),
> > address_status -> List(confirmed), period3 -> List(1 M),
> subscr_date -
> >> List(05:01:02 Oct 08, 2009 PDT), first_name -> List(Test),
> > address_country_code -> List(US), address_city -> List(San Jose),
> > mc_currency -> List(USD), mc_amount3 -> List(9.99),
> > residence_country -
> >> List(US), payer_email -> List([email protected]),
> > address_name -> List(Test User), txn_type -> List(subscr_signup),
> > payer_status -> List(verified), subscr_id -> List
> > (S-8X87353621486401E), last_name -> List(User), payer_id -> List
> > (JMM2RTLNU5RPJ), reattempt -> List(1), notify_version -> List(2.8),
> > custom -> List(2), address_zip -> List(95131), receiver_email ->
> List
> > ([email protected]), business -> List
> > ([email protected])
> >
> > params from subscr_cancel message:
> > btn_id -> List(1070963), test_ipn -> List(1), charset -> List
> > (windows-1252), address_country -> List(United States), item_name ->
> > List(Pro Account), recurring -> List(1), address_state -> List(CA),
> > amount3 -> List(9.99), address_street -> List(1 Main St),
> > verify_sign -
> >> List(AvpXEetWAO5JsntihTfwE4HykmNlAsappICrYh6PaVgG3JJUYLtOnqVU),
> > address_status -> List(confirmed), period3 -> List(1 M),
> subscr_date -
> >> List(05:06:19 Oct 08, 2009 PDT), first_name -> List(Test),
> > address_country_code -> List(US), address_city -> List(San Jose),
> > mc_currency -> List(USD), mc_amount3 -> List(9.99),
> > residence_country -
> >> List(US), payer_email -> List([email protected]),
> > address_name -> List(Test User), txn_type -> List(subscr_cancel),
> > payer_status -> List(verified), subscr_id -> List
> > (S-8X87353621486401E), last_name -> List(User), payer_id -> List
> > (JMM2RTLNU5RPJ), reattempt -> List(1), notify_version -> List(2.8),
> > custom -> List(2), address_zip -> List(95131), receiver_email ->
> List
> > ([email protected]), business -> List
> > ([email protected])
> >
> > Thanks,
> >
> > Ryan
> >
> > On Oct 7, 6:18 pm, Timothy Perrett <[email protected]> wrote:
> >> Ryan,
> >>
> >> The PayPal stuff is pretty much my baby - its awesome that your
> using
> >> it in production!
> >>
> >> See what your saying - its been a while since I did anything with
> >> PayPal; what fields *are* returned when the transaction is
> canceled?
> >> Or, specifically, the question is what behaviour do you need?
> >>
> >> Lets start there and then I can work on a solution - it was my
> >> understanding that all responses from paypal had the payment_status
> >> field; im using the reference here:http://is.gd/43po4can you detail
> >> the type of transaction you've been seeing this behaviour on?
> >>
> >> Cheers, Tim
> >>
> >> On 7 Oct 2009, at 20:56, Ryan Donahue wrote:
> >>
> >>
> >>
> >>> I'm receiving IPN updates from PayPal when a subcription is
> created
> >>> and when it is canceled. However, the cancel message never make
> >>> it to
> >>> my actions method. Apparently, the cancel message does not
> include
> >>> the payment_status. I think this results in the message being
> >>> dropped
> >>> on the floor because of the for-comprehension on line 458 in
> >>> Paypal.scala. Would appreciate any help. By the way, we've been
> >>> using the paypal module in production for a couple months now (a
> >>> very
> >>> small app for selling a partner-branded version of our screen
> >>> recorder).
> >>
> >>> Thanks,
> >>
> >>> Ryan
> > >
> >
>
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
