|Latest 7 Posts
| "Do I Need to Learn Java?": a brief conversation with a composite character|
Wed, Mar 26th 2014 176
| workaround for severe screen sharing bug in Mavericks|
Tue, Feb 4th 2014 93
| the more essential it is, the less passionate we are|
Sun, Feb 2nd 2014 78
Sun, Feb 2nd 2014 76
| Beyond Documents, part 2: a futuristic example|
Wed, Dec 18th 2013 78
| an easy way to give Domino Designer a ridiculous performance boost|
Wed, Dec 4th 2013 66
| they told me I could be anything|
Sat, Oct 26th 2013 86
Sorry, no records were found!
||when to create reusable controls
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.
Apr 13, 2012
Sorry, no records were found!
| Recent Blog Posts