Turn Collage applet into webswing

[anupama]

Related to turning Phind applet into webswing ​https://trac.greenstone.org/ticket/964

Again, webswing supports JApplets but not Applets. However, there was little porting involved as there was no real java.awt gui used. There were calls to dangerous deprecated methods Thread.stop() and Thread.destroy (and deprecated Applet/Container mouseDown() method).

Collage was tougher to get running, as it wouldn't even run in the appletviewer initially, nor would ever download when I got it to run (SecurityExceptions when downloading). Then the internal threads needed to be halted on user exit in a less dangerous way then deprecated Thread stop() and destroy() methods. Once turned into a webswing application, it took time to find how to stop the threads from continuing to run when the user navigated away from the page: the kill() JavaScript webswing command. This worked when webswing was run as application but not as webswing applet. Dr Bainbridge helped work this out, as well found the solution for how to pass custom (dynamic) parameters from JavaScript to the applet's fixed parameters already present in webswing.config.in. He also worked out how to use the original XSL applet element, so that the custom GsdlCollageBrowse GS3 runtime service and related changes created could be phased out again.

The steps in porting GsdlCollageApplet to being run by webswing were:

• Copying the GsdlCollageApplet classes from Greenstone 2 into GS3's src/java/org/greenstone/applet and changing their package names accordingly. The first aim was to get it all to compile.

• Getting it to run at all against the small beatles tutorial collection

• appletviewer would not run against the default classifier CL3 tab with adjusted applet element. It produced a Magic Number error (this was not a Java version error), generally produced if there's a misconfiguration on the server. This later turned out to be because the codebase for the applet wasn't right for when run through the appletviewer)

"​http://localhost:8383/greenstone3/library/collection/smallbea/browse/CL3"

Eventually this URL would be made to work and would be the preferred way to try to run the Collage applet through the appletviewer, though appletviewer still runs in a sandbox and throws up security exceptions when Collage attempts to download.

• creating a temporary GS3 runtime service class outputting the applet element (since JPhind had a Service that worked) and supplementary changes in the perl code and XSL producing a dedicated CL4 tab in order to see the applet run at all.

• Now the appletviewer run against that service URL would show up the applet but downloading would fail, since the appletviewer's security sandbox prevented URLs from being downloaded.

appletviewer "​http://localhost:8383/greenstone3/library?a=a&rt=d&s=GsdlCollageApplet&c=smallbea"

(This URL is now phased out)

• Got the GsdlCollageApplet to run as an application and fixed up downloading

• Replaced deprecated mouseDown() call

• Followed Java Thread API suggestions for replacing calls to deprecated and dangerous Thread.stop() and Thread.destroy() called by internal threads.

• Made the GsdlCollage be run in application mode by webswing

• When the user navigates away from the page, the GsdlCollage application continued to run (as seen in log messages). The JavaScript webswing kill() call on the instance finally stopped it.

• It would be better to run as applet: as the application version could be moved around and the exit button clicked. Dr Bainbridge worked out how to use customArgs in webswing.config.in to pass dynamic customised parameters from JavaScript to the webswing run in applet mode.

• kill() on the webswing instance did nothing any more if it was run as an applet. Dr Bainbridge worked out this was because there was no registered shutDown handler. So then we registered one to do the clean up.

• classifier.xsl produced the XSL editable applet element for GsdlCollage (CL3 tab for tudor collection), which was preferred to the custom GS3 service temporarily created (GsdlCollageBrowse.java, and the temporary new CL4 tab).

Dr Bainbridge got the classifier.xsl applet HTML element to work with the GsdlCollageApplet class, even when run through the appletviewer: the codebase attribute on the applet element needed changing.

The GsdlCollageBrowse service (that generated a hardcoded applet element to get me past such issues in the meantime) and related changes could thus finally be phased out.

• All dynamic parameters handled. Further, rewrote JavaScript to have default fallback parameters for the rest of the parameters. Then read parameters set on any applet element used as a "shim", using fallbacks from what JavaScript worked out.

The applet element likewise set its dynamic parameters from the pageResponse XSL.

• build.xml would copy out the webswing-api.jar (if it exists) into the web/applet folder, as there are webswing library imports and calls being made in the GsdlCollageApplet and JPhind code now, so the webswing-api is needed during compile and runtime.

