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.
locating XPage components with XspQuery
Sun, Apr 14th 2013 12:00a Tim Tripcony Several years ago, I wrote a utility Java class designed to make it easy to search for components within the current XPage instance based on various criteria. I've found it enormously useful, and, apparently, so has Keith Strickland, because he added it to org.openntf.xsp.extlib, complete with a few refinements. As an example of how you might use this, examine the following line of code:
List requiredFields = new XspQuery()
.loc [read] Keywords: ldd
your how is not your what
Wed, Apr 3rd 2013 11:36a Tim Tripcony I've noticed a pattern emerging when I'm asked for help with XPages. Here's a representative conversation:
"I'm trying to do [X] and it's not working. How can I do that?"
"What are you trying to accomplish?"
"I already told you. I'm trying to do [X]."
"No, that's how you're trying to do it. What are you trying to do?"
For example, replace "[X]" with "reach into a repeat control from outside it" (since this has become the most frequent topic I'm asked about [read] Keywords: xpages application
my new favorite quote
Sat, Mar 23rd 2013 5:20p Tim Tripcony "We go about our daily lives understanding almost nothing of the world. We give little thought to the machinery that generates the sunlight that makes life possible, to the gravity that glues us to an earth that would otherwise send us spinning off into space, or the atoms of which we are made and on whose stability we fundamentally depend. Except for children (who don’t know enough not to ask the important questions), few of us spend much time wondering why nature is the way it is; where the [read] Keywords: wiki
Taking the scary out of Java in XPages: Prologue
Tue, Feb 26th 2013 9:50p Tim Tripcony The discussion following my last post made stark the need for greater availability of information that makes the nature of Java more accessible to Domino developers. Credit for the title of this post goes to Declan, who is considering writing a series of blog posts on this topic. I will be doing the same; hopefully there will be a fair amount of duplication. As David Leedy is fond of stating, it's a good thing when several people share the same information, because that makes it easier for the [read] Keywords: domino
Passthru vs. component - my perspective
Sat, Feb 16th 2013 9:40p Tim Tripcony Paul Withers posted a thorough article explaining the differences between namespaced XPage components (e.g. ) and their corresponding passthru elements (e.g. ), providing numerous examples of what actually happens when these objects are constructed. I've always heard (and often repeated) that passthru elements are more efficiently processed than their namespaced equivalents, so Paul's post inspired me to offer my own perspective.
Simply put, there's practically no difference... but there a [read] Keywords: acl