Tip of the Iceberg

Category xpages
A common misconception, due primarily to the content of this blog and my occasional public speaking, is that I write XPage applications for a living. But that's just my hobby. My day job is writing extension library controls for others to use in their XPage applications. And for me to use in my hobby apps too, I suppose. As such, my Package Explorer might look subtlely different from yours:



Because the differences are likely subtle, let me call attention to just a few:

• Only the Package Explorer is in my perspective, not the Application Navigator. This is because I write library controls, not XPage applications.
• The menu bar at the top indicates this is Eclipse, not Domino Designer. This, again, is because I write library controls, which doesn't require Domino Designer. Periodically, as changes to a given library are deemed stable, I deploy them to an update site from which others can then install the library into Designer. But to do the development, I don't actually need to have Designer open.
• The system path of the JAR files referenced as plugin dependencies for the project expanded in the screenshot refer to "xpagessdk". This is a nod to the XPages SDK project Nathan contributed to OpenNTF on Monday. This project makes it easy to configure a vanilla Eclipse installation for XPage control library development without the need for the Expeditor Toolkit.
• Finally, as may already be obvious due to the name of the JRE, the location of the menu bar, the colored circles above the toolbar, and, of course, the frickin' Apple logo, this Eclipse installation is running on a Mac. Not inside a Windows VM in Parallels burning through half my RAM... just a Mac. And yet somehow there are no nasty little red X icons telling me my projects won't compile. I can perform my primary job functions as a Domino developer without getting hassled to reboot to install Windows updates that fix what Microsoft should have gotten right the first time... or consigning the bulk of my CPU's processing power to an antivirus program intended to protect me from script kiddies exploiting the weaknesses for which Microsoft hasn't yet released a Windows update. I can just open the lid of my MacBook Air, write some code, commit it to the source repository, then close the lid again. I haz a happy.

Let me be absolutely clear about one point: this is not a Domino Designer client for Mac. It doesn't (yet) understand the Designer VFS, so you can't just install the XPages SDK on your Mac and then start developing XPages on that Mac. You still need Designer for that (and, for Designer, you need Windows). However, you can develop artifacts that facilitate the development of, and enhance the user experience of, your XPage applications: controls, renderers, data sources, converters, validators, managed beans, phase listeners, custom EL bindings... the works.

I'm often asked to define the benefits of shifting most, or all, of an XPage application's logic from SSJS to Java. Those benefits are legion - improved performance, increased compile-time error management, true object oriented program structure, straightforward consumption of third-party libraries, and so on - but now you can add one more to the list: the higher the percentage of your application logic resides in Java, the less significant a role your operating system plays in your capacity to develop that logic. Write the bulk of your code on whatever machine you prefer (or are provided), in a comparatively lean and clean installation of Eclipse, and minimize the extent to which Designer - and, therefore, Windows - is required.