This is the 2nd article in the introduction to the Domino Facelift. The first article's here (updated link) if you need to start from the beginning.

Now that you've got the idea of what we're trying to accomplish with Facelift, let's move on to talk about Forms and how the framework addresses them. There are a LOT of properties in Form design that the Domino web engine doesn't recognize and render to the browser. Some examples:

• Date field: calendar picker
• Date field: selection of date only, time only, or date and time
• Names field: Address picker
• Dialog: Allow values not in list
• Dialog: Use View to select choices, Use ACL to select choices
• Number field: right justification of data
• Number field: numeric data provided
• All fields: width
• All fields: help description

There are many, many more. I'll get Dwight to provide a more complete list. What are your choices as a Notes developer for dealing with this?

• Forget about it and just let Domino render as it sees fit...bad
• Decide what you want and write javascript into the form design for the things you think are important...better
• Figure out a standard way to implement every property that's been specified in the Designer properties....good
• Do the above AND make it global so when a decision is made that a rendering style has become "stale" or "not good enough anymore" it can be changed in one place and implemented globally across all apps...great

That's what we're after here. Enough chit-chat.

When you take a Notes form and render it to the web browser, you can't look at "View Source" and get any idea what the form designer intended. If Domino decided to ignore a property setting, that's the end of it, no more info at the HTML level. We need a way to get back to the form design and see what was SUPPOSED to happen. Enter DXL.
Reading the DXL of a form, we can see many of these lost attributes. For example, here's what we get when looking at a date field:
We can learn a lot from this. The Designer said, "I want a Native OS style and I want the field to be .25in high and 1in wide. I want a border, the name of the field is debut, it should show a calendar picker, it should be date only, and it should be formatted American style and use a four digit year. There's quite a bit of information here. Now what do we need?

We need a way to get this knowledge to the browser and into something that the browser understands. Well, the browser understands html, javascript and css. It also understands transformation through XSLT. We've decided to go the first route. Turn that additional information into a series of javascript function CALLS, and let something at the browser figure out what to do with it. Here's an example of the javascript calls that could be made from that DXL information:
If these javascript calls are attached to the HTML page, whether at initial load or later, then there can be a javascript library that knows what to do with those calls. Let's take a look at the first one:
The line that actually triggers the datepicker behavior is
And inside the fl_Date_img function we see
And finally you see the implementation of the displayDatePicker which is a big chunk of code borrowed directly from Julian Robichaux. And that's the whole point. There are people doing good things out there. The problems of the Domino Web Engine aren't new, and people have been building cool things to compensate for them. See Matt White and his Name Picker. See Bob Obringer and his Ultimate View Navigator.

The issue isn't that these things don't exist, the issue is how we can consistently and globally apply them...whenever necessary, wherever specified by the Designer in the form properties. Let's get away from one-offs and instead recognize that automated calls can be produced for these widgits and behaviors. Then, we can put more effort into building great widgit implementations rather than always dealing with how do I wire it and plug it in.

Do you get it? Are you with me?

Next topic: How the javascript calls get attached to the form.

1. Mark Vincenzes01/28/2006 10:34:53 AM

Where is the first article? The link in this article gets me to a "couldn't find design note" error.

---

2. Lance Spellman01/29/2006 04:31:47 AM
Homepage: http://www.workflowstudios.com/lance/blog.nsf

My apologies and thanks for spotting it. I'd originally started the thread in my blog and moved it over here. The link has now been updated.

---

3. Dwight Wilbanks01/29/2006 12:48:50 PM
Homepage: http://www.dwightwilbanks.org

The fl_PickerIMG() is what was broken in the labs on Thursday. My initial implementation of it only works if the field is the last thing in its parent element. In my case, I almost always create fields inside tables so, the field is the only thing in the table. I coded for the other event, but, didn't actually test it.

---

4. Nathan T. Freeman01/30/2006 12:13:00 AM

Lance, lemme see if I have this right... you're doing DXL extracts on the Domino form, transforming that into an XSL that is then applied to the Domino-generated HTML form?

If so, that's very very cool. And it's exactly the technique that I recommended to IBM 3 years ago. Nice to see someone's coded it at last!

---

5. Lance Spellman01/30/2006 04:33:01 AM
Homepage: http://www.workflowstudios.com/lance/blog.nsf

Nathan,

Not exactly, however Mac Guidera was doing something like that in his session at Sphere. Didn't see it, so I can't comment on it directly. We made a conscious decision at this point to not implement the behaviors as XSL. Although longer term, I think that's the solution. In the short run, we need standard JS calls to good implementations (date picker, name picker, value not in list, etc...) all of which whill need to be implemented as DHTML with JS DOM manipulation. Once there is a good library established for these components, it wouldn't be too difficult to go back and implement this as XSLT. A further step would be to hook this into the Domino Web Engine itself (as an nsfhook) to then implement the whole shebang.

---