A Couple Things I've Been Trying Out Lately

Oct 16, 2012 9:22 AM

Tags: xpages

I'm always trying to figure out new tricks and (groan) patterns for my XPages development, and I've had a couple trends and experiments lately that I think are worth mentioning.

First off, I've been doing a lot of source control stuff lately, but that's a topic for another post, currently in crummy-draft form.

Beyond that, I think I'll just start a list:

  1. The joys of ExtLibUtil. Historically, I've had a general "JSFUtil" class (with the name and original code copied from here), but I've stopped copying that around from DB to DB and instead have started only copying the methods I really need, instead looking first at the ExtLibUtil class. If you, like me, were slow to hear about this bundle of magic, I suggest you take a look.
  2. Using the DominoDocument class in a bean. This one I'm not sure of, but I figured I'd give it a shot. DominoDocument is one of the classes that the XPages environment uses to wrap a lotus.domino.Document object and make it more or less persist across serialization. I decided to try using this (and maybe the View equivalent later) directly on the theory that it might be a bit easier to use and maybe even faster. So far, it's been a bit of a hassle, but I do enjoy having the various DataObject methods available for passthrough for my bean for EL use.
  3. Dynamic form generation. This is along the lines of something I was discussing in a chat the other day - the notion of having some more default "scaffolding" for XPages, where it could pick up more of the existing database elements without having to actually write the form XPage (or drag the fields over). For a simple data-driven app, having an XPage that generates type-appropriate fields (including keyword values from drop-downs and the like) could save a lot of time up front.
  4. "Controller" classes to back XPages. I've started more often making classes meant to have a bit of knowledge about a specific XPage (say, Document.xsp paired with DocumentController.java) and putting almost all code in there. So, instead of having a bit of SSJS on the save button to handle saving the document, putting a confirmation in the flashScope, and handling a redirection (ideally by returning a string), I do something like <xp:eventHandler ... action="#{documentController.save}"/> and write all the code in Java. This is still slightly awkward, but it's another way to move code out of the XPage itself, aiming to go EL-only as much as possible.

Most little tweaks like these aren't huge on their own, but they all combine to make significant quality-of-life improvements. It's a great feeling to see my XSP markup getting leaner and easier to read day by day.

Commenter Photo

Ove Størholt - Oct 16, 2012 5:03 PM

Hi Jesse

I saw on your GitHub profile that you have "kind of" started a project running Minecraft as a Domino server task.

Sounds fun! What do you plan to achive?

Best regards from Ove

Commenter Photo

Jesse Gallagher - Oct 16, 2012 5:27 PM

I mostly did that because I didn't want to bother with setting it up as a Windows service. I considered trying some crazy stuff like actually loading up the server's Java classes directly and running it in-process, but I ended up just punting and running it via a system command. Every once in a while, I consider going back to that to try out other methods, but it hasn't been a high priority.

Commenter Photo

Tommy Valand - Oct 17, 2012 2:23 AM

Thanks for the tip about ExtLibUtil.. I hope they consider it a public API, so that our code won't break on future releases :)

New Comment