Stop trying to hit me and hit me!

In this case, the blue pill is good for you.

In this case, the blue pill is good for you.

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.

“Huh?”

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…”

Advertisements
Posted in Uncategorized
9 comments on “Stop trying to hit me and hit me!
  1. Interesting and certainly a technique that I will be using. But there are some drawbacks I can think of to using a single front-end:

    – single ACL, which makes it harder to fine tune access
    – single theme (one .nsf will only accept one theme setting), where I would love to be able to work with a base theme and extend that per application
    – many, many XPages and Custom Controls will demand for a very stringent naming convention. The flat view of design elements in Designer does not help here
    – single point of failure

    • thentf says:

      Fair points, Thimo.

      For ACLs, remember that the access rules for the individual data stores are still applied. So if the user only has Reader access to some target NSF, then they still only have Reader access. In which case, the design decision you have to make is whether to show them a link for something that creates content in the target, right? But you have to do that anyway even if your XPage is in the same NSF. Otherwise you get pathological user experiences like the Domino Directory has where you see an action for “Create new group” and you click on it and says “you’re not authorized to do that.” Well, why did you present me with the opportunity then!??!?!

      I think many people would consider just one theme to be an advantage. If I had a nickel for every time I heard someone say “all our applications should have the same look and feel,” well, I’d still be broke because a nickel isn’t worth anything any more, but I’d have a great big sack of nickels for sure.

      You’re quite correct about the crowding effect it could have on your template. It could very quickly end up looking like the Teamroom template (*shudder*) I have some follow up posts planned where I’ll discuss that further.

      I agree about the single point of failure. In my experience, entire Domino servers tend to fail rather than single applications, but I’ll admit that my experience is probably anything but normal. 🙂

  2. So many XPages app? We’re down to zero here, application code is 100% in OSGi plugins. 🙂

  3. One of those XPages apps I deployed way back in 2009 was just a shell. The data was in a different database. On a different server. Which was 8.0.2. That other database was a Notes Client app. The XPages shell was accessed via a sidebar widget, for reporting. On an 8.0.x client.

    But I don’t think I’ll be deploying just one XPages app to customers any time soon. Why not? Two big reasons for me. 1) Department A wants new functionality for app X, but department B hasn’t yet approved changes to app Y. It’s always going to happen. Yes, branching can handle that, but separate NSFs make it easier. 2) Fewer design elements makes easier to work out where I want to be. I’m sure that you’ve devised some clever ways for injecting columns into a view based on a Map or rows and relevant components into a Form Table based on configuration documents to work around that issue. But I think I’m a few steps behind on that process of vanilla-isation at the moment.

  4. Erik Brooks says:

    If you have the luxury of servers with adequate hardware, I actually find the “old school” method of compartmentalization in separate NSFs to be *preferred* in many scenarios for the reasons Thimo mentioned.

    It’s also much more beneficial for live troubleshooting/patching for a developer to be able to jump into one specific NSF and debug/fix something live without risking breaking things for other users.

    The old-school method does make code deployment a bit more of a pain with respect to configuration docs that need to be pushed around to multiple NSFs, but that’s more of a separate discussion revolving around the Design task.

    One thing that’s very, VERY cool with XPages is the ability to point to a datasource that is in a different NSF on a different *server*. We’ve got a specific use case for that on one app where we have replicas across LANs/WANs but require users to access a specific, 100% consistent set of docs regardless of location. Very cool stuff.

  5. thentf says:

    “It’s also much more beneficial for live troubleshooting/patching for a developer to be able to jump into one specific NSF and debug/fix something live without risking breaking things for other users.”

    Well, if I have portalProd.nsf, there’s nothing on earth that stops me from copying that to portalFix.nsf, working on something until I get it right, and then putting that fix back into portalProd.nsf. Depending on your preferred deployment strategy, putting the fix in might mean a sloppy copy/paste. It might mean the merging of a branch in SCM.

    It might mean simply redirecting the site document from “portalProd.nsf” to “portalFix.nsf.” There’s no reason you couldn’t have N number of variations of your single application available for use concurrently. That’s a design decision that you can make on the very first day.

    • Erik Brooks says:

      You’re correct, it’s relatively simple to spin off a copy of your NSF for debug purposes, but there are many other concerns there as well:

      1. The developer may not have admin permissions to make new NSFs on that server (or create/modify website docs.)

      2. If the NSF is large that can cost you a lot of valuable developer time while it copies.

      3. A new NSF copy won’t have any view or FT indexes built. More time waiting.

      4. If there are scheduled agents in the NSF then you better not bring those along.

      5. To properly troubleshoot multi-NSF apps you might need to copy multiple NSFs and – aside from repeating all of the concerns above – this may require changes to configuration docs to ensure your references point to the additional copies you made. More time, and increased potential for error.

      6. Spinning off a copy of an NSF will inadvertently hide any db-level problems that might be occurring. E.g. if you’ve got a ghost doc entry in a view the simple act of spinning off a new copy will cause view indexes to be built from scratch, hiding the real problem from the developer.

      All of this costs more time and means that your developers have to have pseudo-admin knowledge to understand more of the application architecture, potential NSF database problems, potential issues that they could cause should they forget something, etc. It’s potentially a lot more complexity than just opening the NSF in-question, live, and debugging from the get-go.

      It also means that if your proposed fix is high-risk you have no elegant way to put it into production for only a subset of the users of the application. The “old school” method allows you to leave the fix in-place for the users that needed it immediately, allowing it to get some “bake-in” time, and easily letting you selectively roll it out to other NSFs as risk-tolerance allows. The single-front-end approach requires a lot of custom code to achieve that same effect.

      The biggest advantage, IMO, for a single-front-end approach is the server resources you save. The disk footprint is much lighter (no duplicated design docs,) more design docs are cached, etc. The Design task would obviously finish much faster as well. But server hardware is becoming cheaper and more scalable every day, so the real decision should be made based on which method is cheaper and more maintainable from a development standpoint.

      • thentf says:

        You have developers who can debug/patch in live systems but can’t create new databases or change web config docs on those same systems? That’s an odd governance strategy.

        But sure, Erik, I’ll agree that there are very specific service provider scenarios where having lots of forks of your codebase makes sense. I’m fairly sure your environment is not representative of the typical Domino rollout. You are the 1%.

        My suggestion is not about server hardware. Developing server systems to conserve hardware is a fool’s errand. Computers are always cheaper than humans.

        Unifying your applications is about reducing development cost by maintaining a common codebase for everything. If you supply a product or a platform that’s made up of 5 or 10 or 20 templates that are used to create new instances of customer implementations, then sure, employing a staff to maintain those as isolated logical units makes sense.

        I’m talking about environments with 100s or 1000s of applications in their domains; places making serious investments in updating these apps, but stuck using the same development strategies that have left those apps outdated and atrophied.

  6. Erik Brooks says:

    “You have developers who can debug/patch in live systems but can’t create new databases or change web config docs on those same systems? That’s an odd governance strategy.”

    No, all of our developers can do those things where they need to. My point with #1 is that in some shops they may not be able to. It could be a moot point if somebody’s devs can create new DBs where needed.

    My points #2 through #5 point out the main disadvantages of the “single front-end” approach: making copies of NSFs, tweaking config docs and waiting for indexes to build is far more time-consuming and prone to error than simply opening the DB and immediately debugging the problem. That will, IMHO, nearly always tip the scales in favor of the traditional model.

Take the red pill.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: