Phil Wallach

WHAT BROKE

This is the old version of the method.  It finds some specific views and scans their datapaths, to see if any entries match.  This version mostly worked fine, but occassionally it would fail, and finding the cause of the failure was proving difficult.

    <method name="check_ok" args="from, to">
        <![CDATA[
        for (var i = 1; true; i++)
        {
            var match = to.classroot.datapath.xpathQuery(
                'matches/match[' + i + ']/text()');
            if (match == null) break;

            for (var j = 1; true; j++)
            {
                var type = from.datapath.xpathQuery(
                    'types/type[' + j + ']/text()');
                if (type == null) break;

                if (match == type)
                    return true;
            }
        }
        return false;
        ]]>
    </method>

WHAT WORKED

I finally tracked down the problem; it occured whenever “to” was not replicated (i.e. there was only one).  So I assume that the replication manager was confusing my view navigation, as the number and type of views to navigate changed.

The solution is shown in the code below.  Basically I navigate the dataset directly, and avoid any view navigation.  Nothing can go wrong, right?

    <method name="check_ok" args="from, to">
        <![CDATA[
        var e  = to.datapath.dupePointer();
        e.selectParent(2);
        e.setXPath('matches');
        if (e.selectChild())
        {
            do
            {
                if (e.getNodeName() == 'match')
                {
                    var c  = from.datapath.dupePointer();
                    c.setXpath('types');
                    if (c.selectChild())
                    {
                        do
                        {
                            if (c.getNodeName() == 'type')
                            if (e.getNodeText() == c.getNodeText())
                                return true;
                        }
                            while (c.selectNext());
                    }
                }
            }
                while (e.selectNext());
        }
        return false;
        ]]>
    </method>

One thing that tripped me up early on is a know bug in the OpenLaszlo loader.  Basically, if a view is destroyed before the resource completes loading, then the loader chokes and nothing more is heard from it. 

Unsurprisingly, this is very very bad.

The bug is documented here:
    bug: destroy before resource is loaded leads to full load queue and hang

The fix is noted in the bug report.  Basically the following code is added to the application.

    <script>
        LzMakeLoad.unload = function ()
        {
            this.loader.unload( this.loader.mc );
        }
        LzMakeLoad.destroy = function (recur)
        {
            this.loader.unload( this.loader.mc );
            super.destroy( recur );
        }
    </script>