Erik Brooks

 
So a few weeks ago I blogged about the Dojo website getting a facelift. It was much cleaner than before, a bit more organized, though less eye-catching.
 
Well apparently they decided to step it up a notch with an entirely new site design. Click here to see it. I have to say I like it.
 
It looks like they've really put a lot of effort into documentation, too. Click the "Learning is Easy" in the lower-right.
 
And I didn't know Cisco was using Dojo also. Cool stuff.
 

 
Neither the iPhone nor the iPad run Flash.
 
There is currently an incomplete open-source javascript-based flash interpreter that came out a few weeks ago that seems to be able to run some flash if it's hacked in. At least, it runs some flash for now on the iPhone.
 
Keep in mind that Apple has a vested interest in Flash not running at all since then applications could potentially bypass the App Store's screening process (and revenue). Also keep in mind that they've made updates that disable applications/workarounds/jailbreaks in the past.
 
Consider your target audience's capabilities wisely. That is all.
 

XPages are gaining traction, and this is a Good Thing (tm).  IBM is obviously behind the concept, as 8.5.1 has some new goodies, and it's no doubt that 8.5.2 will also.  The Dojo community is addressing IBM's needs (and vice-versa), and we're seeing a bit of fresh Domino/XPages developer blood pop up in the 8.5 forums as a result.
 
And a really, really awesome thing is happening: People (including IBM) are contributing sidebar widgets and XPage custom controls to the community. This is huge, and hopefully I'll be donating some nice ones in awhile.
 
XPages are truly revolutionizing Domino development. Aside from a couple of glaring barriers-to-entry (inability to consume LotusScript, complaints of inadequate documentation, lack of user-versus-signer ACL control, inability to "partial refresh" multiple controls) they really are pretty darn amazing. They let you do things with the interface that would simply be cost-prohibitive on legacy Domino.
 
One of the design paradigms that is becoming prevalent in XPage development is a de-normalization of Domino data.  I.E. you don't use list fields (text list, number list, etc.) as often. Many pieces of XPages are built around handling a collection of documents, and to leverage that integration you're better off using individual documents for some things.
 
As a case-in-point here are two of my favorite examples of reusable controls -- both are File Upload managers:
 
Here's one.
 
Here's the other.
 
They both let users upload attachments. Each attachment becomes a new document, with a few pieces of additional information (including the UNID of the "main" document).
 
Cool right? I thought so too. The interface is definitely waaaay better than the old "File Upload Control" from legacy Domino dev. But then I thought about it a bit, and realized that there's a big problem with this new paradigm: indexing.
 
You've got a collection of "main" documents, and a bunch of "file upload" documents. But as soon as you've decoupled your data in this way, many things get much more difficult.
 
Try this: Get a collection of all "main" documents that have more than 2 files uploaded.
 
Now, if instead of XPages you were working with classic Domino dev you would be storing your attachments in the "main" docs themselves. And you would simply type this in your view selection formula: @Attachments > 2
 
But in this new decoupled paradigm of XPages where your data spans multiple docs, what do you do? You either get to hack in some sort of incrementing code to write to a field on the main document (and decrementing when you go to delete) and search on that, or you get to hack in a loop routine to do your own pseudo-JOIN and return the collection of docs that matches your criteria. The first would be potentially open to sync problems, the second would not scale as your dataset grew. A third possible option would be to manipulate the file after it's uploaded to shoehorn it back into the "main" doc, but that's got its own set of problems. And all of these approaches require a bunch of extra code.
 
Ouch.  Score one for legacy Domino dev.
 
I think that XPages are going to quickly bring to the forefront the #1 weakness of NSF - views.  Don't get me wrong - views are still fairly powerful, and there's a lot you can do with them. But they haven't gotten any true indexing enhancements in years. Well, there's the "defer index build" feature which is more of an admin/disk space help (8.0), and also the feature where view index builds are integrated with the transaction log (6.0 I believe). But as far as helping you search/group/sort/evaluate your data, things haven't changed in a decade.
 
