dominoGuru.com
Your Development & Design Resource
Roadmap to XPages Application Development
06/20/2011 12:12 PM by Chris Toohey
When I was invited to speak at the XPages Guru webinar earlier this month to help jumpstart June as the Learn XPages month... I was assigned a rather interesting subject: defining a roadmap for IBM Lotus Notes Domino Application Developers to XPages.
Armed with 5 slides (4 if you discard the intro/cover) and approximately 7 minutes of the hour-long webinar, I attempted to convey my individual experience both with learning XPages and what I believe are the key factors in learning and successfully employing XPages in your daily application development efforts.
My first slide, The Paradigm Shift, set the tone.
XPages can deliver amazing functionality and extend Lotus Notes and Domino far beyond any previously conceived limitations...
... but you need to embrace the change.
Simply put, XPages is an amazing technology... but you will not get the most out of it (or quite possibly not even understand its full potential) unless you understand that there are conceptual differences between Traditional Lotus Notes Domino application development and use of XPages.
My next slide, Embracing the Change, outlined three (3) of the biggest blockers that I think the majority of Lotus Notes Client application developers will encounter:
- Object-Oriented Programming
- NotesDocuments
- NotesItems
- [Possibly] unfamiliar languages & techniques
- Using HTML, XML, JavaScript, CSS, and Java
- It's new [to you]...
- Don't get frustrated, it was new to everyone!
The idea of employing OOP in your daily application development efforts isn't new for IBM Lotus Notes Domino application developers... mostly. Understanding that you're dealing with an individual object -- be it a NotesDocument or even an individual NotesItem -- and that via direct object manipulation or iterative cycling can allow you to deliver features within your applications previously thought not possible. Understanding OOP in the LND world is critical to advanced XPages application development.
For example, let's say you have a history NotesItem on all of your documents that tracks a combination of timestamp with the current status of the document in the application or business logic lifecycle as well as the current user updating the document.
Most Lotus Notes Client application developers would create a multi-value Computed Text Field named history and use the following @Formula:
@Trim(history : @Text("[" + @Text(@Now) + "] " + status + " --
" + @Name([CN];@UserName)))
But what if you update the NotesDocument from a View Action? How about an Agent?
An OOP approach to this would be to create your own
updateHistory()
function that would handle the update, writing to
the history NotesItem as an object vs. treating it like a field on a UI
Form.
Unfamiliar languages and techniques can block platform developers. From simply not knowing a given language to not understanding that it can be critical to both the success of a given project and your success as a developer to learn a new language or technique. Reluctance to pick up on a new technology will destroy any XPages development initiative... since for many of you XPages is itself a new technology.
And finally a rather tricky one, but something that I think many long-term Lotus professionals will run into. Frustration with something new.
Look, we've all been there. Hell, there are still days when I'm looking to achieve some functionality that I think should be a rather simple matter but I find -- often after a series of IM conversations with friends and fellow community members -- that I was approaching the problem from the wrong angle.
Where you are an expert LotusScript developer, you're back to Hello World with XPages... And where it is absolutely an amazing thing that most of our epic hacks for the platform are no longer needed, you need to understand and embrace that it's going to require a new angle, a new view, and quite possibly might rely on you hitting F1 (or leaning on people who've been doing it slightly longer than you have) for some guidance.
Don't get too frustrated!
My next slide spoke to Some common mistakes that people often make with XPages.
- "I'm going to use XPages for my next project…"
- Complete novice project usage could result in:
- Delayed Deliverables
- Frustration from "learning curve"
- Management's dismissal of XPages as "viable solution"
- "I'm just going to download the 'XPages Framework' template…"
- It's simple… once you understand what it's doing!
These are pretty self-explanatory. Don't go gung-ho after your first exposure to XPages and conclude that you must abandon all Traditional Lotus Notes Domino application development techniques. Things will not end well for you.
You need to evolve your skillset by adding XPages to your bag of tricks. To do this, you need to start of small and build both a comfort level with the technology and an understanding of where it can be best employed.
My final slide in the deck was a simple roadmap table, which illustrated 4 milestones for this evolution:
Stage One | Stage Two | Stage Three | Stage Four |
---|---|---|---|
Simple Add-ons | Evolving Existing Apps | Standalone/New Apps | SaaS, APIs, and Beyond |
|
|
|
|
|
|
|
|
Stage One: Simple Add-ons
You're just getting started... so don't try to build Rome in an afternoon. Start off by creating XPage-based alternate UIs and UXs for Web Browser Clients using the RAD techniques and as many menu/dialog-driven features as possible.
Deliver a few quick-wins for your users while cutting your teeth, and read as many intro-level tutorials as your Google-Fu can return!
Stage Two: Evolving Existing Apps
In this phase, you can start to dive deeper into XPages application development while still leaning on the designs and scope of your existing applications.
See, a big mistake that most people make when getting into XPages development is that once they get some of the basics down, they hit Ctrl+n and start writing a new app. The problem here is that you don't have the confines of scope (or, let's be honest... you won't stick to the scope).
Evolving an existing app actually restricts you, as you'll be looking for similar functionality and user experience instead of testing the full capabilities of XPages via a playground of shiny and whirring that might look decent on a demo but will ultimately not help you master XPages.
Stage Three: Standalone/New Apps
Now that you've evolved some applications, it's time to Ctrl-n and write your standalone apps using XPages. At this point, you will have mastered RAD XPages and have no reservations about using the Source Pane. You will have been using HTML, CSS, JavaScript, and learned enough about Dojo and how to integrate with it to achieve your desired goals that you can really start to extend your XPages skills.
Stage Four: SaaS, APIs, and Beyond
There have been several awesome projects that have leveraged XPages... but my absolute favorite to date has been TSAzr.
This application uses XPages to consume all requests sent from the TSAzr iOS application and maintains all data via scoped variables.
Rather simple functionality (and an expertly-timed release) aside, this app shows the potential for XPages as an application platform that reaches far beyond the previously-conceived boundaries of IBM Lotus Notes Domino.
Conclusion...
Here's the abstracted slidedeck for those of you interested in seeing the pretty pictures that I included with each slide:
My advice to any Lotus development professional is to learn XPages... if for nothing other than an opportunity to learn HTML, CSS, JavaScript (and eventually Java) in a familiar and increasingly-documented arena.
XPages are certainly the future of IBM Lotus Notes Domino, and learning more transferrable skills will make you a better developer and ultimately more successful.