Just tested with paypal sandbox and it works, thanks.
On Oct 11, 5:59 pm, Timothy Perrett wrote:
> Ryan,
>
> I have pushed the code to master so give it a couple of hours and
> Hudson should automatically start pulling those changes into 1.1-
> SNAPSHOT JARs for you. Alternatively do a pull an
Ryan,
I have pushed the code to master so give it a couple of hours and
Hudson should automatically start pulling those changes into 1.1-
SNAPSHOT JARs for you. Alternatively do a pull and build locally.
Cheers, Tim
On 10 Oct 2009, at 01:38, Timothy Perrett wrote:
>
> Ryan,
>
> Ignore my l
Ryan,
Ignore my last email please - i've just tested the change using the
IPN simulator and it now handles the Cancel message properly by
passing Empty.
The change is on my branch here:
http://github.com/dpp/liftweb/commit/451dd3cb97e562a063da5cfe046badf1f9d8ad4c
Cheers, Tim
On Oct 10, 1:05 a
Ryan,
Looking at it, the strange thing is actually why it compiles now, not
why it doesn't compile with the change you suggested.
Given:
for (info <- buildInfo(resp, r);
// stat is going to be a Box[PaypalTransactionStatus.Value] anyway
// because of L489.
stat <- info.paymentStatus) yie
Here's a diff showing the changes I made. Notice I added a case to the
SimplePaypal.actions method that I'd think would fail compilation but does
not.
On Fri, Oct 9, 2009 at 1:08 PM, Ryan Donahue wrote:
> Well, I am a scala newb, but I know maven all too well. I ran "mvn clean
> install" from
Well, I am a scala newb, but I know maven all too well. I ran "mvn clean
install" from the lift-paypal dir to install lift-paypal-1.1-SNAPSHOT.jar to
my local repo.
To be sure, I changed the signature as follows which does cause errors:
def actions: PartialFunction[(PayPalInfo, Req), Unit]
Chang
Hey Ryan,
How *exactly* did you locally do the build? If you had done the
install of your altered lift-paypal then you would certainly get a
compile error because the signature has changed. The new syntax should
be:
object MyIPN extends PaypalIPN {
def actions = {
case (Full(CompletedPayme
Tim,
I locally changed the PaypalIPN.actions method return type to
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Apparently this does not cause any compilation errors for user
implementing their own IPN handler as follows
object M
Ok cool, I'll take a look at this tomrrow all being well.
Thanks for the feedback
Cheers, Tim
Sent from my iPhone
On 8 Oct 2009, at 20:43, Ryan Donahue wrote:
> I created the ticket: http://github.com/dpp/liftweb/issues/#issue/88
>
> I do receive the payment_status field for PDT. I bet in pr
I created the ticket: http://github.com/dpp/liftweb/issues/#issue/88
I do receive the payment_status field for PDT. I bet in practice you will
never receive a payment_status value other than Completed, because if the
payment was not completed PayPal would not redirect the user's browser back
to y
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 r
I am about to use the PayPal module, too and I am in favor for getting
things right even if breaking the API!
Heiko
2009/10/8 Ryan Donahue
> Yeah, I noticed my email got mangled.
>
> It would make sense to me if PaypalIPN.actions and PaypalPDT.pdtResponse
> were consistent.
>
> trait PaypalPDT {
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 ma
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 Dona
Arg, looks like the param listings in my message got formatted as
previous message quotes. Hopefully, it is clear enough.
On Oct 8, 8:14 am, Ryan Donahue wrote:
> Hi Tim,
>
> Looking at "Table 2. Summary of subscription variables" of the page
> you reference, payment_status is not included for
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_s
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?
17 matches
Mail list logo
