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.
Using the ODA Design API for File-Resource Manipulation
Wed, Nov 19th 2014 5:11p Jesse Gallagher As is characteristic of his blog, Sven Hasselbach recently posted two
interesting posts on using the NAPI classes in the XPages runtime to manipulate
files in the WebContent folder. If you haven't read the posts, I suggest you do
so now, because it's knowledge that is very good to have. The NAPI classes are
chock full of cheating sorcery.
But the point of this post here is a bit of me-too-ism. Which is to say: the
OpenNTF Domino API has you covered on this front. The API's Design packag [read] Keywords: domino
Factories in XPages
Wed, Nov 12th 2014 5:18p Jesse Gallagher In my last post, I intimated that I wanted to write a post covering the concept
of factories in XPages, or at least the specific kind in question. This is that
The term "factory" covers a number of meanings, and objects named this way crop
up all over the place (ODA has one, for example). The kind I care about today
are those defined in an XspContributor object in an XPages plugin. These
factories are generally (exclusively, perhaps) used for the purpose of
generating adapters: as [read] Keywords: domino
Using "Verboten" Property Names in Custom Controls
Sun, Nov 2nd 2014 8:11a Jesse Gallagher In an attempt to save you from yourself, Designer prevents you from naming your
custom control properties after SSJS keywords such as "do" and "for". This is
presumably because a construct like compositeData.for would throw both a syntax
error in SSJS and the developer into a tizzy. However, sometimes you want to
use one of those names - they're not illegal in EL, after all, and even SSJS
could still use compositeData['for'] or compositeData.get("for") to access the
Fortun [read] Keywords: ibm
Sun, Oct 26th 2014 5:15p Jesse Gallagher This weekend, I attended CocoaLove a new Mac/iOS-development-related conference
held in Philadelphia. Though my Cocoa resume consists of doing various
tutorials every few years for the last decade or so, the location, concept, and
speaker lineup were impossible to resist.
The upshot: this was a great conference. As the tagline – "A conference about
people, not tech." – indicates, the sessions weren't technical or even
generally about programming as such. Instead, it was a bit more i [read] Keywords: domino
A Welcome SSL Stay of Execution
Tue, Oct 21st 2014 3:11p Jesse Gallagher As you likely know from the torrent of posts on Planet Lotus on the topic,
IBM announced a hopefully-imminent pair of updates to cover the two main SSL
issues that have come to the fore recently: lack of SHA-2 support and the
POODLE vulnerability in SSLv3. This is welcome indeed!
Personally, I'm going to stick with the nginx approach for HTTP, even in simple
setups, because I've found the extra features you can get (and the promising
new ones I haven't tried) to be a dramatic [read] Keywords: domino
Some Notes on Developing with the frostillic.us Framework
Thu, Oct 9th 2014 5:12p Jesse Gallagher Now that I have a few apps under my belt, I've been getting a better idea of
the plusses and minuses of my current development techniques - the
frostillic.us Framework combined with stock controls + renderers. This post is
basically a mostly-unordered list of my overall thoughts on the current state.
Component binding is absolutely the way to go. This pays off in a number of
ways, but just knowing that the component is pointed unambiguously at a model
property - and thus getting its field [read] Keywords: notes
Building an App with the frostillic.us Framework, Part 7
Tue, Oct 7th 2014 6:12p Jesse Gallagher Well, it's been much longer than planned, and this topic isn't actually
particularly groundbreaking, but the series returns!
Define the data model
Create the view and add it to an XPage
Create the editing page
Add validation and translation to the model
Add notification to the model
Add sorting to the view
REST with Angular.js
One of the edge features of the Framework is that it assists in writing
DesignerFacesServlet servlets - which are sort of like XAgents but written
dir [read] Keywords: ibm