Most of us understand why our code should be reusable, even if it isn't: keeping duplication of effort to a minimum, such as the capacity to apply a fix or enhancement once and gain distributed benefit. In terms of XPage controls, there is also a lot of information available about how to structure code to make it reusable. For instance, I recently submitted two guest tutorials to Notes in 9: an example of how to implement an in-view-edit Custom Control, and a demonstration of converting a Custom Control to a library component. Not much has been said, however, about when to make the effort of creating these types of reusable artifacts.
Many of us are busy. That's a very good thing... people want something from us, and they're willing to pay for the result. Not everybody can say that right now, so even those of us with unrealistic deadlines are comparatively fortunate. But, even in our haste to deliver what is expected of us, there should ideally be some balance that allows us to give our employers and customers their money's worth. And that can't truly happen unless we're structuring our code - at least a little bit - to be reusable.
So... amidst the tight timelines and pressure to deliver, when do we take the time to create these types of artifacts that may only pay for themselves in the long run? In my experience, there are two ideal opportunities to do just that: at the beginning of a project, and at the end.
Particularly when there are few (or no) live XPage applications in your environment, it can be difficult to identify potential areas of duplication. And, of course, regardless of how many applications are already in place, it can be difficult to convince project stakeholders both to pay and to wait for the extra time it may take to perform this manner of design analysis up front. So in many cases the only realistic opportunity to identify candidates for reusability is once the project is complete. Many organizations' processes include some form of "Lessons Learned" phase for each project (even if only in principle, not necessarily in practice). This can be an excellent time to review the end result to identify which portions of the design could be packaged for consumption in subsequent projects, thereby reducing both the cost of that subsequent development and the effort required to maintain all applications that consume those artifacts.
An even better time to do this analysis, however, is during the initial design phase of the project. In a sense, identifying what should be wrapped in a control and what should be page-specific is often easier to envision prior to actual development, because these are primarily structural decisions, not logical decisions. Put another way, in contrast to other reusable code, like script libraries, you don't have to map out the processes of the application to predict that its interface will include common features as users navigate from page to page. "Low-fidelity" prototyping (using tools like Balsamiq Mockups, Evolus Pencil, or even just pen and paper) is a great way to visually identify these areas of potential duplication prior to even opening Domino Designer. This makes it likely that, even within the scope of a single project, the application will be faster and cheaper to develop and easier to maintain. When extended across numerous projects, this process can drastically reduce total cost of ownership and implementation.
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()
.addInstanceOf(UIInput.class)
.addEquals("required", true)
.loc [read] Keywords: ldd
lotus
dojo
java
javascript
openntf
oracle
server
389
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
xpages application
java
154
SSJS is a crutch
Fri, Feb 22nd 2013 10:50p Tim Tripcony I've been debating for quite a while whether I should write this post. It obviously makes a potentially controversial statement. A fellow developer who knew I was drafting it put my hesitance into perspective: "you really want to be that guy?" This was my response:
I want to be the guy who saves people pain. But sometimes to do that, you have to tell your friend if she wants to stop being punched in the face, she needs to leave the guy who keeps punching her in the face.
This post is ju [read] Keywords: agent
domino
formula language
ibm
lotus
lotusscript
notes
xpages applications
development
java
javascript
openntf
wiki
125
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
domino
xpages application
development
properties
security
136
org.openntf.xsp.extlib
Mon, Jan 21st 2013 5:20a Tim Tripcony About 18 months ago, I created an OpenNTF project called Community Control Library. The fundamental reason for creating the project was my belief that the single factor keeping the Domino community from realizing the true potential of the platform is the assumption that the XPages Extension Library is the extension library, not an extension library. Let's briefly revisit its history:
IBM starts an internal project, code named "Porus" (in reference to the Greek / Roman god of plenty), inte [read] Keywords: domino
ibm
notes
policies
xpages application
applications
best practice
community
development
openntf
wiki
