in bug 1467 (http://bugs.slimdevices.com/show_bug.cgi?id=1467) there is
some grumbling by kdf and dean about the use of passback by INPUT.List.
So, since I wrote it in there to begin with, I figured I might as well
explain why.

The INPUT modes are intended to be generic. They are only intended to
handle actions which are common to all callers of the mode. So for
INPUT.List this means up/down and number scrolling. Everything else is
dependent on the caller.

Now we come to where we need to make a choice: How do we let the caller
determine what happens when we press a button (play for instance)?

There are several options here.

1) For those buttons you don't know how to handle, re-press them in the
mode of your caller (passback).

2) For those buttons you don't know how to handle, call an exit handler
in your caller, letting it know what was pressed (the original method I
used, see change 319)

3) The caller supplies all desired extra functions to the INPUT mode
when it calls it (INPUT.Choice does a little of this)

Why did I choose 1 over 2? I had some experience with the second method
with INPUT.Text, and it was a pain to deal with, much like the command
execution callbacks. To make it work, you need to have a bit if - elsif
structure, or a hash to look up the exit mode and decide what to do. if
- elsif is clunky, so the hash method is preferable. So, you end up
with a hash that maps exit modes to code references. Those exit modes
are most likely going to be stuff like 'play' or 'add' or 'left' or 'right'.

It turns out we already have a hash that looks a lot like that - the
function hash that is present in pretty much every button mode.

What really makes the exit handler a pain are button pressing styles.
You either have to map them all individually in the INPUT mode to send
different function arguments to exit, or you need to query the client
object in your exit handler to figure out exactly which button was
pressed, and how.

The thing that puts the final nail in the coffin of everything through
an exit handler for me is user customization. With the exit handler,
you pretty much are stuck with the mapping that is in the perl code. If
a user want a different behavior, they have to edit the code.

passback makes things easier on the developer, and on the user. For the
developer, he makes a function hash just as if he were handling the
input himself, except he only needs to specify the code which is
specific to his mode. The Default.map entries (or defaultMap()) are
also made as if the mode didn't use an INPUT mode.

For the user, he can remap the mode as desired, just by editing a
custom.map file. Even brand new buttons can be added just by adding map
entries (to both the mode and to the INPUT mode, where the INPUT mode is
mapped to passback).

In the current implementation of INPUT.List, I still do have an exit
handler, but just for left/right. This is because pretty much every
caller of INPUT.List will need to do similar things for left and right.
I also handle the simplest case, just displaying a list, where right
should do nothing but bump, and left pop out of the mode.

As for that third option, I have some problems with it as well. For one
thing, it too suffers from difficult user customization (remapping
through code rather than map files). It also falls into the bad (in my
opinion) habit of conflating buttons and functions. For example, in
INPUT.Choice, there are mappings of play to play and add to add, which
in turn invoke the onPlay and onAdd callbacks provided. The problem
here is that a caller might not necessarily want to 'play' something or
'add' something when those buttons are pressed. But the choice of
naming the functions is no longer there.

Another problem with the third option is button pressing styles. Again
picking on INPUT.Choice, you can't do anything except a simple play or
add, all the other styles of play/add are dead. If you follow the onX
paradigm, you'll need to supply onX functions for every style, and have
mappings in the INPUT mode for each button style. Or instead of
individual onX functions, you could pass a hash of functions which could
include the various styles. There are still mapping problems there though.

So, that's what went into my decision to use passback instead of the
other options. Comments/questions?

kdf

2005-06-17, 09:16

Quoting Robert Moser <rlmoser (AT) comcast (DOT) net>:

> in bug 1467 (http://bugs.slimdevices.com/show_bug.cgi?id=1467) there is
> some grumbling by kdf and dean about the use of passback by INPUT.List.

oh for the love of...

I only suggested it as way to work around a problem
its now fixed, so I really don't see any reason for passback to go anywhere.