My XPage journey being laid out before you, I now come to a point where I want to say what we need in order to be more productive in XPage development.
- The IDE must be optimized. This must be done in a few ways.
- Nested functions must also be listed in the left side panel of the SSJS editor.
- All functions must be listed alphabetically in the left side panel of the SSJS editor
- While binding fields to a control, the field names must be sorted alphabetically and not randomly. It would be helpful if this alphabetizing was done ignoring caps.
- It would be helpful if field names while binding data were also available when using a separate database as a source.
- Adding to point f, it would be nice if fields from a selected list of subforms could also be added to the binding options, and that it would work more like type-ahead.
- It should be possible to completely ignore the drag and drop and often buggy nature of the Design panel. I would request that the source editor be optimized for direct xml input. See visual studio to see what I am talking about.
- For those projects where the customer does not want to install the openNTF Domino API, programmers must fall back on the IBM Domino API. For this, a must have would be a detailed documentation on the use of the API, when to recycle, when not to recycle, and the design patterns that they see as correct and incorrect. Most designers are left completely in the dark and set up to fail when it comes to recycling and memory management.
- Setting properties for multiple controls in background documents was very easy. Highlight a few controls, add some code, make a few clicks and done. The designer/programmer never had to search through the property window long before finding what was needed. The following are things to consider:
- Too many clicks are needed to configure controls on the XPage. There must be a way to optimize this.
- Support for changing the values of multiple values at the same time.
- Themes. You can create your own theme in theory, but a lot of stuff is based on dojo and, most of the time, to get what you want you need to get into the innards of Dojo theming. In the case of OneUI, you have to first understand how it all works. There should be better theme development support in designer. This should include altering the Dojo level themes as well as stuff on OneUI. Optimize this, and you will increase designer productivity by a lot and make point 4b a lot simpler.
- With the openNTF Domino API, this point is moot, but get rid of the NotesException. Completely. It. Must. Go. I need to handle a SecurityException (User does not have sufficient ACL access) differently than a NullDocumentException (document with given key not found in view) and that differently from IllegalStateException (document was removed or recycled). By having one exception for everything and just changing the “Text” variable (an already bad design), the developer cannot really alter the exception handling without parsing the Text first.
- Some issues, whether bugs or not, need to be addressed. They may not be seen as bugs to the creators, but to the end user who only sees something different than what he sees in the client, it is wrong.
- Dynamic categorization in views must also be indented. Building a view navigator is all well and good, but it is not what he sees in the client, and for many customers that is unsatisfactory. This is true with the dynamicViewPanel, and the ViewPanel controls, and possibly others that I have not tried.
- The Calendar control is a nightmare. It is complex to set up, buggy in IE, and questionable in other browsers. It needs a major overhaul and fast.
- I am sure I could think of plenty more if I gave myself the time.
XPages are a good idea in theory. At its core, it offers a relatively easy way to get a Notes Database open to the web quickly while, under many conditions, not sacrificing usability. It offers solutions to the current Big Data problem where a single Database cannot contain the data it needs to by offering a behind the scenes and invisible way to access numerous databases simultaneously, whether they are Domino, SQL, or a mixture. The development of applications is a headache at best, and a catastrophe at worst. XPages show great potential, but lack what I believe to be real support and backing from IBM. Instead the XPage development community is left to fend for itself. If we want XPages to succeed in the current market, than it must be able to compete alongside Microsoft Sharepoint, JSF/JSP applications, and other high end platforms. This includes programmer efficiency, usability, extensibility, lack-of-buggy-ness, and support. Call me a masochist, but I want XPages to succeed.