XPages can be a lot of things, and by looking at the source code for the openNTF project "XPages Extension Library", or as I like to call it, "The missing XPages documentation", you can see a lot of the stuff that is possible. However, it is not for the faint of heart.
As somebody who has a CMS system running with a presentation layer made with XPages, I feel I have something to add to this discussion. When we upgraded our old application (from v5 to v6), we created a presentation layer using traditonal WebQueryOpen agents and a custom templating engine, but had troubles scaling this. The solution for us was to go the "XPage as Agent" route with Freemarker as a templating engine. On top of Freemarker we have added our own freemarker-directives that speak Domino.
The reason we did this is the following:
1.) We had an existing application, and wanted more or less backwards compatibility with our templates
2.) Simple for our consultants to modify and reuse templates and subtemplates without modifying the design of the application
3.) The Web is text, not objects
This model gives us a few easy advantages, for example templates are stored as Notes documents (and some system templates resides in jar files), and we can also easilly use Memcached to cache complete or partial pages. XPages is actually a really fast processing environment, and typically gives us response times around 200ms for a cache miss, and 30-50ms for a cache hit.
While this solution works fine for us, we have had troubles with unstable servers, and after several PMR's we are still not sure if its us or XPages that crashes Domino on high load.
If we didn't have our own CMS already, I would not have considered using XPages for public websites, as I see it as too much work. I would have chosen an already existing CMS. We do however use XPages for internal sites and custom applications for clients, replacing "traditional" Domino web development.
XPages can be a lot of things, and by looking at the source code for the openNTF project "XPages Extension Library", or as I like to call it, "The missing XPages documentation", you can see a lot of the stuff that is possible. However, it is not for the faint of heart.
As somebody who has a CMS system running with a presentation layer made with XPages, I feel I have something to add to this discussion. When we upgraded our old application (from v5 to v6), we created a presentation layer using traditonal WebQueryOpen agents and a custom templating engine, but had troubles scaling this. The solution for us was to go the "XPage as Agent" route with Freemarker as a templating engine. On top of Freemarker we have added our own freemarker-directives that speak Domino.
The reason we did this is the following:
1.) We had an existing application, and wanted more or less backwards compatibility with our templates
2.) Simple for our consultants to modify and reuse templates and subtemplates without modifying the design of the application
3.) The Web is text, not objects
This model gives us a few easy advantages, for example templates are stored as Notes documents (and some system templates resides in jar files), and we can also easilly use Memcached to cache complete or partial pages. XPages is actually a really fast processing environment, and typically gives us response times around 200ms for a cache miss, and 30-50ms for a cache hit.
While this solution works fine for us, we have had troubles with unstable servers, and after several PMR's we are still not sure if its us or XPages that crashes Domino on high load.
If we didn't have our own CMS already, I would not have considered using XPages for public websites, as I see it as too much work. I would have chosen an already existing CMS. We do however use XPages for internal sites and custom applications for clients, replacing "traditional" Domino web development.