The list of potential enhancements is huge, some of which we've discussed here:
 

• store readers' field info as part of the view index to help address the "many readers and docs" problem
• get view indexes out of the NSF, on an external path similar to DAOS' functionality
• implement IBM's patent from 2002  (which pertains to Notes/Domino specifically) to allow users to resort while inside of a category, or while using restrict-to-category
• sorting on category-row totals
  
• cross-column totaling (e.g. a category row has a 12 in column A and 15 in column B.  Column C shows 12/15)
• allow developers to specify fields to be indexed at the NSF level, similar to what "Optimize Document Table Map" does for the Form field (though that feature got broke in 6.0).
• add additional column totaling algorithms (min, max, stddev, "custom" with an @Formula would also be nice)

 
...and of course, the classic problem I've exemplified in this blog post: JOINs. Part of me thinks that, with NSFDB2 being scrapped, IBM's got to at least be aware of the need for those. Hopefully there's work being done. With just a bit more enhancements on views, there's really no stopping XPages.

UPDATE: Here's a link to this idea on IdeaJam.

So XPages are cool.  VERY cool.  And since they can be bolted onto an existing Notes app you should be really, REALLY tempted to upgrade your existing Domino web apps with screen-by-screen updates.

Simply rewrite a form/view/etc. as an XPage and leverage all of the CSS and JSF goodness, give your users a better experience, give your app better performance, etc.  And you can finally code stuff where it's supposed to be, without having to use all of the hack-tastic legacy Domino web techniques.

But there's one big hurdle here:  XPages don't work with LotusScript.  At all.  So those legacy apps, if they use WebQueryOpen or WebQuerySave agents, are looking for a forklift-style upgrade where you get to rewrite your agents and script libraries in Javascript and/or Java.

So a cool new technology requires a massive rewrite?  Hmm.... sounds kinda like Microsoft.

But wait, it gets worse.  The Notes client doesn't support XPages (yet).  Oh, I'm sorry - did you need to use that app on the web AND in the Notes client?  Well now you get to maintain your Lotusscript libraries for the Notes client, all while maintaining new Javascript/Java libraries for XPages on the web, right?  Certainly you're ready to double your dev and testing efforts.

I know, I know - Notes 8.5.1 will get XPage support in the Notes client.  This may mean we finally have a single dev road where we can simply write an app in XPages and it Just Works(tm) in browser or client.  And that would be really, really fantastic.  But (as far as I know) Xpages still aren't going to support LotusScript.  So, again, any legacy apps will need major rewrites to take advantage of the new front-end.

I'm sure Lotus development saw this coming a mile away as a shortcoming of XPages.  It was asked about in forums for the Notes/Domino 8.5 Beta, and also the Gold release.  There's even a Wiki article that tells you how you can have an XPage run an agent (which could be an LS agent) as a pseudo-band-aid to try to help on some things.  Unfortunately that approach is riddled with shortcomings, such as requiring that you save your doc(s) prior to calling the agent (even if you're not certain you want to do so yet) and foregoing all XPage error encapsulation.  All your XPage can do is say "Hey man, I kicked off the agent, ok?"  And recreating the functionality of a WebQueryOpen agent? That's even more fun.

Naturally, I opened a PMR for this, asking to be added to the enhancement request to have XPages consume Lotusscript.  But you know what?  THERE WASN'T ONE.  Not a single SPR relating to this.

Now, certainly Lotus development has talked about this.  Certainly Design Partners have mentioned this on conference calls.  Certainly there was feedback about this in the private Betas.  I'm sure Nathan's shouted loudly that this is a huge barrier for legacy applications.  But for general customers this is the only formal means at our disposal to ask for this type of thing.

So if you too would like to see Lotusscript support in XPages, open a PMR and ask to be added to SPR# PALT7SVH29 .