The table below will be filled with information corresponding to actions on the fields above
The Accept and Reject buttons, when enabled, allow the user to play the part of the server which might validate the information received and accept it or not. Since we don't have a server to play with, we play the server ourselves by clicking on the desired test response.
The example shows several ways to interact with the user with various controls.
I use the built-in formatter from the DataTable which already draws an active checkbox.
There is no need to assign an editor since the checkboxes are already active.
I listen to
checkboxClickEvent and when fired I pick enough
information from the new value and the old value plus column information and the record's
primary key to assemble a message to the server to accept those changes.
I use the
submit function to do the part of the method that would
submit the information to the server. The information it receives in its arguments
goes to be displayed in the bottom table. If a callback function is assigned, it will
also enable the Accept and Reject buttons. These are intended to simulate
possible server responses and see how each control can handle it.
Radio buttons are somewhat harder than checkboxes because while the HTML controls
are mutually exclusive, the values within the recordset are not
(they don't even know they are being represented as radio buttons) and while you get
radioClickEvent fired for clicked checkboxes on or off, you don't get anything
for those radio buttons that get unchecked due to some other becoming selected.
So you know when they are being turned on, but not when turned off-
I use a custom formatter function which is not very different from the standard one but it adds a crucial part, it saves a reference to the last radio button checked so that if a new one becomes checked you know what to uncheck. This is done in the event listener so that before setting the value for the new radio button checked, I reset that of the previous one, both in the recordSet and in the visual interface.
In IE there is an anomaly where you can have more than one radio button in the same group set at once. When this page is first loaded, the data array in the DataSource has two radios checked. On its own, IE draws both checked, Firefox only the last one checked. Of course the source data is wrong, after all, there shouldn't be more than one of them on but I added a parser function to the DataSource so that it only keeps the last one (actually, the DataSource parses the records from the last one to the first so the parser allows only the first true to get through, which happens to be the last)
I use the standard formatter for dropdowns Fixed: , but since it has a bug, I override it
with a corrected version at the begining of this page. I listen to
which, though not documented, it exists. In that event I, once again, collect information and
submit it to the server and, depending on the reply, I update the information on the client side.
I present two ways of handling actions, via buttons or images. In the buttons I use the standard
DataTable method to format buttons which takes the field data and uses it for the button's face.
For the images, which are more compact, I pile three of them in the same cell, each within a
link. I use a page marker as the link
href which can later be easily extracted
to find out which of the images in the cell has been clicked
and causes no conflict with the expected format of an actual hyperlink.
The listener for the
buttonClickEvent is simple enough, once again, I gather
the record and column information but since the button has no actual value to change
there are no new or old values, both are set to N/A (not available).
The listener for the
linkClickEvent is a little more complicated
because it is shared with the textbox control. The first part and the else part
of the conditional asking if the column is the one that corresponds to the textboxes
is quite similar to that of the other controls.
There is no standard formatter for this one either so I draw the textboxes myself each
followed by a couple of
<span> elements, each containing a version
of the action images. The first span has the opacity set to ghostly to make the images look as disabled,
the second span is not displayed initially and has the images surrounded
<a> anchor elements.
I listen to key presses on the DataTable and if I get any I first try to find out where in the DataTable they happened (they might be keyboard shotcuts used elsewhere). If they happened within any of the textboxes, I switch the two spans so that I make the active images visible and the ghostly inactive ones invisible.
When any of the action images is pressed, they are grayed out again. If the Reject button is pressed, the textbox is set back to the value taken from the recordset, which has not been modified yet. If the Accept button is pressed, I read the value from the textbox and assemble the information for a call to submit. On the callback to that submission I either update the recordset with the new value or revert the textbox value to the original one.
IE doesn't does not support the
opacity style, thus there is a little
playing around with a IE-only
filter style attribute which is only
valid on certain HTML elements with certain attributes. The easiest solution would be
to have two sets of icons and switch in between the active set and the inactive one.
I just wanted to play with opacity so there it is. I won't do it again, promise, better to have two sets of icons.
An unintended side-effect of this is that you can type in any of the textboxes and then go to another one and type some more and finally submit any of them in any order. This might be a feature in some cases but it would also give a chance to the user to go and change a textbox in another line and forget to ever submit the first one. That is the good thing about the standard editor that comes with the DataTable, only one editor can be active at anytime for the whole DataTable and a new editor won't pop up until the previous has been dismissed, either accepted or cancelled. This is much safer.
Consequently, I cannot recommend using this type of control except for the most trivial tasks.