TW 2.7.0

[JohnHind]

Simon,

Our changes to TW to support these have made it into the wild in TW 2.7.0 (but unfortunately they do not seem to have updated the "upgrade" link which is still offering 2.6.6).

This allows radical simplification of the plugin to:

if(config.userAgent.indexOf("appjstw") != -1)
{
    // The AppJS browser can always load and save using its external functions.
    readOnly = false;
    window.allowSave = function()
    {
        return true;
    }

    window.getLocalPath = function(fileUrl)
    {
        return window.externalJsPath(fileUrl);
    }

    window.saveFile = function(filePath,content)
    {
        return window.externalJsSave(filePath,content);
    }

    window.loadFile = function(filePath)
    {
    return window.externalJsLoad(filePath);
    }   
}

Or alternatively we would be able to use the code injection (prefixing) model to avoid the need for the plugin at all.

Sadly AppJS does not seem to be very active - so appjs-TiddlyWiki still does not work properly on Mac because the confirmation dialogs have still not been implemented.

What do you think is the best way forward for appjs-TiddlyWiki?

• John

[sihorton]

Cool well done John that is excellent, would be good to update the plugin. AppJS is waiting on a major rewrite to re-architecture and solve most of the current bugs / problems once that is done it will be an even better platform to build on.

I think that we could implement the confirmation dialogs ourselves in HTML but the tricky part is the blocking i.e. you can write in code:-

var a = confirm("are you sure?"); //the code after this line is not executed until they click ok alert("you clicked:",a);

There are a number of approaches to achieving the same functionality (without having to change any existing TikiWiki code), how much are confirm dialogs used in TikiWiki plugins etc?

[JohnHind]

Yes, on the face of it there is nothing preventing direct replacement of the confirm, prompt and alert methods with HTML replacements just by overwriting the window object methods. Put these in the preemptable "window.tweakConfig" method I (cleverly) snuck in the same change request and this would even work for plugins too. But as you point out, making these modal is the problem. But the principle is good if we could make it work - indeed I think AppJS went down the wrong path adding in "window furniture" like menus - if the user wants these they should do them in HTML inside the (plain) browser window.

What do you think about maintaining the plugin versus adapting the AppJS router to prefix code to unmodified TW? This would remove the need for my AppJS "hack" to allow setting the userAgent string.