Master Series: Planning your LJO strategy
ruthspeaks 2700006S3X Visits (940)
One of the things about WEF, as a development tool, is its friendliness to plugging in custom Java code. And so you know the basic mechanics but people don’t talk a lot about the strategy of how to organize the LJOs that you do create. As you might imagine, there is value in putting a little thought into this, and the following ideas have evolved into a pretty useful strategy.
by Kevin Wilmeth
One of the things we love about IBM Web Experience Factory (WEF), as a development tool, is its friendliness to plugging in custom Java code. And by this we mean optionally plugging in code, only where it is truly needed, not being covered natively by the buider set. You can do this in…a lot of places, including places people wouldn’t necessarily even think to look. (Ironically, the full extent of this capability often eludes the highly experienced Java programmer, who may be mentally wired in to a different way of organizing code, and not intuitively “see” how WEF presents itself for such extension.)
And so we have the humble “Ell Jay Oh” as part of the toolkit—we teach its basic mechanics within the first five days of training—but we don’t talk a lot about the strategy of how to organize the LJOs that you do create. As you might imagine, there is value in putting a little thought into this, and the following ideas have evolved into a pretty useful strategy that I like more the more I use it.
LJO layers that work together
The big inspiration for my strategy came some years ago now, when the Domino builder set first became available and I worked on a number of projects that needed it. As a longtime Domino developer before I discovered the Factory, I understood that really getting value out of Domino meant going beyond (way beyond) the limited capacity of the builder set. And so lots of core Domino functions wound up as Java methods in LJOs. Enough so, that I had to do something to organize them!
At some point, it dawned on me to look at my LJOs in layers, much like you’d think of SOA layers. It turns out that there are two very clear separation points that you can lean on to do this: IXml, and WebAppAccess. This implies three layers of LJOs in your project architecture.
Continue reading: http