Intro to Facelift for Domino01/27/2006 09:52:13 AM
(Repeat of earlier blog content...content repeated here for permanent access)
Now that Lotusphere is complete, it's time for some detailed explanations of the Domino Facelift. While Dwight and I were thrilled that a number of people "got it" and validated the concept, we're also disappointed in ourselves as there were many who didn't get it or failed to see the value in it. Here's the start on a series of articles and screencams to really go through it point by point.
Please remember, this is a framework that is being contributed to the community. This is not a "product in development". Yes, we hope to capitalize on this framework, but from the perspective of making it faster for us to accomplish things for our clients in our own consulting engagements, not from "selling" it. By extension, if it makes things faster and easier for us, and it's available to everybody to build upon, then others can also benefit and everyone should be happy ;-)
What is the Domino Facelift? The driving goal of the framework is to provide a consistent toolset that makes Forms and Views observe and use the properties specified in the Notes Designer. If a property is implemented by the Notes client, why shouldn't it also be implemented by the browser client. If there is a rich UI experience in the Notes client, why shouldn't there also be a rich experience in the browser.
Read More...
As examples, if a form designer has specified the use of a Calendar picker and a "date only" value for a Date field, the Notes client provides it and the browser doesn't. That should come to an end right now!!! It shouldn't take a vastly experienced Notes/Domino developer to hack every form to make one available to the web. On the view side, why the heck don't we have scrolling views, document selection, document preview, type ahead, and a host of other things we're accustomed to from the Notes client. It's only been 6 or 7 years since the Domino web engine came to life, couldn't something have been done by now? Well it hasn't, and it might not ever. DWA (Domino Web Access) gets us tantalizingly close, but it's not readily available to the rest of our development environment.
So it's time to take things into our own hands and provide a framework that does. It needs to be:
Next...on to Forms and how we can deal with them.
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:
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 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:
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.
Now that Lotusphere is complete, it's time for some detailed explanations of the Domino Facelift. While Dwight and I were thrilled that a number of people "got it" and validated the concept, we're also disappointed in ourselves as there were many who didn't get it or failed to see the value in it. Here's the start on a series of articles and screencams to really go through it point by point.
Please remember, this is a framework that is being contributed to the community. This is not a "product in development". Yes, we hope to capitalize on this framework, but from the perspective of making it faster for us to accomplish things for our clients in our own consulting engagements, not from "selling" it. By extension, if it makes things faster and easier for us, and it's available to everybody to build upon, then others can also benefit and everyone should be happy ;-)
What is the Domino Facelift? The driving goal of the framework is to provide a consistent toolset that makes Forms and Views observe and use the properties specified in the Notes Designer. If a property is implemented by the Notes client, why shouldn't it also be implemented by the browser client. If there is a rich UI experience in the Notes client, why shouldn't there also be a rich experience in the browser.
Read More...
As examples, if a form designer has specified the use of a Calendar picker and a "date only" value for a Date field, the Notes client provides it and the browser doesn't. That should come to an end right now!!! It shouldn't take a vastly experienced Notes/Domino developer to hack every form to make one available to the web. On the view side, why the heck don't we have scrolling views, document selection, document preview, type ahead, and a host of other things we're accustomed to from the Notes client. It's only been 6 or 7 years since the Domino web engine came to life, couldn't something have been done by now? Well it hasn't, and it might not ever. DWA (Domino Web Access) gets us tantalizingly close, but it's not readily available to the rest of our development environment.
So it's time to take things into our own hands and provide a framework that does. It needs to be:
- standardizable
- skinnable
- scalable
- scentralized
Next...on to Forms and how we can deal with them.
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
- 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
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:
<field usenotesstyle='false' height='0.2500in' width='1in' multiline='true' borderstyle='single' type='datetime' kind='editable' name='debut'>
<datetimeformat show='date' date='yearmonthday' fourdigityearfor21stcentury='true' zone='never'/>
</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?<datetimeformat show='date' date='yearmonthday' fourdigityearfor21stcentury='true' zone='never'/>
</field>
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:
fl_AttachDatePicker("debut","date");
fl_AttachWidth("debut","1in");
fl_FormatDate("debut", "yearmonthday", "fourdigityear");
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:fl_AttachWidth("debut","1in");
fl_FormatDate("debut", "yearmonthday", "fourdigityear");
function fl_AttachDatePicker(FieldName, parms){
var ThisField = fl_GetField(FieldName)
if(ThisField==null) return fl_FatalError("Null field error on " + FieldName)
g_valType[ FieldName ] = parms
fl_addEvent(ThisField , "change", fl_Validate);
if(parms=='date'){
var img = fl_PickerIMG( ThisField,"/" + g_faceliftDB + "/calendarpicker.gif")
fl_addEvent(img , "click", fl_Date_img);
}
}
The line that actually triggers the datepicker behavior isvar ThisField = fl_GetField(FieldName)
if(ThisField==null) return fl_FatalError("Null field error on " + FieldName)
g_valType[ FieldName ] = parms
fl_addEvent(ThisField , "change", fl_Validate);
if(parms=='date'){
var img = fl_PickerIMG( ThisField,"/" + g_faceliftDB + "/calendarpicker.gif")
fl_addEvent(img , "click", fl_Date_img);
}
}
fl_addEvent(img, "click", fl_Date_img)
And inside the fl_Date_img function we see
function fl_Date_img(){
if(g_DateField == this.previousSibling) {
g_DateField = null
var DATEDIV = DATE_GetDIV()
DATEDIV.style.visibility = "hidden"
} else {
displayDatePicker(this.previousSibling.name)
}
}
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.if(g_DateField == this.previousSibling) {
g_DateField = null
var DATEDIV = DATE_GetDIV()
DATEDIV.style.visibility = "hidden"
} else {
displayDatePicker(this.previousSibling.name)
}
}
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.
