Subscribe via Feed

Single Copy XPage Design, another piece of XPages magic!

Paul Hannan, Jun 15, 2010 1:18:58 PM

More detail posted to the wiki.

Here's another piece of XPages magic coming your way in 852* and it's called Single Copy XPage Design (SCXD). Doesn't sound too exciting does it? But it's cool, real cool.

So what is it? Single Copy XPage Design is a new feature in 852 that allows for XPage resources to be shared. XPages design elements (XPages, Custom Controls, CSS, client/server JS libraries, themes) are stored in one database and then other databases can point to this common "SCXD" database through a new database property available in Designer (in the Performance section on the XPages tab in the Application Properties). At runtime, XPages will read this information and, if it is not empty, will then use the design elements from the "SCXD" database instead of the current database. So effectively you have UI in one database and data in another.
So what are the benefits of this new feature? Being placed under the Performance section in the Application Properties should be a give it away. The benefits are felt at runtime where the browser caching becomes more efficient as the same resources can be served for many separate applications. Rather than having same resources being served from each application which isn't optimal from a browser point of view.
Another benefit is that you can use this feature to your advantage by cutting down on design and admin time required to maintain the same UI across databases.
So let's have an example. Say you've upgraded your Domino server to 852 and on this server you've got some legacy, pre-8.5, applications which you're thinking about upgrading as well as take advantage of this new XPages technology.
Let's take an old application is from an old Discussion template.
And you've also got newer discussion app based upon the 852 template (this is it set to the green theme from oneuiv2).
So in the old app we're going to open the Application Properties in Designer and set the SCXD path to the newer discussion application to use it's XPages design elements.
Both of these applications would have the same forms and views (the newer discussion template has new forms and views which need to be copied over to the pre-85 discussion application to get this scenario to work).
Now hit the old pre-85 app in the browser - http://yourDomino/oldDisc7App.nsf/allDocuments.xsp
So there it is, a Domino app without XPages using XPages! :D
MAGIC!?
Some limitations to this feature:
  • A dummy or blank XPage with the same name of the default XPage from the SCXD database is needed to allow it to launch app in the default XPage.
  • The SCXD database has to be a NSF, not an NTF.
  • Common 'classic' design elements (Views, Form, Agents...) are needed in both NSFs. Only the XPages design elements can be shared
  • The XPages design elements cannot currently be overridden on a per instance basis.
  • The HTTP task needs to be restarted when the SCXD is set.
* Disclaimer: this is pre-release software so there is no guarantee that this will be part of the final release.

 

 

 


3 responses to Single Copy XPage Design, another piece of XPages magic!

Marius, July 23, 2010 8:47 AM

Why not a Single Copy Template / what are the benefits over Single Copy Templates?


Paul Hannan, July 15, 2010 6:53 AM

Hi Phil,
Yes, you are correct on the risk of database corruption. Though this risk would be lessened somewhat as the data on the other databases would still be preserved and unaffected. And the turnaround time to addressing the issue (replacing the corrupt db with a backup copy) could be swift.
On the performance side of things there shouldn't be a hit in the scenario this feature is meant for - the browser accessing many apps of the same design. Performance would be improved here.
This is a great feature though I think it wouldn't fit everyone. If your organisation has many apps of the same design, why upgrade them all when you can just do the one? And if your users are working with multiple apps of the same design from a browser or XPiNC, then this could be the feature for you.


Phil Warner, July 14, 2010 9:20 PM

I've been advised in the past that this sort of thing was bad practice, both in terms of performance and exposing the risk of your entire application breaking if your central resource database becomes corrupt or gets accidentally removed. What's different here? This is a tremendous feature if it's robust.