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.
SNTT: Reconstructing DateRanges
Thu, Feb 27th 2014 8:11a Jesse Gallagher In the OpenNTF API chat, I was reminded yesterday of how terribly broken
DateRange retrieval is in Java. Specifically, though you can create date ranges
and use them in view lookups, retrieving them from documents or view entries is
FUBAR. To wit:
Field Value 02/27/2014, 02/28/2014, 02/27/2014 - 02/28/2014, 01/01/2014 12:00 AM -
01/02/2014 12:00 PM
doc.getItemValue("SomeField") [02/27/2014, 02/28/2014, 02/27/2014, 02/28/2014,
01/01/2014 12:00:00 AM EST, 01/02/2014 12:00:00 PM EST]
No [read] Keywords: lotusscript
My Current Model Framework, Part 2: An Example
Fri, Feb 21st 2014 2:11p Jesse Gallagher To go along with the updated release of my Scaffolding project yesterday, I've
created an example database created with that template and containing a basic
use of my model framework:
This demonstrates a few things about the framework:
Setting up the two classes that go with each object type - the object itself
(e.g. model.Department) and the "manager" class that handles fetching objects
and collections (e.g. model.DepartmentManager) and adding the collectio [read] Keywords: database
Couchbase StateManager for XPages, Part 2
Fri, Feb 21st 2014 9:11a Jesse Gallagher I had the opportunity to dive a little back into the StateManager I wrote the
other week to try out a theory. The first thing I noticed was that there was a
minor problem: it didn't work at all. Specifically, the code I had didn't
actually store the whole proper state of the view, so it ended up being
regenerated anew each time; the fact that this didn't cause an error was what
led me astry.
Fortunately, I was able to scrounge together enough code to get it to work
properly, bringing t [read] Keywords: domino
Couchbase StateManager for XPages, Part 1
Wed, Jan 29th 2014 1:11p Jesse Gallagher The other day, I attended Tony McGuckin's Connect session on XPages scalability
(a companion to his earlier Masterclass on performance) and I was inspired to
try out a thought I had: could it work to use Couchbase to further push the
bounds of XPages scalability?
If you're not familiar with Couchbase, it's a product similar to CouchDB, which
is in turn essentially Domino-the-DB-server re-done for modern needs. Last
summer, I wrote some data sources to use Couchbase data in an XP [read] Keywords: domino
Data separation with an asterisk
Thu, Jan 9th 2014 8:12a Jesse Gallagher A little while ago, I converted over to the practice of separating your XPage
app from the NSF that contains the data, even when it's going to be a
one-to-one mapping. This confers a number of advantages in the areas of easier
testing, easier development, programming discipline, and security. One of my
favorite aspects is the ability to do this on your data DB:
Don't allow URL open
This alone adds tons of security: no more worrying about ?ReadViewEntries,
hiding your views from the web, [read] Keywords: notes
Go read: "Paul Hannan, The XPagers [sic] Champion"
Tue, Jan 7th 2014 4:44p Jesse Gallagher In spite of its heinous, brutal titular attack on English-language rules of
plural punctuation*, I urge you to go read David Leedy's recent post about Paul
Hannan. I can't add too much other than my agreement. Paul always does an
excellent job filtering through our grousing on Twitter and it'll be a shame to
not meet him in person at my first Lotusphere.
* I kid.†
† Not really. [read] Keywords: lotusphere
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