Improving user interaction with the XPages date picker

Problem

When using a date picker in an XPage, user’s can still type incorrect data into the field which requires validation when saving.

Solution

Don’t let them type anything into the field and provide the calendar picker when they click into the field.

When you turn an XPage Edit Box into a “date field” you can select to use the date/time picker popup as we see below

Creating a date field with picker
Creating a date field with picker

But when that translates onto the webpage, the user can still type in the field and enter any old rubbish, which then needs to be validated.

Users can still type rubbish into the date field
Users can still type rubbish into the date field

Avoiding unnecessary validation is good for two reasons:

  • Less user frustration when they get the input wrong
  • Less code to write

We are going to change the form dynamics so that:

  • When the user clicks in the field
    • The calendar popup will appear
  • When the user tries to type anything
    • Nothing will happen (so they can’t type anything)

We can achieve this by adding a simple function to the onClientLoad event of the XPage.

First we have to look at the created HTML for the date control in the webpage.

Date field container for the Edit Box and the Calendar Button
Date field container for the Edit Box and the Calendar Button

What we can decipher is that the XPage has created a <SPAN> container (amongst other things) around the Edit Box and the Calendar Button. However, we do not know the name of the function which is called when the button is clicked (it is dynamically created as part of the dijit widget).

We do not need to know the function name because we can programmatically trigger the onClick event of the button.

The following code works like this:

  • When the onFocus() event of the Edit Box is triggered the the onClick event of the calendar button is triggered
  • When the user tries to type in a value they are prevented from doing so

in the clientOnLoad event of your XPage or Custom Control add

	improveDatePicker("#{id:contractTermDate1}")

and in a script library add the following

function improveDatePicker(idTag){

	//Select the BUTTON within the container
	var calButton = x$(idTag+"_Container", " .dijitButtonContents")
	//Select the dateField
	var dateField = x$(idTag)
	//When focusing on the field click the button
	dateField.focusin(function (){
		calButton.click()
	})
	//When pressing a key in the field
	dateField.keypress(function(evt){
	//prevent the event from completing
		evt.preventDefault()
	})

}
Clicking in the improved date field
Clicking in the improved date field
Advertisement

16 thoughts on “Improving user interaction with the XPages date picker

  1. Marky you beaut. This is an excellent easy to follow post.

    1 question:

    You could add a dojo date/time control if you have the extension library. Would that not be the better solution?

    Cheers

    • DOH – I didn’t even know that was there – oh well, great minds think alike I guess 🙂

      If you don’t have the extension library, my manipulation does the same thing as the xe_djDateTextBox “Dojo Date Text Box”

      • Hi Marky. Make no mistake….there are many that don’t use the extension library.

        If you go to my showcase, in the example capture form tab, i actually make use of the dojo date field, but it looks a touch different because i’m using the Claro Theme. I like how it shows a dialog image instead of a date icon.

        I’ll be blogging about my showcase page very soon, and will explain what i’m using on the page.

        http://showcase-xsp.ukuvuma.co.za

  2. What’s the pros and cons of this approach vs. using the straight dojo date/time picker. Where it’s an editbox with DojoType set rather then the built in XPages control? I’ve not used it in a long time but I thought just using pure Dojo would also bring up the calander when clicking in the field.

    • If you are going hardcore and doing it manually you will get a better solution. 😉
      But for those who just like to use the IDE interface that is probably a step too far.

      As with the previous post on the type ahead, this is as much an investigation of how XPages work under the cover of the web page, as much as anything else.

  3. xp:view xmlns:xp=”http://www.ibm.com/xsp/core” dojoParseOnLoad=”true”
    dojoTheme=”true” dojoForm=”true”

    xp:this.resources xp:dojoModule name=”dijit.form.DateTextBox” /xp:dojoModule /xp:this.resources

    xp:inputText id=”inputText2″ dojoType=”dijit.form.DateTextBox” /xp:inputText

  4. What about Accessibility?
    Older versions of Dojo (they have recently corrected this 1.5 plus) the date time picker weren’t accessible so the fallback was to type in the date into the editbox.
    In this case the window may need to remain open.

    • Paul that is an excellent point – and also highlights the 1000lb elephant in the room when I am making this client side manipulations – I have no control over the HTML generated by the server and it *could* be version specific. I really need to put a qualifier on all of these articles for what version and test any backwards comparability where I can.

      thanks again

  5. Marky,

    Love these CSJS solutions you are adding to the xpages standard controls. I would urge you to add all of your “tricks” to xsnippets, so we have a single place to search when I can’t seem to remember how that was done.

    • As Paul pointed out – these may be version specific “hacks” at times and so I am a little loathe to add them as XSnippets. But I do take your point and will certainly consider it when I know that something is version proof (or at least as much as I can make it).

      I do have one XSnippet for the x$ function – but I actually need to update that again for the v0.3 with dojo.query added (https://xomino.com/2012/02/28/x-update-for-dojo/)

      • You do make a good point about things like this being version specific as IBM has not promised to not change their implementation of any of these components and I would guess at some point they will. Maybe just a note with what versions you are aware of this working with would help, so at least it wouldn’t mislead anyone.

  6. Mark – I agree with Toby… don’t worry about posting your stuff.. Post it anyway and just clearly mark it when version this is known to work on. Who knows.. if it does change in the future maybe someone else will improve it and post it back. That’s the main goal of opensource.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s