• There's further a webswing.config.application and webswing.config.applet to swap between when running Phind/Collage as webswing applications versus webswing applets. Another change that must be made is in webswing-phind.xsl/webswing-collage.xsl: set isWebswingRunAsApplet to true if run as applet and to false if run as application.

• It turned out that several Collage (but not Phind) applet parameters and even width and height as geometry dimensions were set as classifier options such as through GLI, appearing in collectionConfig.xml. These would need to appear in the applet element, so these were now pushed out by the perl code (buildConfig.xml) to be available in AbstractBrowse service as options subelements on the classifier, and AbstractBrowse then pushed any options available on classifiers out onto the pageResponse. The XSL then read these into the applet element.

• Any width and height set on a Collage or Phind applet element would need to be preferred to the width and height on the collage/phind webswing div element.

• Collage used to print the message "Downloading..." forever when the GS3 server was not running (and I guess also if there was no internet connection), so now it sensible stops in such a case after feedback to the user. It would then further quit if run as an application.

[anupama]

Commits for getting GsdlCollageApplet to work with webswing:

​https://trac.greenstone.org/changeset/38853 to ​https://trac.greenstone.org/changeset/38855

​https://trac.greenstone.org/changeset/38871 to ​https://trac.greenstone.org/changeset/38874

​https://trac.greenstone.org/changeset/38880, ​https://trac.greenstone.org/changeset/38881

​https://trac.greenstone.org/changeset/38884 to ​https://trac.greenstone.org/changeset/38890

​https://trac.greenstone.org/changeset/38908

​https://trac.greenstone.org/changeset/38921, ​https://trac.greenstone.org/changeset/38922

​https://trac.greenstone.org/changeset/38925 to ​https://trac.greenstone.org/changeset/38933

​https://trac.greenstone.org/changeset/38935 to ​https://trac.greenstone.org/changeset/38951

​https://trac.greenstone.org/changeset/38956, ​https://trac.greenstone.org/changeset/38957

​https://trac.greenstone.org/changeset/38964 to ​https://trac.greenstone.org/changeset/38968

[anupama]

To swap between running both Phind and Collage as webswing applications versus webswing applets:

1. In ext/webswing/web/etc, there's a webswing.config.application and webswing.config.applet. To swap between when running both Phind and Collage as webswing applications versus webswing applets, copy the appropriate config file into web/ext/webswing/etc as webswing.config.in.

2. Then edit the XSLT:

1. In web/interfaces/default/transform/PAGES/webswing-phind.xsl, set isWebswingRunAsApplet to true if phind is run as webswing applet and to false if run as webswing application.

2. Similarly, in web/interfaces/default/transform/LAYOUTS/webswing-collage.xsl, set isWebswingRunAsApplet to true if collage is to run as webswing applet and to false if run as webswing application.

To just run one of phind/collage as applet and the other as application:

1. Copy one of the webswing.config.application|applet from ext/webswing/web/etc across into web/ext/webswing/etc as webswing.config.in.

2. Then in the nwe web/ext/webswing/etc as webswing.config.in change the appropriate application's config settings by copying it from the other file webswing.config.application|applet in web/ext/webswing/etc.

3. In web/interfaces/default/transform/PAGES/webswing-phind.xsl, set isWebswingRunAsApplet to false or true as appropriate and likewise in web/interfaces/default/transform/LAYOUTS/webswing-collage.xsl

[anupama]

Assuming you have the "small beatles" (smallbea) tutorial collection built and running with default GS3 settings:

• Running GsdlCollageApplet as applet in the appletviewer is not fully successful because of security issues downloading URLs in the appletviewer. The appletviewer command is:

appletviewer "​http://localhost:8383/greenstone3/library/collection/smallbea/browse/CL3"

• To run GsdlCollageApplet as command line application, see the command for the method comment to main() at the bottom of the src/java/org/greenstone/applet/GsdlCollageApplet/GsdlCollageApplet.java file.

[anupama]

​https://trac.greenstone.org/changeset/38989

and especially ​https://trac.greenstone.org/changeset/38991 with minor adjustments in ​https://trac.greenstone.org/changeset/38992

These changes remove the applet shim from which potential (but currently non-existent) Collage classifier user configurable settings could be drawn to instantiate the Collage webswing app.

Dr Bainbridge suggested that applets were defunct (so it might not be sensible to leave them lying around on the page) and in any case gsf variables will serve better than an applet shim for obtaining the user-set Collage classifier options that were made to appear in the pageResponse.