in reply to consolidating menu option processing

Class::StateMachine, Term::Interact example, dispatch table, IO::Prompter, Term::Interact, Term::Menu ...

poorly thought out example

use strict; use warnings; use Data::Dump qw/ dd pp /; my $stash = menu_one( "say hi or say bye:\n", [ qr/hi/i => sub { print "hi\n"; $_[1]->{hi}++; 1 }, ], [ qr/quit|bye|adios/i => sub { print "bye bye\n"; 0 }, ], ); dd( $stash ); dd( menu_one( "say why :", [ qr/.*/ => sub { die "why?!?!?\n"; 0 }, ], ), ); sub menu_one { my( $header, @actions ) = @_; my $ret = 1; my $stash = {}; while( $ret ){ my $line = getone($header); ACTION_LOOP: for my $action ( @actions ){ my( $match, $callback ) = @$action; if( $line =~ $match ){ $ret = $callback->( $line, $stash ); last ACTION_LOOP; } } } return $stash; } sub getone { print @_; scalar <>; }

Replies are listed 'Best First'.
Re^2: consolidating menu option processing
by temporal (Pilgrim) on Jul 19, 2013 at 13:32 UTC

    Well that's certainly a nifty approach, encapsulating the entire menu's functionality rather than just the unique options. Thanks for the example!

    I should've guessed there would already be something on CPAN, ha. Most of those modules seem to be good for validating input, but not so much for consolidating all of the options execution (which is in addition retrieving basic string input) at a single point of code.

    Since we both ended up implementing variations on them - it seems like dispatch tables are the way to go! =)

    Strange things are afoot at the Circle-K.