ShowTable of Contents
The XPages2Eclipse feature described in this article works similar to a technique called "XAgents", covered by blog posts of Chris Toohey and Stephan Wissel:
XAgents are an XPages version of classic web agents: a piece of server side JavaScript (SSJS) code which is called via a URL from the web browser and which produces content by writing text or binary data into an output stream.
Such an agent is useful when there is a need to programmatically create web content, e.g. web pages in a Domino based Content Management System, Office documents and spreadsheets, captcha graphics for authentication or to implement your own REST service.
So if there already is such a mechanism, why did we develop our own?
Well, when working with those XPages based agents, we faced several issues that our implementation solves:
Call code in other database
Let's say you have an application that consists of at least two databases, one application database and one that stores configuration data. For a clean architecture, you would like to put all configuration related code into the configuration database, including a REST API that you want to call from client side JavaScript code in the application, e.g. to read configuration data or store user preferences.
This works on the web, because you can request content of other databases without problems as long as the current user has sufficient access rights.
But unfortunately it's not possible with XAgents in the local Notes Client (XPiNC). There you can only call such an agent in the currently open database. You would need to move all your configuration code into the application database to make this work, which messes up your architecture.
The implementation we picked for XPages2Eclipse has a different approach: It uses its own servlet implementation to handle the requests and pass it to your JavaScript or Java code. This servlet is always available. It calls JS/Java code in local and even in server databases.
Parallel execution of requests
Routing many requests through a single XAgent XPage leads to bad application performance. The reason is that, up to Lotus Notes/Domino 8.5.2, code in an XPage runs sequentially for a single user. So if you let one XPage do a long running operation (e.g. output a large file or process many documents as part of a REST call), other XPages for the same user will wait until the operation is done (for experts: the XPage code is synchronizing on the HttpSession object while your code is invoked).
Our implementation in XPages2Eclipse does not do such a synchronization. Code execution occurs in parallel, only limited by the number of HTTP threads in the web server. You get maximum throughput.
Cache control for developers
An an XPages developer, you probably have experienced the issue that changes you make in Domino Designer sometimes are not visible after a page reload in the browser. The reason is that the XPages runtime caches the code for performance reasons and you often have to do a "restart task http" on your development server (which also restarts the JVM running XPages). This might be ok for web development on a local Domino server, but it's a real pain for XPiNC development. In that case, you have to restart the Notes client including Domino Designer!
XPages2Eclipse does have (OSGi) console commands that you can use to clear the caches we use: one for SSJS library content and another one for any Java class that your code is using.
Access to Notes Client APIs
Originally, the first idea behind our "JavaScript servlet" implementation was to make the XPages2Eclipse APIs accessible for developers who are not using the normal Dojo/Ajax request mechanism of XPages to call server side code from UI code, but prefer other frameworks like Ext.JS or JQuery. As you may know, Dojo and XPages client side runtime code can be disabled with a database property "xsp.client.script.libraries=none", as mentioned in this blog posting:
http://www.bleedyellow.com/blogs/andyc/entry/xpages_without_javascript_part_1_bye_bye_dojo?lang=en
In such a scenario, you could feed your UI elements through your own REST API and also implement the whole application logik as REST calls - a very clean approach, because the UI is completely separated from the backend code.
We support this approach by making an "eclipseconnection" object available as a global variable to your JavaScript code when it is run in the local Notes Client.
And since we found out that the technology is also very useful for Domino applications on the web (even without the "eclipseconnection" object), we added a switch to make it work on Domino servers.
Benefits
-build servlets and REST services in JavaScript instead of Java
-call code in other Notes databases, even in the local Lotus Notes client, clear separation of application code and a modular architecture
-performance gains compared to XAgent approach (XPage
Activation on Domino server
-Notes.ini variable for activation (global / per database)
mndX2ERPCEnabled_path_to_db_nsf=true
mndX2ERPCEnabled=true
-Highly optimized for performance
-same JavaScript engine for all all requests to one database
-SSJS library contents, Java class files and resources cached in memory
-OSGI commands to flush caches
x2ejs show
x2ejs drop all
x2ejs drop -n-
x2ecl show
x2ecl drop all
x2ecl drop -n-
Advanced features
-Include command
-code checks design element signature for all included libraries
restrictelevationmode=1
runelevated_C1257889004BEB96=true