Linking a JS object to ScriptUI listbox item

Question

I am writing a script that that takes elements from a document and for each element makes a custom object with its own properties and methods. This list of elements is then spat out into a ScriptsUI listbox.
How do I link each listbox item to its associated obejct? i.e. So if I double click on a listbox item it will run a particular method within that object.
P.S. I dont want to have to store array ids in a column or something hacky like that.

Answer 1

Yep, it seems that the Translator component of the MVVM pattern wouldn't be very useful in a ScriptUI perspective.
The most asbtract pattern you have to deal with, I think, is the GenericList widget (ListBox, DropDownList, maybe TreeView?) and its relationship with what we may call a DataProvider (following Flex and .NET terminology). But ScriptUI/ExtendScript does not allow a serious level of data binding.
The whole problem is to emulate something of a dynamic link so that the data provider can notify the List widget of some changing. As a response, the List then would update its items accordingly. A skeleton of this approach could be drawn using custom event notification:
const EXTERNAL_EVENT_TYPE = 'myEventType';
var externalProcess = function F()
    if( F.targetWidget )
        F.targetWidget.dispatchEvent(new UIEvent(EXTERNAL_EVENT_TYPE));
// =====================================
// UI
// =====================================
var w = new Window('dialog', "Example"),
    // register the LB as a target:
    lb = externalProcess.targetWidget = w.add('listbox'),
    b = w.add('button',undefined,"Test Change");
lb.addEventListener(
    EXTERNAL_EVENT_TYPE,
    function(){ alert("Something is happening. I need to update my items!"); }
b.onClick = externalProcess;
w.show();
but I'm afraid this code—which, by the way, works!—leads us to an anti-pattern! Indeed, while we have to register and maintain a reference to the List widget in the external object (which is assumed to wrap the data), we still need to tell the list how to access the data provider in order to update the list items. The only benefit of the scheme above is that the external process can notify the list at any moment. Maybe this could make some sense in a non-modal context (palette), but this doesn't solve the original problem.
So, intuitively, I would tend to take the opposite view: instead of making the external process trigger some event in the UI when its data change, let simply provide a generic resync() method to the list widget. The paradigm, here, is that a data provider should always be an array structure whose elements expose a toString() or whatever feature. If the list widget has a reference to some data provider, then it can load and/or resync the list items using always the same abstract routines. Then we have something purely prototypal:
ListBox.prototype.load = DropDownList.prototype.load = function(/*obj[]&*/dp)
// =====================================
// A simple load method based on the assumption that
// all dp items offer a toString() ability
    // Manage a reference to the data provider
    this.properties||(this.properties={});
    this.properties.data||(this.properties.data=[]);
    dp?(this.properties.data=dp):(dp=this.properties.data);
    // Vars
    var CAN_SEP = 'dropdownlist'==this.type,
        n = (dp&&dp.length)||0,
        i, s;
    // Add the ListItem elems
    for (
        i=0 ;
        i < n ;
        s=(''+dp[i++]),
        this.add(CAN_SEP && '-'==s ? 'separator' : 'item', s)
        // One could improve the code to support additional
        // keys for: multicol, images, checks, etc.
    return this;
ListBox.prototype.resync = DropDownList.prototype.resync = function(/*obj[]&*/dp)
// =====================================
// Resync, or even reload, the data provider items
    this.selection = null;
    this.removeAll();
    return this.load(dp||null);
ListItem.prototype.get = function()
// =====================================
// Return an object instance from the DP (behind this ListItem)
    return this.parent.properties.data[this.index] || null;
From that point, what could the client code look like? We basically have two options:
#1 The process is non-modal and then the external object will invoke List.resync(…) when required; in this case it MUST have a reference to the widget.
#2 The process is modal, meaning that the 'external' object in fact is entirely interacted from the UI (e.g. via a button click); in that case no external reference to the list widget is actually required since the UI module itself knows exactly when a List.resync() is required, so why should it delegate the job? Here is a basic example in such a context:
// Let's have some arbitrary 'OOP' stuff available
var MyClass = function(uid,str)
{   // constructor
    this.id=uid||0;
    this.rename(str||'');
    // various methods
MyClass.prototype.rename = function(str){ this.name=str||'<unknown>'; };
    // toString()
MyClass.prototype.toString = function(str){ return this.name; };
var myDataProvider = [
    // some array of instances
    new MyClass(3, "Name 3"),
    new MyClass(5, "Name 5"),
    new MyClass(7),
    new MyClass(11, "Name 11, OK?")
var processChanges = function()
{   // emulate various changes in the data provider
    myDataProvider[0].rename("New name (3)");
    myDataProvider[2].rename("Finally Born 7");
    myDataProvider[myDataProvider.length] = new MyClass(13, "Did you miss 13?");
    myDataProvider[myDataProvider.length] = new MyClass(17, "Hello 17");
    myDataProvider.splice(1,1);
// Now the User Interface:
var w = new Window('dialog', "Example"),
    lb = w.add('listbox').load(myDataProvider),
    b = w.add('button', undefined, "Test Changes!");
lb.onDoubleClick = function()
    var someInstance = this.selection.get();
    alert( "My secret UID is: " + someInstance.id );
b.onClick = function()
    processChanges();
    lb.resync();
w.show();
Does it make sense?
@+
Marc