Despite my grousing about the state of programming for Domino in general and Designer in particular, I'm still mostly a fan of XPages. I use it for my guild's web site and pretty much every new project at work. However, I haven't been able to crack migrating my main work database template over.
Without getting too much into it, the point of the template is to create one database per project to act as a project web site listing online events with arbitrary registration forms and exit evaluations (among other things). Except for custom changes, everything is done via the normal Notes client, not Designer - pages exist as documents with a Body rich text field and associated data and register forms/exit evals, crucially, contain a set of response documents describing their fields. It's important to keep everything as visual as possible, because the users (the people at my company that set up these web sites) are not programmers.
I scrupulously try to avoid modifying the design of the database, so I go out of my way to do custom work via the existing mechanisms as much as possible, and I make pretty good use of rich-text-isms like embedded views, tabbed/computed tables, attachments, buttons, and computed text. In the case of the generated forms, fields can be placed either automatically (with a surrounding template of HTML per-field) or directly into the rich text body via <%FieldName%> placeholders (creating an experience like form design in Designer). Additionally, I have "WebQueryOpen" and "WebQuerySave" fields in the documents for formulas that I pass on into @Eval() in the equivalent places in the actual forms; most of the time, I use these for running agents.
Of the various potential show-stoppers, I think computed text fares the best. For one, it mostly worked - the computed formulas are indeed evaluated and the result is put into place correctly. However, they don't have the same environment you get with the "classic" design elements. The big one that I ran into immediately was @UrlQueryString(...) - it appears that the rich text renderer doesn't inform the rich text about its web environment completely. Prior to 8.5.3, "Display XPage instead" pages didn't know about the real URL, so they couldn't get query parameters at all, but 8.5.3 appears to pass that information along properly. So that means it MIGHT be fixable, if I find a way to properly set fields in the document before the rich text is rendered, so I can set QUERY_STRING - if I can do that, either @UrlQueryString(...) will work or I can manually parse the string as needed.
They work! ...ish. It looks like icon columns get their URLs a bit messed up, but I can't think of a time when I actually used them, particularly in a situation where I couldn't just write out the URL myself.
From a cursory glance, I think I'd be SOL when it comes to these. Tabbed tables render flattened out and computed tables don't seem to work.
These show up as "(See attached file: foo.jpg)". So... not functional. I might be able to fix it by using a filter on the text to replace the HTML with a link to the document, but I don't know if I could get the attachment image properly. Attachment images aren't amazing, but sometimes they do the job.
In some cases, I could run the formulas through session.evaluate(), though I'm not even sure queryOpenDocument/postOpenDocument let me hook into the right spots (sometimes I set fields on document open). I don't think that would run agents, though, so I'd be stuck trying to parse out the text to look for @Command([ToolsRunMacro]; "...").
It's a lot of hurdles! I'd love to switch over to XPages, particularly since, for everything that's more difficult than using classic elements, there are 10 things that are way easier. It'd just be quite an investment of time to merely get up to par with the functionality I already have, if it's even possible in all cases.
The Curse of TMTOWTDI
Tue, Nov 26th 2013 2:17p Jesse Gallagher TMTOWTDI is a Perl-ism, standing for "there's more than one way to do it". It
is often a blessing, particularly in the context of Perl, in that it results in
multiple synonymous ways to accomplish the same task, each of which fits best
in a different context.
However, as you might expect, this is a double-edged sword that can lead to
messy code and a difficult learning curve. It's this negative context that
bites the XPages platform in a number of ways.
One way is relatively benign bu [read] Keywords: domino
Building My App On Custom Renderers
Sun, Nov 24th 2013 7:18p Jesse Gallagher A little while ago, I mentioned how I have become smitten with custom renderers
- Java classes that take XPage components like application layouts and widgets
and render them in custom HTML. Though I've had a lot of other things to work
on in between then and today, my ardor for the subject has not dimmed. So
today, I mostly completed the process for my task-tracking app.
At a high level, the app is a fairly typical web app built using the
popular-for-good-reason Ace - Responsive Admin Te [read] Keywords: admin
Internalize This Deep Wisdom
Tue, Nov 19th 2013 5:17p Jesse Gallagher Toby Samples tweeted earlier an old blog post by Jeff Atwood about the virtue
of minimal code, and I think everyone would be well-served by reading it and
the articles it links to (the Wil Shipley post has since moved (incidentally,
if you don't currently pay attention to Wil Shipley, you really, really should
I've found maintaining the goal of reducing the conceptual weight of my code to
be the most valuable tool in my belt. One way of doing that is to separate out
unr [read] Keywords: xpages
My Current Model Framework, Part 1
Sun, Nov 17th 2013 10:21a Jesse Gallagher As I do from time to time, I've recently been taking another stab at a standard
model framework for my XPage apps. My latest one has been proving its worth in
a couple apps I've been writing lately, and I'd like to go over the general
goals and advantages of the way it works.
The framework is focused on a couple main ideas:
Low Overhead. The Java language requires a certain amount of overhead to get
anything done, but I want to minimize that. The task of defining a new model
object con [read] Keywords: domino
I Am Terribly Excited About Custom Renderers
Tue, Nov 12th 2013 6:10p Jesse Gallagher It's much to my chagrin that it took me until this past weekend to properly
dive into custom renderers. I had seen them before, primarily when working with
mypic, but always avoided building my own, primarily because of what a hassle
they are to write. However, I'm now convinced that the hassle is worth it, at
least for some primary uses.
If you're not familiar with custom renderers, they're sort of an odd beast, but
they're the kind of thing where the concept eventually "clicks" in [read] Keywords: ibm
Wed, Oct 2nd 2013 8:12a Jesse Gallagher Though I'm not as eloquent on the matter as the many others who have shared
their appreciation for what Bruce Elgort has done for the community, I wanted
to be sure to pitch in as well. I have been active in this community for a
relatively short amount of time, but even before that Bruce's was one of the
names I knew looking in from outside, from his personal contributions to the
Taking Notes podcast and to his leadership of OpenNTF. And since I started
being actively involved in the com [read] Keywords: notes
URLs in XPages
Tue, Oct 1st 2013 6:11p Jesse Gallagher The topic of URLs came up today in a chat and in the most recent NotesIn9, and
I think this is an area that deserves some particular attention. When designing
any web app, it's easy to fall into some traps with URLs, and writing XPages
code juggles things around a bit - some things are much easier than usual, some
are insidiously harder.
At a base level, there are four main types of URLs you'll use when writing a
web app, distinguished by how they begin (don't quote me on the names, or [read] Keywords: domino
Domino Wishlist, September 2013
Fri, Sep 20th 2013 10:11a Jesse Gallagher I joined in a tweet from Paul Hannan earlier about desired Domino features
(that's a very worthwhile thread to read - lots of great ideas from others) and
it's had me thinking about more on my list. Fortunately, I have a blog for this
kind of thing! I'm leaving off a couple big-ticket items like Eclipse-4.x-based
Designer on the Mac because IBM may not be required for that.
Make $WSIS not trigger crummy SSL behavior (really, first-class support for
proxies in front of Domino, not just I [read] Keywords: domino
Progress on the org.openntf.domino Design API
Fri, Sep 6th 2013 4:14p Jesse Gallagher The primary focus of my recent work with the OpenNTF Domino API has been the
implementation of a fleshed-out design API. I've done a lot of work in my
Domino-programming career manipulating design elements, usually via DXL (such
as with my Forms 'n' Views app), and my aim is to codify all of that into the
API itself, eventually growing it to cover almost every design element that
Designer does (we'll see about Navigators, Composite Apps, and the like).
One of the big hurdles in recen [read] Keywords: domino