Putting all of you action controls in one basket.
I mentioned yesterday that my boss doesn't like to see the 'Edit' link button on the grid when it's designed for editing. He're almost as keen to see the 'Update' and 'Cancel' buttons gone too.
Wilthout giving away too many clues to my age 8-) I can say that I started working in programming with database engines like Informix, whose forms had all of the controls along the top row of the (80 x 25) screen. These controls (read: text labels) changed to suit the context of the task at hand.
Following on from that, if there were a number of UI elements on the screen, where an action isn't caused by a direct and necessary interaction with the control, the feeling here (in house, I mean) is that the controls should be centralized. This is where r.a.d.Toolbar comes in.
First let me say I'm not talking about never
interacting directly with (say) the grid. If the only control on the page then use the CommandItem, but if there are other controls (in the case of this project Upload and Treeview) then we try and make it so that the user only has to go to one place on the form to find the control to initiate the action s/he wants. Obviously, if I want to change node on the treeview, I click the node that I want or to select a row in the grid, I'll click on the grid.Similrly the 'default' action on the grid is initiated by double clicking.
In this project a secondary function of the grid it to allow the user to edit some elements of the document details shown. To do this I added a toolbar button that puts the selected row in the grid in edit mode.
In keeping with the idea of keeping the controls centralized, once we've gone in to edit mode, I hide all of the buttons in the toolbar except for 2 (previously hidden) buttons with CommandNames of "EditOK" and "EditCancel". Now it won't take the brains of an archbishop to figure out what they do.
If the user selected the "EditOK" button I have to call the code that validates the data, updates my datasource and takes the row out of edit mode.
Because of the way the t
elerik code is written you don't seem to be limited to just doing it their way, so I can get at the data (both the old values and the new) validate and cacnel the update if it's wrong etc.
At the moment I'm struggling to make t
elerik's sample code for extracting updated values from the user form (found in this
article) to work, but I'm not to far off I think.
OK. Maybe I'm rambling now so I'll shut up. I guess I've not really added to the overal sum of human knowledge with this post, but I wanted to show that you don't just have to do things the default way; if your 'house' style requires a different approach, then those clever boys and girls at t
elerik have prolly left you enough wiggle room to do it your way.