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.
An XPage As A Tree: Implications
Wed, Apr 16th 2014 3:11p Jesse Gallagher A few posts ago, I talked about how the skeletal nature of an XPage is really a
very abstract representation of a UI. At its core, it isn't conceptually tied
to the web - and, indeed, the probable bulk of the work done by JSF is to push
against the normal rules of the web.
The goal of XPages/JSF is to abstract away the messy business of writing web
pages, much like a cross-platform mobile framework attempts to abstract away
the chore of writing to iOS or Android directly.
In practice, I [read] Keywords: xpages css
How I Added File-Download Support To My Model Framework
Sat, Apr 12th 2014 10:33a Jesse Gallagher Unlike the last few posts, this one isn't as much a tip or tutorial as it is an
attempt to share my suffering by detailing the steps I took recently to add
file-download and -upload support to my current model framework.
The goal of my framework overall is to retain the benefits of normal Domino
document data sources (arbitrary field access, ease of use in simple cases, and
compatibility with standard XPage idoms) while adding on useful new abilities
(getters/setters, relationships with o [read] Keywords: domino
Loading Resources via Themes
Thu, Apr 10th 2014 10:36a Jesse Gallagher In today's TLCC XPages webinar, Marky Roden had a great presentation discussing
resources and design definitions to help speed up Designer. If you didn't catch
it live, it's worth tracking it down when it's available.
I'd like to build on what he was talking about a bit by explaining how to use
themes to load resources in a way that also prevents Designer slowdown while
having the secondary benefit of being clean design (with some caveats that I'll
If you're not familiar [read] Keywords: xpages application
The Collections Framework as Education
Sun, Apr 6th 2014 4:15p Jesse Gallagher While I've been formulating the followup to my last post, I've also been
thinking about how wonderful the Java Collections framework is. I've been
singing its praises for a long time (as have others), but what's stood out to
me lately is how well it encapsulates many of the most important foundational
concepts of Java.
One of the reasons Java appears so intimidating and foreign to Notes developers
is that the way many are introduced to it - as an auxiliary for XPages -
involves learni [read] Keywords: notes
Life in Other Worlds
Tue, Mar 25th 2014 5:17p Jesse Gallagher I've found the reaction to BlueMix to be pretty interesting. Unsurprisingly,
the main question in our community has been "how does this relate to Domino?"
The answer is pretty clear: it doesn't.
That's not really a bad thing! About half of the problems a platform like
BlueMix solves - app packaging, multi-server availability, data-store access -
are either non-issues on Domino or are done much more easily with it than with
other app servers. The other advantages, well... IBM could lik [read] Keywords: domino
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