Skip to main content

Simple question seek short answer - Data Binding!

2 replies [Last post]
javaneze
Offline
Joined: 2003-06-13
Points: 0

Hi! I am trying to understand the whole mechanics of JDNC and I have a simple question. I guess I am not 100% sure about that.

What is the default data binding structure introduced JDNC. Well I mean is there any equivalent of DataSet (in memory smart table with serialization capablities etc) like components found in ADO.Net ? I am reading about the classic DataModels etc and TableDataModels. Is this the way that we are going to form out data in order to feed the GUI components (tables lists etc).

I am sorry if my question is too obvious ...or if there is an answer that I could not find. Actually I was wondering if JDNC in general could provide a package such ADO.Net ...or are they other projects which provide such components!

(I am aware that in some cases the answer might be JDO..I am just seeking for other alternatives)

Thank you for your time!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Amy Fowler

jdnc-interest@javadesktop.org wrote:

> Hi! I am trying to understand the whole mechanics of JDNC and I have a simple question. I guess I am not 100% sure about that.
>
> What is the default data binding structure introduced JDNC. Well I mean is there any equivalent of DataSet (in memory smart table with serialization capablities etc) like components found in ADO.Net ? I am reading about the classic DataModels etc and TableDataModels. Is this the way that we are going to form out data in order to feed the GUI components (tables lists etc).

This is a very good question as the answer is hard to gleem directly
from the current, admittedly rough, APIs.

Our general thinking is to provide support for easy data-binding to a
couple of well-established data model types:

- WebRowSet (disconnected JDBC RowSet functionality which has been
developed as part of JSR114); This in theory provides the serialization
and transaction-handling required for dealing which rich, 'sometimes'
connected clients that need SQL database connectivity.

- JavaBeans (& collections of JavaBeans); A fair number of applications
have designed simple data models around these patterns, tools support
them, AND they happen to be the type of object returned from JAX-RPC,
which makes it very convenient for WebServices.

Clearly there are many more flavors out there (EJB, CORBA, JDO, on and on)
but we figure we've got to start somewhere and we prefer to start with
patterns that are widely adopted and reasonable to understand.

The model we currently envision is that the application defines their
data models as one or more of the above, with JDNC supporting common actions on
those data models, such as inserts, updates, local caching (for offline),etc.
Obviously the application will also define custom behaviors (business logic, etc)
for those models. This model layer is really the app's bread and butter and
it should be completely independent of the UI (MVC-101).

Then, the application defines the user-interface and *easily* binds those
UI components to elements in its data-models, with JDNC hiding most of the Swing
glue required to implement the mechanics of those bindings.

JDNC currently exposes the org.jdesktop.swing.data.DataModel interface because
the binding mechanism uses it internally to abstract away the interaction
with a given data model (bindings don't need to worry about whether they are
talking to a RowSet or collection of JavaBeans). However, the intention is
NOT to require apps to deal directly with the DataModel interface, unless
they benefit directly from the abstraction. An app should be able to easily
bind directly to a column in a RowSet or a property on a JavaBean without
touching the DataModel interface directly. The API isn't quite there yet.

One case where DataModel was useful to an application was in the Web Service
client Mark Davidson built for his JavaOne talk. In his case he was dealing
with accessing a sequence of JavaBeans (from successive WebService calls)
and by using DataModel the app was able to replace the bean transparently
behind the JavaBeanDataModel instance without having to re-bind to the new
java bean instance each time.

Now Rich Bair has raised the very reasonable question on a separate
thread (http://www.javadesktop.org/forums/thread.jspa?threadID=3851&tstart=0)
whether we should be adopting RowSet as the single abstraction for all data,
regardless of whether it comes from a database. It's worthy of exploration as
we embrace building RowSet support, but the downsides may prove painful.

I also considered using javax.swing.table.TableModel, which has much of
what we'd need in such an abstraction and, contrary to assumptions, has
absolutely no JTable or UI dependencies (I sure wish it lived in a java.model
package!). Ultimately I opted not to use it because of its table-centric
nomenclature, but I suppose that would also apply to RowSet.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

javaneze
Offline
Joined: 2003-06-13
Points: 0

Thank you very much for your thorough answer!