Best practice: how to write local plugin functions for library handlers?

David Bovill david.bovill at gmail.com
Fri Jun 19 05:47:27 EDT 2009


Thanks Andre - good to know someone else likes indexing code and dynamically
generating it - you can do great things coupling that with introspection. I
don't think that helps with the aim here which is minimal scripting effort -
equivalent to calling a normal library function, but one you can customise
with your own local test functions. I've simplified it a bit and got rid of
the call to executioncontexts I was using:

function script_CallingObject
    return item 1 of line -3 of the executioncontexts
end script_CallingObject

and pass the long id of me to the library function if the default "target"
won't do. I'm using getprop handlers in the local script as I prefer the
simplicity of the syntax and speed.

I'll take a look at the XmlRpc server code though - have you got a link to
the latest version? - are you using an array to define the xmlrpc call and
passing that to the library handlers? - think that is a great technique as
you get named params where the order no longer matters and avoid huge lists
of params.


2009/6/18 Andre Garzia <andre at andregarzia.com>

> David,
>
> I don't know if I really understood the problem so pardon me if I give you
> a
> non-solution. When I don't know in advance what functions I will be calling
> during runtime, I usually do the following. First I create a global array
> with elements which are also arrays, this stored elements have the
> following
> keys:
>
> name  -  a generic name for a given function, it need not be tied to the
> function real name.
> method - the real function/handler name of a given function or handler
> type - if it is a function or a handler/command
> target - a long id to the function/handler is available.
>
> so a hello world might look like this:
>
> myHelloA["name"] =  "helloworld"
> myHelloA["method"] = "mySweetHelloWorld"
> myHelloA["type"] = "command"
> myHelloA["target"] = "stack "hello.rev""
>
> With an array of such elements, I have a dictionary of available functions.
> If you loops this array you can depending on the type, assemble a dispatch
> or a value call. So to add more tests, you just add more elements to the
> global storage array.
>
> I use a similar code in my xmlrpc server and it works fine. Generating code
> chunks at runtime and executing them might be easier to maintain than a
> catch all code. I like generating code at runtime. If you're only executing
> inside the IDE then you don't need "do", you can create a temp stack, set
> the script of it to your runtime generated piece and call it. No penalty
> there.
>
> Hope this helps
> andre
>
> On Thu, Jun 18, 2009 at 8:07 AM, David Bovill <david at architex.tv> wrote:
>
> > Say we have a complex, but generally useful handler that loops through a
> > lot
> > of things, and want to call a function on each element found. For example
> > it
> > may be a "search" function that loops through all objects in a stack, or
> a
> > "process' function that loops through certain nodes in an XML file. Now
> > there may be all sorts of "test functions" that we would like to call
> > during
> > this search - the question is how to structure the library handler and be
> > able to call custom test functions / handlers in the local script you are
> > working on?
> >
> >
>
> --
> http://www.andregarzia.com All We Do Is Code.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



More information about the use-livecode mailing list