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
-~----------~----~----~----~------~----~------~--~---
