Yesterday, Jesse Gallagher wrote a great blog post on using an older version of the Web Tools Platform plugins in Domino Designer to get a better editor for faces-config files.
For over a year now, I’ve moved beyond Domino Designer for chunks of my day job – SourceTree for source control, Perforce P4 Merge for fixing merge conflicts, Eclipse Modeling Framework for data modelling, and Eclipse for plugin development. My repositories for projects regularly include much more than just an On Disk Project – documentation (yes, I’m weird), Javadocs, a ReadMe.md and and other files pertinent to the project. So I’m used to contributing content outside the NSF when developing and used to regularly refreshing the ODP in Package Explorer and syncing the NSF.
So my initial thought when reading Jesse’s article was “would it work to edit the faces-config.xml in Eclipse with the editor from Web Tools Platform?
It proved a little more involved, but not hugely taxing – thanks to Jesse’s screenshots and documentation for Designer.
First of all, if you just open the faces-config.xml in Eclipse, it doesn’t give you the visual editor. You just get an XML editor.
The first step is to ensure you have an installation that includes Web Tools Platform, which you can check by going to Help > About Eclipse and clicking on Installation Details. On the Features tab, what you’re looking for is Eclipse Web Tools Platform under provider and Eclipse Java EE Developer Tools under feature name.
If not, the easiest way to install it is to go to the Eclipse download site for your version and look for m2e-wtp. The Maven plugins are also needed for building IBM SBT, if you develop with that.
Once you have confirmed you have WTP installed, and specifically the JSF configurator, you need to add the On Disk Project to Eclipse, right-click it and select Properties. We now need to turn it into a faceted project. In the Project Facets section select Convert to faceted form.
Once the project has been set up as faceted, you can create the configuration. You will have a number of options on the drop-down. The problem is XPages isn’t based on an exact JSF version. It has elements of JSF 2.0 ported back into 1.1, the most notable of which are Custom Controls and viewScope. So really, you’re best off selecting JavaServer Faces v2.0 Project. (From what I’ve read before, JSF 2.0 deprecates VariableResolvers in favour of ELResolvers, but the JSF 2.0 editor still has VariableResolvers.)
The important option is then to click Further configuration available…. You then need to tell the project where your Java source folder(s) are. By default, it will try to help youo by creating a src folder. You don’t need that so remove it and map to your standard folder for Java source files. I still use WebContent/WEB-INF/src rather than the Java design element at Code/Java, hence why I’ve selected that.
I didn’t get to select this first time. So what I did was deselected all except JavaScript in the Project Facets area of Properties, then re-select JavaServer Faces v2.0 Project. On the next tab I went with the defaults but deselected Generate web.xml deployment descriptor. As Jesse mentioned, it’s not needed for XPages.
Finally, I disable library configuration. I’m not quite sure what that’s intended for, but that settings seems to be fine.
Now when you edit the faces-config.xml, you get a fully rich editor. You can also define viewScoped managed beans, as well as components and anything else you might want to specify in a faces-config.
Of course after you’ve made your edits, you’ll need to refresh your On Disk Project and sync your NSF.
One caveat is that in the application I was testing, I had jar files as Referenced Libraries. When I sync’d my NSF I had to add those jars again to the Build Path. I’m sure it’s something to do with how adding the project facet changed the project. Whatever the setting, I guess I had not set it back correctly.
One caveat is that when importing into Designer I found it had lost the “Local” source folder, which Domino Designer uses to create Java classes for each XPage and Custom Control. This meant that when I added a new XPage, the build process didn’t make it available. It may have been caused by me playing around to try to get this whole process to work, but it was easily fixed by just right-clicking on the NSF in Package Explorer and selecting New > Source Folder and calling it Local. A build then worked as normal.
Paul we should isolate the editor and then port to DDE. Would be a nice small project (like findbugs integration).