Ok cool - I think im getting this :)
Somthing else I've just been noodling and I havent tried yet, what
happens if you repeatably call a method on a case class? I was
thinking of having something like:
var x = PaypalIPNHandler().onEvent(CompletedPayment, myfunction _ ::
anotherFunc _ :: Nil).onEvent(PendingPayment, dealWithPending _ ::
Nil)
Would the variable X have both event handlers or would it just have
one? I have a list of event objects to wrap the statuses retrived from
paypal like so:
val paypalPaymentStatuses: List[PaypalPaymentStatus] = List(
CanceledPayment,
ClearedPayment,
CompletedPayment,
DeniedPayment,
ExpiredPayment,
FailedPayment,
FailedPayment,
PendingPayment,
RefundedPayment,
ReturnedPayment,
ReversedPayment,
UnclaimedPayment,
UnclearedPayment
)
and would like to make is easy for the user to setup behavior for
there individual circumstances.
Cheers
Tim
On Oct 16, 7:43 pm, Marius <[EMAIL PROTECTED]> wrote:
> On Oct 16, 9:33 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > Thanks for the explanation Marius - that makes perfect sense. I'll
> > take that advice as your right, it fits the need perfectly.
>
> > If I wanted a list of functions that could have a couple of different
> > parameters I guess it would be:
>
> > List[(String,Int) => Any]
>
> > Or whatever, right?
>
> Right
>
> Also, what is the Any for?
>
> Any is there so you can basically use a function that returns
> anything, Unit, Int String ... if you just don't care about the
> function's result.
>
> Does that define what
>
> > type of function is valid as a callable function?
>
> Kind of ...yes ... any function that fits that signature.
>
> For instance, if i
>
> > had a trait / class with a bunch of methods in that I wanted the user
> > to start with, could I do something like:
>
> > List[(String) => PaypalHandler]
>
> > so that only methods of type PaypalHandler or subclasses are valid?
>
> Yes it should due to covariant return types.
>
>
>
> > Cheers
>
> > Tim
>
> > On Oct 16, 7:24 pm, Marius <[EMAIL PROTECTED]> wrote:
>
> > > well List[(String) => Any] is a list of functions that take a String
> > > as an argument and return an Any
>
> > > Assume we have two functions that we want tobe called when a failure
> > > occurs
> > > def f1(s: String) = ...
>
> > > def f2(s: Sting) = ...
>
> > > PaypalIPNHandler().onFailure(f1 _ :: f2 _ :: NIL)
>
> > > We're passed here a list of partially applied functions. This
> > > functions will be sequentially called when a failure occurs. Note that
> > > you can use curried functions as well if you want to pass additional
> > > state
>
> > > onFailure is defined something like
>
> > > def onFailure(funcs: List[(String) => Any]) = failureFuncs = funcs
>
> > > when a failure occurs you can do
>
> > > failureFuncs.map(_("failure info")) // for each function registered
> > > just call it.
>
> > > Now, again, here I used a String as an argument (lack of inspiration)
> > > but it can be your own object holding relevant information about your
> > > failure.
>
> > > This approach seems to fit your requirements of "I want to build it so
> > > that users can execute any code they wish upon a different event from
> > > paypal. " since users can register "arbitrary" functions
>
> > > Br's,
> > > Marius
>
> > > On Oct 16, 4:52 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > > > > Do default handlers actually do anything?
>
> > > > Right now, no they don't, I need to noodle the design to make sure
> > > > there's nothing that it would be usefull to inherit
>
> > > > > Why not using functions or a List[(String) => Any] (Instead of String
> > > > > you may pass any type so the function signature is not so important).
> > > > > This is a paradigm used in Lift a lot.
>
> > > > I can't say I'm familiar with that syntax? (well, what it's actually
> > > > doing). Might you be able to explain a little?
>
> > > > I want to build it so that users can execute any code they wish upon a
> > > > different event from paypal.
>
> > > > Cheers
>
> > > > Tim
>
> > > > > Br's,
> > > > > Marius
>
> > > > > On Oct 16, 1:36 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
> > > > >> Hey guys,
>
> > > > >> Im just implementing the IPN stuff for paypal and had a quick
> > > > >> question. I think it would be cool to write something like:
>
> > > > >> PaypalIPNHandler(
> > > > >> ).onFailure(FailureHandler).onVerified(VerifiedHandler)
>
> > > > >> object FailureHandler { ... } // or case class etc
> > > > >> object VerifiedHandler { ... }
>
> > > > >> Im thinking of this so that then users can subclass the default
> > > > >> handlers and get all the functionality / processing that comes as
> > > > >> default, but then lets them customise so they can update the database
> > > > >> or whatever they want to do with that information.
>
> > > > >> So, my question is this: is this a good idea? Any drawbacks in doing
> > > > >> this?
>
> > > > >> Cheers
>
> > > > >> Tim
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
