Got non-XPages design elements? You really should use WebContent.

Recently I was able to help explain an issue Russ Maher was having with his application png files – It got me thinking that as modern web developers (which is what XPage developers need to be), we should not be using Domino database elements for “web elements”.

Back before R8 we all used the Database Files, Style sheets and Database Images as a way to reference files as part of the database. I now believe we need to stop using these altogether for “web development”.


WebContent is better

A modern (non-XPages) web based application typically looks like this


As you can see from the image above within a well structured web application css, images and js are all neatly separated out into separate folders. This makes it easy to drag and drop them from web server to web server because all the links are relative and easy to find.

Within our WebContent folder (Accessible within the package manager Window – Open Perspective – XPages) we are able to drag and drop a web project,  jQuery plugin, angular.js directive, extjs and many items and have them continue to function without any issue.

Bootstrap is another great example, well structured and easy to add to our applications.


Source control

When we build out our applications and use source control the “database structure” is stored locally and then committed to our Git or Mercurial repository. Not using the WebContent folder causes us problems when we are searching for files in this environment. Having all our files as it they were in our database makes our lives harder and certainly harder for non-XPages developer to find our code. Some is in “Code” and the rest is in “Resources”, that doesn’t make sense.




We as XPages developers need to stop using the “database” for files etc and start to use the WebContent like proper web developers.



Yes – I know we all have old applications which get modernized and we cannot always do anything about it, but at the same time for new development moving forward this is where I am at.





19 thoughts on “Got non-XPages design elements? You really should use WebContent.

  1. I’ve been pushing so hard in the opposite direction, but you’re right. The way things are ‘organized’ in Designer is confusing. Better to move outside than have half-in, half-out.

    • The only advantage to continue to use database elements is because you are used to it, and that’s not a good excuse 🙂

  2. Perhaps you’re right however there is still a need for the granular security afforded by putting some artifacts in documents etc.

    There isn’t any granular security down there in WebContent.

    • Sean – in your example you are talking about dynamic content as opposed to the under lying framework of the application. That’s a great distinction to make.

      Sorry if I was not clear enough, content was not necessarily what I was going after.

      Why you would want to edit CSS files on the fly though I am not so sure and would love to understand more 🙂

      Nice blog post BTW – you should try that more often 😉

  3. While I don’t disgree this whole process of doing it like “proper web developers” at a certain point makes the platform redundant.

    • I actually believe that continuing to think and work like notes developers and not like web developers contributes to the platform’s demise within an organization.

      Functionality is no longer the sole primary requirement, UX is at least equal first.

      XPage developers by definition are web developers and need to think that way.

    • I disagree from both angles. The platform has the benefit of being a database store, web server, mail routing platform, security, REST and Java APIs, both of which are extensible, offline use etc. Use proper web development and your app and the platform becomes more accessible to proper web developers. Plus this approach has the added advantage of reduces dependency on proprietary editors, which is always good. Stop using file resources and all you need to make available for an Eclipse plugin (for XPages apps) is the XPage editor (which is the same for Cudom Contols), the builders and some kind of Forms and Views editor. The ability to break from an archaic version of Eclipse would be a great benefit.

  4. What about CSS / JS aggregation via XPages. We have found that this makes a big difference to applications ( yes I know – another blog to write 🙂 )

    Is this supported in these folders – I honestly don’t know.

      • Great idea but do not know how to achieve it.
        I have never seen any example posted on the internet on this topic
        If you have a good example can post it on your site?
        Thanks so much.

    • When I use “outside” editors to edit the content of the WebContent folder, it opens Pandora’s box for me. I can use the latest and greatest developer tools I want. For example I like using jade and Sass to write my front-end, instead of html and css, respectively. I use a software called Prepros to convert my jade into html and minimize and concatenate my Sass into a compact css, which are then copied into the WebContent folder of my nsf application. It’s a wonderfully efficient way of coding. I do believe, it’s one bright possible future of XPage development: Keep the security, ACL and the database provided by Domino, but use any front-end to display the data in the browser.

Leave a Reply

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

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

Facebook photo

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

Connecting to %s