Post | mennovanslooten.nl/blog

Introduction

For this second tutorial I decided to show you an easy way to create your own form components. We all know that form elements like radiobuttons, checkboxes and selects are notoriously hard to style. Fortunately, the Backbase Presentation Client allows us to easily create our own. If you're curious, take a quick look at the end result.

Goals

With these components I had very specific goals in mind:

• They have to function like normal elements. Neither the user nor the back-end should notice any difference.
• For the user this means it should be keyboard-accessible.
• For the back-end this means it should be 'submittable'.
• Oh, yeah, it has to look good.

The setup

In this case we're keeping it as simple as possible. Nothing fancy here. For one checkbox this will be our code:

<a b:behavior="checkbox">
  <input type="checkbox" name="check" value="1"/>
  <label>Check 1</label>
</a>

The code for one radio looks remarkably similar:

<a b:behavior="radio">
  <input type="radio" name="radio" value="1"/>
  <label>Radio 1</label>
</a>

As you can see, there are actual radio's and checkboxes in there. These will make sure the controls can be submitted. Of course they look like crap so they will be hidden with CSS later.

Another thing you might notice is the a tag around everything. This makes sure that the custom element can receive focus and keyboard events.

Adding interaction to the checkbox

As I've said before: the power is in the behavior! For a checkbox it's really not very hard. If you click on it it should toggle its (selected/deselected) state. Here it is event by event

<s:event b:on="construct">
  <s:task b:test="input/@checked" b:action="select"/>
</s:event>

As the custom component is constructed it checks if its input has a checked attribute. If that is the case it selects itself.

<s:event b:on="command">
  <s:task b:action="select-deselect" b:target="input"/>
  <s:task b:action="select-deselect"/>
</s:event>

Now, when it receives a command event (like when the user clicks on it) it will toggle its own selected state and that of the input inside it.

<s:state b:on="deselect" b:normal="checkbox"/>
<s:state b:on="select" b:normal="checkbox checkbox-select"/>

And finally we define the CSS classnames that should be applied for the selected and deselected states.

Adding interaction to the radiobutton

The radiobutton is a little more complex. Not only should clicking it select itself, but it should also deselect any radiobutton with the same name.

<s:event b:on="construct">
  <s:task b:test="input/@checked" b:action="select"/>
</s:event>

The onconstruct event is almost identical to the one of a checkbox, only this time it triggers the command event, as if the user has clicked it. This way we keep the deselecting of other radio's in one place.

<s:event b:on="command">
  <s:task b:action="deselect"
    b:target="ancestor::form[1]//a[input[@type='radio' and @name = current()/input/@name]]"/>
  <s:task b:action="select"/>
</s:event>

On command it does two things. First, it deselects all radio's with the same name. (check out that bizarre XPath expression!) Secondly, it selects itself. The select-event is handled like this:

<s:event b:on="select">
  <s:task b:action="set" b:target="input/@checked"
    b:value="checked"/>
</s:event>

Unfortunately, a radiobutton does not support the select event by default (like the checkbox does). So to select the radio, it sets the checked attribute to "checked".

<s:event b:on="deselect">
  <s:task b:action="remove" b:target="input/@checked"/>
</s:event>

And to deselect it, we remove the checked attribute completely. What's left for the radio's is to define the classnames for each state:

<s:state b:on="deselect" b:normal="radio"/>
<s:state b:on="select" b:normal="radio radio-select"/>

The wrap-up

So now we have our custom components, with their own selected/deselected states and corresponding classnames. To beautify them I borrowed the look-and-feel of Mac OS X. These are the images I used:

That wraps it up! We've got our custom checkboxes and radio's and they're looking good! They're not completely identical to regular checkboxes and radio's so there's plenty still to do, if you want to:

• They don't support a 'readonly' state.
• Keyboard navigation between radio's is a little different.
• They don't have any 'hover' effects.

Apart from that, I think they turned out really well. I hope you enjoy them.