dominoGuru.com

Your Development & Design Resource

IBM XPages: Data Sources via Resource Bundles

08/06/2012 04:53 PM by Chris Toohey

IBM XPages: Data Sources via Resource Bundles

One of the true killer features of XPages for any IBM Lotus Notes Domino application developer is the native ability to create a remote data source for any UI control, thus quickly extending or integrating with an existing Lotus Notes or Domino Web accessible NotesDatabase. However I have found that when you define a remote data source for a given xp:viewPanel or another data source-driven control... things really tend to slow down.

Basically, any focus/click/blur in the Source or Design panes of an XPage have the data sources recalculate in order to wire any "pretty panel" data source selection. So when you're trying to change the values of the View Column Titles in an xp:viewPanel, it's going to recalculate/refresh that wiring to ensure that nothing changed in case you also want to change the actual value of the View Column.

Work locally, and it's fine. Work on a remote server (which I often do), and there are times I can brew an entire pot of coffee while DDE does the dance of the damned and updates everything.

To combat this (I need to cut back on my coffee intake), I started using a technique that I originally employed to address another concern: Domino Server, NotesDatabase, View, and Form location/name changes.

If you're working in the same NotesDatabase, the changing of a View or Form is often handle completely in that NotesDatabase design. You change the View, then all navigation and application logic should be changed accordingly. However, it's amazingly simple to overlook such changes (or worse yet, feel as though such changes can never be made for fear of breaking critical systems) when you're using that NotesDatabase as a storage container or otherwise integrating that application with some external app.

So because I've had NotesDatabases moved on me seemingly at random, Domino Server names change, Views go missing, or someone finally adds an alias to the "New Request by Employee" Form, I started using Resource Bundles in my XPages development standards to define any external resource.

The added benefit, as it turns out, is a huge speed boost in controls like the xp:viewPanel and xp:panel.

Here's an example xp:pane that uses this technique to define the NotesDatabase and Form for our Resource Bundle-driven data source:


<xp:panel>

    <xp:this.data>

        <xp:dominoDocument

            var="thisProfile"

            databaseName="#{javascript:return 
preferences['db_users'];}"

            formName="#{javascript:return 
preferences['form_user'];"

            documentId="#{javascript:return 
getPersonUNID(context.getUrlParameter('id'));}"

            ignoreRequestParams="true"

            action="openDocument">

        </xp:dominoDocument>

    </xp:this.data>

...

Here, we have the xp:dominoDocument's databaseName and formName checking our "preferences" Resource Bundle. We can choose to add this Resource Bundle via the XPage resources or via a Theme (see examples below):

Resource Bundle via XPage resources


<xp:this.resources>

    <xp:script

        src="/core.jss"

        clientSide="false">

    </xp:script>

    <xp:bundle

        src="/preferences.properties"

        var="preferences">

    </xp:bundle>

</xp:this.resources>

Resource Bundle via Theme


<resources>

    <bundle 

        target="xsp" 

        src="preferences.properties" 

        var="preferences" 


        loaded="true" 

        rendered="true" />

</resources>

And now, our "preferences.properties" Resource Bundle:


db_users=development/Servers!!directory\da_nab.nsf

form_user=Person

Pretty basic, really...

We use the serverName!!filePath syntax for NotesDatabases (or just the filePath if they're on the same Domino server), and alias names for any View or Form Design Elements where appropriate.

Conclusion

Simply put: this breaks RAD, in that you'll lose any of the basic wiring that you normally get when you're setting up xp:viewPanel columns or xp:panel input elements. The Data Source "pretty panel" dropdowns will appear "blank", but you can either type the variable/notesItem names in there or stick with the Source pane.

This greatly improves speed when you're dealing with remote data sources, and is highly recommended for those seasoned pros who don't bother much with the "pretty panels" anymore. The speed, not to mention the ability to change-at-will without the need to rebuild, make this a slick option... but your mileage may vary.

Love it or disagree? Share your thoughts in the comments section below. Like/+1 if it's something you want others to see, and as always if there's something topic or demo-wise you want to see on the site, just let me know.

About the author: Chris Toohey

Thought Leadership, Web & Mobile Application Development, Solutions Integration, Technical Writing & Mentoring

A published developer and webmaster of dominoGuru.com, Chris Toohey specializes in platform application development, solutions integration, and evangelism of platform capabilities and best practices.