XPages in Domino Beat Maker Designer 8.5


If you've downloaded the public beta of Domino Designer 8.5 (often referred to as DDE, or Domino Designer in Eclipse), you should have seen the new design element called an XPage. If you have been living in a cave (hey, hobbit, leave the zombies alone...), XPages are a web-only (at least for now) canvas upon which you can lay out various controls to produce radically new Domino application designs. XPages are to traditional Domino web development what Notes 4 and LotusScript were to @formulas and then-traditional Notes client development. No kidding, XPages allow for a massive paradigm shift. 

Along with Andrew, Nathan and John (and quite a few others), I was at IBM in Westford this week for an class on XPages. We spent most of our time saying things like, "But that means we don't have to..." or "That means now we can..." The possibilities are endless. And I'm really - really - impressed. I've been beating IBM up privately over the fact that the shiny new LotusScript editor isn't in 8.50, and I thought that DDE without it wasn't enough of an improvement to bother with. I was wrong. Completely, totally, utterly wrong. If 8.50 included XPages and nothing else, it would still be the biggest thing that's ever happened to Domino development. Don't take my word for it, though - try it out yourself. And definitely keep an eye on the blogs over the next few months, because I guarantee Nathan's tutorial (on, get this, creating a JOIN in a Notes view - seriously!! Go read it now and come back, I'm not going anywhere...) will not be the last really cool XPages snippet you see.

Things that are difficult or impossible to do without XPages, but easy with them:

  • As mentioned above, Nathan already showed you JOINing data from multiple views and forms into a single view, in a quasi-relational way.
  • Similarly, performing quasi-relational updates to multiple documents based on a common key goes from being annoying to being completely trivial, because on a single XPages you can bind fields to multiple different forms/documents and save all the elements at once.
  • Paging through views, a la Google search results, which currently requires jumping through hoops, is as simple as dropping a control on a form. And yes, it handles responses and categories correctly. There are several styles built in, or you can choose to create a custom one.
  • Tabbed forms, currently hack-tacular, are also just a control on a form.
  • Multiple views and/or forms on one web page, which is another hack-tacular treat, typically requires iFrames and isn't supported visually in Designer, is trivial because XPages doesn't care how many view or table or field (or ...) controls you drop on a page.
  • Complete control over view output, including multi-row view entries, is as simple as using a repeat control to let you iterate over the view entries and do anything you want to them.
  • Search results, and their UI, and their sort order? Not a nightmare anymore. A simple matter of passing the search query to a page with a view control (or a repeat control), setting a 'search' property to reflect that query, and configuring the control and the XPage's layout however you want to see it. Passing that query involves using the application (or session or ...) scope, which you can see in Nathan's tutorial.
  • Date or time controls, list boxes, combo boxes, file upload/download, and rich UI controls in general, don't require hand-written html, css, and javascript - they're built into XPages as controls you can just drop on an XPage. 
  • AJAX partial page refreshes are as simple as choosing which elements to refresh.
That's not a complete list of rap beat maker by any stretch of the imagination. That's off the top of my head, based on things I was thinking about during the class. I bet the other geeks who were at the class would have a similar list containing the things that stuck out in their minds. The point is, there is so much power and flexibility available to us that the solutions we build are only going to be limited by our own imaginations. 

When I originally heard some of the capabilities we would be given by dropping controls on a canvas (seriously, IBM, that's what the name should be, not XPage), I thought we would be restricted by what those controls included when IBM built them. In other words, I thought this was just the Java applets all over again. And, as you should know by now, I was wrong. First of all, it's possible to build custom controls ourselves. Secondly, if we don't like the way the Designer's IDE is doing something on our XPage, we can go directly to the source and edit it manually. And finally, just about everything I saw, properties or events or labels, can be computed. In his 'join' tutorial, Nathan points out the 'little diamonds' that allow setting things dynamically, and the fact that they exist is extremely (or XTremely?) cool. 

Quick note: this deserves an entire entry, and I'm sure somebody will write it if I don't get to it first, but the server-side JavaScript we can use all over the place includes JS versions of the back-end LotusScript classes. So we not only have @functions in the JavaScript (you did read Nathan's tutorial, right?), we also have access to back-end LotusScript objects. If your primary skill as a Domino developer revolves around your ability to manipulate those classes, you aren't going to have much trouble moving to JavaScript on an XPage. LotusScript and JavaScript are syntactically different, but there are a lot of similarities, and going from one to the other isn't particularly difficult. 

Conclusions: These are MY conclusions, not IBM's or even Acme, Inc's (the legendary employer). And I am, as always, an idiot. Believe me at your own risk. 

  1. XPages will give Domino (web) developers a 500% productivity increase. For free.
  2. XPages will allow us to build applications we either cannot build at all or can build only at prohibitive cost and effort now.
  3. Once XPages are available in the client (not hinting at NDA secrets here, I'm not saying that will happen at all, much less any idea of when, but IBM has been asked to provide that by quite a few people, publicly, and they aren't idiots - they have to see the potential), forms, pages, framesets, subforms, navigators, outlines, and MAYBE even views become effectively deprecated - or at least unnecessary. This is huge. If XPages, and the custom controls that come with them, contain the entire application UI and business logic, why use the traditional elements at all? So many of our current limitations and restrictions go away with XPages, and they are so much more powerful and flexible that we won't WANT to use the old elements. And hopefully IBM will develop future XPages iterations in such a way that we don't HAVE to. I'd like to see a data schema editor, rather than binding my XPage fields to fields from a form. A decent XML editor would do quite nicely. I'd like to define view indexes, but not formatting, and I don't think I need to see the view in the current visual representation in order to do that (think SQL). Maybe those things are impossible, but that's what occurs to me when I think of a world where most of the current UI design elements are irrelevant.
  4. JavaScript is going to be the new LotusScript. Or at least that's MY theory. And this is very good news. It's a scripting language, which means it has a low entry point for newbies, but it also supports a very high level of sophistication (see: frameworks like Prototype, jQuery, Ext, etc). It is also extremely popular and well-known, which is a nice change for us Domino geeks.
  5. Number 4 does NOT mean LotusScript is dead. The core language hasn't changed much in years. The new developments are almost always in the Domino classes. I don't expect that to change. And I definitely expect to see a real LotusScript editor in Eclipse, in case you're thinking its absence from 8.5 means IBM won't build it at all - that's just not going to happen. Think of LotusScript the way we think of @formulas. They still exist and are often the best way to get something done, they are still expanding in functionality and power, but they are definitely superseded by LotusScript as the development language of choice. I just expect JavaScript to do the same thing to LotusScript, and LotusScript to remain a useful tool just like @formulas.
  6. XPages are NOT difficult to learn. They are very powerful, very flexible, and the possibilities may seem overwhelming at first. But - and remember, I'm the guy who ranted at great length on this site about how unnecessarily difficult it was (and is) to do CA and Eclipse plugin work, so I'm not a PollyAnna when it comes to this sort of question - it isn't difficult to USE the techniques. The difficulty will lie in learning what they all do, and figuring out which one is the best way to accomplish a particular goal. But the actual code and the techniques involved? Not hard at all.

Start working with XPages in the beta. Really. And be prepared to be blown away.