Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Nested Dispatch Tables?

by Spidy (Chaplain)
on Mar 24, 2008 at 04:06 UTC ( #675850=perlquestion: print w/replies, xml ) Need Help??
Spidy has asked for the wisdom of the Perl Monks concerning the following question:

Greetings, fellow monks.

I am currently working on an Ajax-driven web application, which has a data access layer written in Perl. There are two distinct entities that actions are performed on, called containers and objects. I am currently rewriting urls that look like /actions/container/create or /actions/object/delete to my actions script, and passing in a type parameter to mark whether we are to perform operations on objects or containers.

I am planning on writing a dispatch table to handle all of the available actions passed to the script, but I was wondering: is there a way to write nested dispatch tables, so that I can dispatch based on the type as well? I was planning on having separate tables for containers versus objects, but can't seem to wrap my head around how I'd go about implementing this.



Replies are listed 'Best First'.
Re: Nested Dispatch Tables?
by chromatic (Archbishop) on Mar 24, 2008 at 04:43 UTC
    I was wondering: is there a way to write nested dispatch tables, so that I can dispatch based on the type as well?

    That sounds like polymorphism to me. Call a named method on a container instance or an object instance and Perl will dispatch to the appropriate method for you based on type.

Re: Nested Dispatch Tables?
by bobf (Monsignor) on Mar 24, 2008 at 04:48 UTC

    You can use any structure as a dispatch table (although they may not all fit the formal definition), including a HoH ($dispatch{$type}{$action} = $sub). A regular hash would work if you decided upon a method for concatenating params into a single string to use as a key ($dispatch{ $type . '_' . $action }).

    Perhaps I do not understand what you mean by a 'nested' dispatch table. Please elaborate if I'm missing the question.

      That sort of sounds like what I'm looking for. In the end, I want to be able to make a call like $actions->{$type}->{$action}->();, or however you'd accomplish the same thing(if that makes any sense) in actually valid Perl.

      This isn't the most elegant of solutions, but would building my two dispatch tables(something like %objects and %containers) and then storing them into an %actions hash as references work?

        The code you give there is valid Perl. If you built a structure using something like the following you would be able to use it just like that:
        my $actions = { first_action => { type1 => \&some_function, another_type => \&another_function }, second_action => { another_type => \&function, yet_another_type => \&something, }, };
        -- David Irving

        Altough you have said that you are not using object-oriented techniques, what chromatic gave you reads like this: $container->action() or $object->action() which looks quite elegant to me. Instead of dispatch tables, you would have two classes and then choose what kind of object to create depending on your $type variable. Then, for each class, you would have your special $actions (methods). That way your main code is the same for both containers and objects, and their differences are hidden in their own space.


Re: Nested Dispatch Tables?
by NetWallah (Canon) on Mar 24, 2008 at 05:24 UTC
    If you are doing OO programming, the need for dispatch tables outside a class should not arise. Or, rather, if it does arise, the decision should be delegated to the appropriate (sub)class, and have only one dimension.

    To my mind, if requirements appear more convoluted than that, the objects have not been sufficiently decomposed. In particular, when you appear to need to dispatch by TYPE - that decision clearly should already have been done based on the class of the object you are addressing.

    Perhaps, if you gave us some information about the problem domain (preferably code or pseudo-code), this discussion would not appear to be so abstract.

         "As you get older three things happen. The first is your memory goes, and I can't remember the other two... " - Sir Norman Wisdom

      I'm not doing any OO programming for this project - sorry if anything I said made you think that.

Re: Nested Dispatch Tables?
by sundialsvc4 (Abbot) on Mar 24, 2008 at 15:45 UTC

    Ditum Ne Agas:   Do Not Do A Thing Already Done.

    What you are describing is “a RESTful application,” and there's no good reason to do that yet again. It's already been done. And, done well. Look at things like Catalyst and other existing Perl frameworks which you might be able to apply to your goals.

    Programmers “instinctively” jump to the conclusion that they must write a new application, but let's face it:   ain't too much really new in this world, and there's no point in doing yet-again what has already been done. Just hitch a ride on a passing starship and go.

    “I don't want to invent a warp engine! I want to get to Alpha Centauri in time for dinner!”

      At the core of it, the RESTful interface isn't the overarching goal - it's just a single piece of a larger entity. It doesn't make sense to me to use an entire framework when all I need is a dispatch table. The URL rewriting example was simply to explain that different types/actions would be getting passed to my script.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://675850]
Approved by planetscape
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (10)
As of 2018-06-22 15:35 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (124 votes). Check out past polls.