Databound dragging in SmartClient 7.0

One of SmartClient’s most powerful and popular features is built-in support for dragging between grids and trees that you can simply enable with property settings. That’s pretty easily understood and has been a part of SmartClient since 2001. What’s new and more interesting is what should happen when you have a databound grid connected to data from web services, SQL tables or other permanent data stores, and then you perform a drag. Can we ascribe any sensible, user-intuitive meaning to dragging an item from one databound list and dropping it on another?

Forgetting for a moment the rich diversity of things that a SmartClient DataSource might be connected to, let’s just think in terms of SQL. If we have grid A showing SQL table A and grid B showing SQL table B, what does a drag of rows from A to B mean? Does it even have a sensible meaning at all? And if there is a sensible meaning to be inferred, what SQL operations does that imply?

For release 7.0 of SmartClient, we have added a number of automatic databound dragging behaviors to grids; these arose as a result of asking ourselves these questions. It turns out that there often is a sensible meaning to be inferred from a drag of rows from A to B, a meaning that a user might even describe as “obvious”.

Firstly, it turns out that changing a dropped record so that it conforms to the drag target’s search criteria will usually give sensible and intuitive results if the two grids are bound to the same DataSource. For example, imagine we had two lists, both bound to the Products DataSource, where has one search criteria that causes it to show only Products of type “widgets”, and the other has search criteria causing it to show Products of type “gizmos”. If the user drags something out of the gizmo list and drops it on the widget list, the meaning of that gesture might seem obvious to the user – she intends that the item be recategorized as a widget. Similarly, if we were in a part of the application where new products are being created, a clear inference can be drawn from the drag gesture: the user intends that a new product be created that is just like this one, but in a different category.

This is one type of code-free databound dragging behavior that SmartClient 7.0 supports. We add or change properties on the dropped item, so that those properties now match the selection criteria of the grid, and then update the record through the DataSource. The record changes in the SQL database and, as a side-effect of that, moves from one grid to the other – SmartClient’s intelligent cache synchronization ensures that all databound components are automatically updated to reflect any changes in the underlying data. These screenshots show the result of a simple, code-free drag operation.

Another, potentially even more interesting, case where we provide automatic databound dragging behaviors is when two grids are bound to different DataSources, but those DataSources are related via a foreign key relationship. Again, it turns out that mutating the dropped record so that it conforms to the target grid’s search criteria gives sensible and intuitive results. For example, let’s say we have a grid bound to the employees DataSource, and another bound to the TeamMembers DataSource. TeamMembers holds details of which Employees are in which project teams, and thus has a foreign key reference to Employees (declared in the DataSource). So, if our TeamMembers grid is showing members of the “Online Billing” project team, what does it mean if the user drags a record out of the Employees grid and drops it on the TeamMembers grid? It seems clear that they intend that employee to be added as a member of that project team.

In this case, SmartClient will create a new TeamMembers record, automatically setting the foreign key reference from the equivalent field on the dropped employee record, and the project code from the selection criteria of the grid. Again, a couple of screenshots show this (and give me an excuse to show one of the pretty new skins)

We also provide an override point in this logic, so data manipulations can be as complex as you need them to be for any given use case. We’re sure people will find uses for this that haven’t even occurred to us, creating applications that make intelligent use of drag and drop to provide natural, intuitive UI’s.

At the top of this article, I asked you to forget about all the things that a DataSource might be connected to; I’ll now ask you to remember again! We’ve looked at these examples using the language of SQL tables here, but of course a DataSource can be connected to anything;. So really, we’re potentially talking about a drag from a WSDL web service to a corporate LDAP server, or from a legacy mainframe app to an EJB stack. DataSources truly are a wonderful thing…