Recently I was able to help explain an issue Russ Maher was having with his application png files – http://xpagetips.blogspot.com/2014/11/got-png-you-may-get-problems.html. 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.
Conclusion
We as XPages developers need to stop using the “database” for files etc and start to use the WebContent like proper web developers.
PS
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.
Xomino 
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 🙂
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.
Oh absolutely. I am talking about the files uses to build the application framework only 🙂
What kind of security do you have in mind? Aren’t reader fields not enough? 😉
One of the key things we do with design elements in the “database” is manipulate them with code – as an example you can add image resources and edit CSS files programatically. Is this possible if they are in webcontent ?
Here is an example of where I create image design elements
http://seancull.co.uk/2008/10/02/sntt-visual-directory-thumbnails-in-the-domino-directory/
Yes, you can add them programmatically.
There’s a blog post waiting to happen for you Sven 😉
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 😉
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.
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.
@sean don’t know – good question though. More research
Yes. How can I get the js scripts inside the WebContent, aggregate and compacted together in order to have a single .js?
Within eclipse I use this old tools
http://blog.avirtualhome.com/rockstarapps-for-eclipse/
But it does not work when installed in domino designer (the file is generated minimized empty)
Thanks so much
You can create a servlet which does the compression and aggregation on the fly.
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.
[…] of Stefano Fois comment I decided to write an example how to create a minimizer servlet for Domino which will compress […]