Yellow is the New Blog

Back in December, Nathan asked me for a quick proof of concept of using Decepticon in conjunction with ExtJS to provide easy styling of Domino forms. It was even easier than I thought it would be, so a couple days later (actually, I think it was the same night... can't remember now) I sent him a link to an example implementation... and promptly forgot all about it until he mentioned recently that somebody else was interested in the same functionality. I figured I might as well clean it up a bit to allow it to be even more modular. The result is a subform that, when added to any form, automatically renders all fields in their Ext.Form equivalent. And... it works with or without Decepticon. It's just easier if you do use Decepticon.

To see this in action, this is how a fairly typical form might look when developed specifically for Notes client usage. Pretty standard, right? Two-column table, one column for field labels and another for the fields. This is what the same form looks like when the subform is included. The table still looks crappy, of course, so you'd want to do some additional cleanup to make the form itself look nice, but for the actual fields, here are a couple of the "easy wins":

• Date-only date fields get a date-picker... not 'cause you flagged them somehow, just because the subform knows it's a date field.
• Similarly, time-only fields get a time-picker. NOTE: if you've specified that the field should display date and time, this still gets confused and renders a boring text input.
• Dialog lists, comboboxes and listboxes get converted to the fancy Ext type-ahead combo thingy. Ironically, "Allow values not in list" currently has the same limitation as above: boring text input.
• If you populate the "Help Description" property for a text field, it renders it similarly to how the "Field Hint" property behaves in Notes: the description displays as a faded background to the field, but unlike in Notes, if you blur out of the field when it has no value (even if it used to), the hint returns. In retrospect, I probably should have pointed this to the "Field Hint" property instead, so feel free to tweak the XSL accordingly.
• Rich text fields get rendered as full-blown WYSIWYG HTML editors. The usefulness of this feature is the most questionable of the bunch, as you probably don't want your rich text fields stored as HTML. On the other hand, if you're already setting your rich text to "Store contents as HTML and MIME", this may be a perfect fit for you. In all honesty, I haven't used any of this in a real-world application yet, so I'm curious to hear what your results are if you do.
  

The example database can be downloaded here.