Thanks to everyone who replied on my last post. Several people told me they thought it was a trick question. I suppose my reputation precedes me.
I will now make a bold assertion: the correct answer should be “one.” You should deploy one XPage application, period.
“But Nathan,” you’re thinking, “we have lots of different applications! We have our help system and our phone directory and our shipping workflow and our CRM and…” Sure, I get it. Except, those aren’t separate applications. Those are separate DATA STORES.
Open up any XPage or Custom Control. Go to your document or view data source. Select the Data panel in the Properties control. See that box on the right side that says “Application?” You see where you can select “Other?” What’s that next to the input box? It’s a blue diamond, right?
Close your eyes and let that sink in for a moment. You can programmatically determine the NSF for your data source…
Ask yourself why you’re putting your XPages and Custom Controls in the same NSF as your data. Do you have a good answer? Or does it occurs to you that the answer is: because that’s the way we’ve always done it?
Of course, in good ol’ Notes development, you HAD to do it that way. A view could only display content from the current database. Sure you could embed a view from some other NSF into a frameset or an embedded view panel, if you were sufficiently motivated, but the UI object for the view had to be in the same NSF. And god help you if you tried to back a Form with data from a different database.
But now you can drop a data source in a control, and have it determine, at runtime, what data container it will refer to. It’s not even difficult. You can do the calculation in SSJS or read it from a query parameter or a session scope variable or a Java Bean or a static method or… or… or…
So what reason is there to put the Control in the same NSF? What reason, in fact, is there to build and deploy and maintain more than one XPages application EVER? What ever you want to do with your XPages interfaces, why not just put them in one place and bind them dynamically to what ever NSFs you need to target?
Think of it: no more managing multiple templates. No more need to touch 100s of NSFs to fix a style sheet. No more copying your Java libraries into a bunch of different places, or clicking all through your Designer workspace to turn the Extension Library on for your apps. No more server Design task.
Want to cache a keyword list for your sales territories? In Notes, such a cache would be per-client. In Domino, maybe you could cache it in a shared profile doc or something that’s scoped to the database. If you keep deploying XPages controls directly into your NSFs, you might decide to put that list in the Application scope memory. But if you put all your XPages controls in one place, then you can cache that list just once for the entire server.
In fact, you can do everything just once. Want to set a theme? Just once. Translate your interface into French? Just once. Import a library? Just once. Reuse a handy custom control you found at OpenNTF.org? Just once. Manage your application with SCM? Just once. Track user preference settings? Just once.
Go ahead, try it. Make a new NSF on your server. Call it, I dunno, PORTAL.NSF. Now go to several other applications and copy your XPages stuff into your new portal. Now just point the data sources to the right source NSFs.
Are you getting it yet? I can only show you the door. You’re the one that has to walk through it.
P.S: for bonus points, make portalv1.nsf, portalv2.nsf and portalv3.nsf. Now make an internet site document that redirects the URL “portal” to portalv1.nsf. Or portalv2.nsf. Or portalv3.nsf. “You have to let it all go…”