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.
workaround for severe screen sharing bug in Mavericks
Tue, Feb 4th 2014 3:40p Tim Tripcony I love my MacBook Pro... once you go Mac, you never go back. Unfortunately, there's a massive problem with screen sharing once you've upgraded to Mavericks: models that have both an "integrated" (low-power) and a "discrete" (high-power) video card started using a feature that Apple calls "Dynamic Switching". This feature attempts to maximize battery life and other aspects of OSX performance by toggling between the display modes depending upon what you're trying to do at the time. As a r [read] Keywords: apple
an easy way to give Domino Designer a ridiculous performance boost
Wed, Dec 4th 2013 4:10p Tim Tripcony From the top-level menu, select "File > Preferences"
Choose "General > Appearance"
Change the option labeled "Current presentation:" from "Styled Presentation Factory" to "Classic Presentation"
When prompted, allow the "workbench" to be automatically restarted
I do feel obliged to warn you that the behavior of Designer after following the above instructions can be extremely disorienting. For instance, removing an app from the Applications navigator no longer cau [read] Keywords: domino
the reason panel data sources can't be accessed outside the panel
Thu, Oct 10th 2013 7:40p Tim Tripcony Marky Roden recently called attention to a lesson he learned: if you associate a data source with a specific panel, you can only refer to it by name via events (or attributes) attached to components inside that panel. There are two very specific reasons for this:
Hierarchical component processing
The role the requestScope plays in variable resolution
While there are no doubt some subtle exceptions to this premise, you can consider all runtime processing of XPages to be hierarchical. To co [read] Keywords: xpages application
quick tip: persistent query string parameters
Thu, Aug 22nd 2013 8:00p Tim Tripcony Here's a handy bit of code to drop into the afterPageLoad event of your XPages:
One of the best characteristics of XPage applications, in contrast to their non-XPage Domino counterparts, is their statefulness. The capacity to maintain consistency of data, user behavior, and user preferences between interactions with the "current" page, across pages within an individual user session, and even across all (or select groups of) users of an application is sim [read] Keywords: domino