Skip to main content

A little disappointed by the DataSet API

26 replies [Last post]
aaime
Offline
Joined: 2003-06-10
Points: 0

Hello everybody,
as you can see by the subject, I'm not very happy about the above API... after working for a bit in an ASP.NET project, using ADO.NET, I just fainted when I saw the API.

Now, I think I should explain. The API is very good for SQL oriented guys, that would just use rowsets, and in fact I should say it's better than ADO.NET, since it supports joining out of the box (in ADO.NET there is no direct way to ask for a joined view, unless you perfom the join against the database, of course).

Yet, I'm not that kind of guy. I like object models, data and behaviour put togheter in the same place, object graphs with real relations. I guess it's a matter of taste, but working with DataSet just makes me go back into my Visual Basic days (oh, the horror), with data on one side, user interface on another, and the logic sprinkled all over in the user interface itself and/or in function libraries.

I see that DataRow can wrap an isolated Bean, but in my opinion it cannot wrap an object graph. With beans, you don't have a predefined structure, the set of properties that you can extract thru property chaining, like Person.Address.City.inhabitants, for exaple, is not endless but for sure quite big. Moreover, some paths can be forbidden, in a sense that some collection or properties can be lazy loaded, and unavailable on the client side (that's what happens with Hibernate, that I use, and I guess also with JDO and iBati)

What I mean, is that object graphs does not fit with the DataSet API. Yes, you can try to hammer an object graph into a DataSet, creating a DataRelation for each property that points to another bean, hammering togheter lists attached to different beans in order to re-create a two table relation, but it would be awkward in my opinion.

I'm working part time on a data binding and validation library especially conceived for beans, and I would like to share it if you want to see it (as soon as I hammer down some details and add some javadoc, it's still not ready), but before I would like to hear your opinion.
Mine is that the DataSet API is very good for SQL oriented operations, but it's no silver bullet, and should not be used for everything (especially for object graphs).

Comments, opinion, even flames are accepted :-)
Best regards
Andrea Aime

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ragnarw
Offline
Joined: 2003-10-26
Points: 0

Hi Erik,

> For the last 10 years, every corporate application
> that I have developed requires accessing data from a
> relational database. Since Swing has never had a
> standard "binding" framework, we have always used
> something else. (VB, PowerBuilder, Oracle Forms,
> etc.)

So our experience is very different. I have never worked with 2-tier applications where clients access the database directly, they have all accessed the database through some sort of application server. Still, if I was to develop a 2-tier application I would strongly consider using an ORM framework or at least a simple DAO layer to get a OO JavaBeans domain model. I consider it good practise to layer applications to shield business logic from the persistence/transport mechanism. I thought the benefits of doing so were well known and accepted.

> The industry has generated tons of new
> frameworks to support persistence and bridging the
> gap between objects and tabular data, but the biggest
> missing piece was binding. JDNC FINALLY gives Swing
> the standard binding layer that has been missing.

And the solution is to scrap the bridging and bind to the specific relational data instead of to the common data model that virually all bridging technologies offer, namely JavaBeans?

And there are quite a few other points here to consider. Binding JDBC directly to GUI widgets makes applications hard to maintain and extend. While this may be acceptable in some circumstances it certainly has negative implications in other. As a relavant comparison, have a look at the Web-client world and using JDBC directly from JSP code. This is generally strongly discouraged, and only recommended for prototyping and testing. Once again, the reasons are well known and should not have to be repeated.

And it is not just a question of preferring JavaBeans to JDBC or OO over relational models. Building on the Web-client experience, I fear that binding JDBC directly to Swing components in JDNC will make it hard to add GUI-related services to the higher level JDNC components in a generic manner.

I am thinking of authentication/authorization/Copy&Pase/Drag&Drop/sort/filter/CRUD-operations and all other stuff that we want BETWEEN the widgets and the persistance layer (or domain model/communication API).

There are huge benefits of having ONE consistant component model. For example, it will be hard to implement generic CRUD (Create, Read, Update, Delete) operations if the model is not standardised. If you choose JavaBeans as the one and only standard domain model in JDNC, it will be much easier to add such services. Providing specific binding to JDBC, WSDL and whatnot in the GUI will lead to a never ending story of hacks in the JDNC component architecture.

Experience tells me that there has to be some sort of layering here to provide generic services in a framework and I don't see this layering in JDNC. On the contrary, the DataSet binding points in the direction of no layering at all.

This is also why I miss support for the N in JDNC. If no generic networking support has been thought out at v0.7, how is that going to be added later? I am afraid it will be hard to add as an afterthought without major modifications to the architecture.

> From a certain viewpoint, the industry has wasted
> d years recreating the same functionality that JDBC
> has always had. ;) I don't need
> yet-another-persistence-layer, I needed a binding
> framework 10 years ago.

No one is asking for another persitence layer, Erik. We are asking for support for JavaBeans, the Java standard that has been around since 1996 and are embraced by the whole industry as THE Java component model.

I see from Richards post that it will be adressed before v1.0 and that good to hear.

But as argued for, this is not just about supporting JavaBeans binding, the question about pros and cons of choosing a standard model or not should be considered.

>> Another related topic: what's with the N i JDNC?
>> As far as I can see there are no truly network
>> enabled components at version 0.7. Am I missing something?
> Don't forget the 'D' for Desktop. ;)

I don't. But Swing components are already on the desktop, and as I said I see that these are beeing improved in JDNC and thats good. I look forward to use them.

Sorry for a long post but I really want JDNC to be a success as much as anyone.

Peace and good night from Norway! :-)

/Ragnar

evickroy
Offline
Joined: 2004-07-23
Points: 0

> So our experience is very different. I have never
> worked with 2-tier applications where clients access
> the database directly, they have all accessed the
> database through some sort of application server.
> Still, if I was to develop a 2-tier application I
> would strongly consider using an ORM framework or at
> least a simple DAO layer to get a OO JavaBeans domain
> model. I consider it good practise to layer
> applications to shield business logic from the
> persistence/transport mechanism. I thought the
> benefits of doing so were well known and accepted.
Yes I know. Some frameworks have been available for quite some time, such as Oracle's ADF framework, but can be very cumbersome and far less productive than other non-Java tools. Separating your business logic from the presentation layer is pretty simple and doesn't really require an ORM framework. Currently, J2EE doesn't exactly keep them completely separated, so there isn't a silver bullet here.

> And the solution is to scrap the bridging and bind to
> the specific relational data instead of to the common
> data model that virually all bridging technologies
> offer, namely JavaBeans?
I didn't say scrap it. I just said that I haven't actually had a need for yet another persistence framework. Oddly enough, none of the RAD tools that have made us highly productive has had this much difficulty with binding or a persistence framework. They are all JDBC or relational data based.

Of course, I'm not talking about self-service or shopping-cart application, however, I'm talking about real-world, mission critical, business applications. ;)

>
> And there are quite a few other points here to
> consider. Binding JDBC directly to GUI widgets makes
> applications hard to maintain and extend. While this
> may be acceptable in some circumstances it certainly
> has negative implications in other. As a relavant
> comparison, have a look at the Web-client world and
> using JDBC directly from JSP code. This is generally
> strongly discouraged, and only recommended for
> prototyping and testing. Once again, the reasons are
> well known and should not have to be repeated.
Yes yes... I've been around that block. JSPs and Web Services will run the entire planet one day... I know.

>
> And it is not just a question of preferring JavaBeans
> to JDBC or OO over relational models. Building on the
> Web-client experience, I fear that binding JDBC
> directly to Swing components in JDNC will make it
> hard to add GUI-related services to the higher level
> JDNC components in a generic manner.
From my understanding it does/will support binding JavaBeans. I believe it does this now. At least the latest source appear to support it.

>
> I am thinking of
> authentication/authorization/Copy&Pase/Drag&Drop/sort/
> filter/CRUD-operations and all other stuff that we
> want BETWEEN the widgets and the persistance layer
> (or domain model/communication API).
Well... in a 2-tier environment, I don't have to authenticate every time the user clicks on something, so...

>
> There are huge benefits of having ONE consistant
> component model. For example, it will be hard to
> implement generic CRUD (Create, Read, Update, Delete)
> operations if the model is not standardised. If you
> choose JavaBeans as the one and only standard domain
> model in JDNC, it will be much easier to add such
> services. Providing specific binding to JDBC, WSDL
> and whatnot in the GUI will lead to a never ending
> story of hacks in the JDNC component architecture.

>
> Experience tells me that there has to be some sort of
> layering here to provide generic services in a
> framework and I don't see this layering in JDNC. On
> the contrary, the DataSet binding points in the
> direction of no layering at all.
>
> This is also why I miss support for the N in JDNC. If
> no generic networking support has been thought out at
> v0.7, how is that going to be added later? I am
> afraid it will be hard to add as an afterthought
> without major modifications to the architecture.
I believe the 'Network' capability is derived from the fact that your Data Provider could come from a SQL database, a web service, an XML file, etc.

Erik

ragnarw
Offline
Joined: 2003-10-26
Points: 0

> > This is also why I miss support for the N in JDNC.
> > If no generic networking support has been thought out
> > at v0.7, how is that going to be added later? I am
> > afraid it will be hard to add as an afterthought
> > without major modifications to the architecture.
> I believe the 'Network' capability is derived from
> the fact that your Data Provider could come from a
> SQL database, a web service, an XML file, etc.

Data does not just come from different sources, they also GO to different sources. This means it is not enough to READ data, you must CREATE, UPDATE and DELETE too (full CRUD).

At 0.7 I see no support for this in JDNC, though there may be some somewhere in the source for all I know. Please let me know if there is.

The DataSet example (Adventure Builder) lacks the C and U and D operations completeley (READ only from an XML file).

Moreover, as far as I can see, binding in that demo actually does not work. If you change data for a package it does not keep those edits between package selections but instead reverts to the old value.

Once again, when you get to the point wher you want to add full CRUD operations to different backend technologies (and support of JavaBeans binding in parallell with JDBC and other technologies), I'm afraid you will have serious problems with your current architecture.

/Ragnar

rbair
Offline
Joined: 2003-07-08
Points: 0

Hi Ragnar

> This is one BIG mistake and should be adressed as
> soon as possible.

As a general point related to this thread: it is naive to think that everybody develops in one way. Data (http://www.evansdata.com/survey_na_topical.shtml) suggests that the number of developers doing direct database access is enormous. Tapping into that market is imperative.

The fact that so much in the Java world right now is done by converting relational data into beans using JDO, Hibernate or some other method _for clients_ suggests not that such ORM software is superior in every circumstance (or, in my experience superior in many circumstances _for clients_), but that the alternative of working with Swing and relational data directly is prohibitively difficult. Indeed, ResultSet/RowSet don't lend themselves to efficient random access -- hence, the need to fetch data out of a ResultSet into some temporary structure (such as a bean!) for display in Swing components.

Richard

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey Ragnar,

Re-reading my last post, it sounded a little combative, which was not the intent. However, the main thrust of the post is correct -- there very many developers out there who don't use java because connecting to their database and binding data to the GUI is too difficult.

Richard

ragnarw
Offline
Joined: 2003-10-26
Points: 0

> Hey Ragnar,
>
> Re-reading my last post, it sounded a little
> combative, which was not the intent.

No problems!

> However, the
> main thrust of the post is correct -- there very many
> developers out there who don't use java because
> connecting to their database and binding data to the
> GUI is too difficult.

I do not disagree with that, and don't say it should'nt be supported. But there are implications here that may not be obvious at this point. Please see my response to Erik about my concerns on generic GUI services and layering.

>
> Richard

rbair
Offline
Joined: 2003-07-08
Points: 0

Hi Ragnar,

For interest sake, the binding machinery already works using a "DataModel" abstraction (as mentioned before). Really, to get JavaBeans working properly changes need to be made to the JavaBeanDataModel (in the databinding.dev.java.net project). If you feel like working on the solution... :)

Richard

ragnarw
Offline
Joined: 2003-10-26
Points: 0

> Hi Ragnar,
>
> For interest sake, the binding machinery already
> works using a "DataModel" abstraction (as mentioned
> before). Really, to get JavaBeans working properly
> changes need to be made to the JavaBeanDataModel (in
> the databinding.dev.java.net project).

Let's call that a good starting point!

> If you feel like working on the solution... :)

Yes and no. I would love to participate, but:

I use JGoodies binding + some homebrewn stuff in my own framework and it works fairly well. I see no need to reinvent when there are good frameworks avaliable. So I don't have specific knowledge about designing binding frameworks from the ground up.

Further, the whole idea is to choose ONE model and stick to it in the presentaion framework. Adapting to different backend technoligies (JDBC, EJB, Hibernate, whatever) happends behind the domain model API. Well known layering adapted from the last 10 years of Java server side + web gui frameworks.

I have very little confidence in binding to different models in parallell in the GUI framework, as I have argued for elsewhere.

But feel free to prove me wrong!

Cheers! :-)

/Ragnar

ragnarw
Offline
Joined: 2003-10-26
Points: 0

> I have to agree that I too am a bit disappointed that
> the DataSet API currently forces the programmer to
> funnel everything into table structures.

+1

It's quite astonishing that the main focus has been on something as odd as the DataSet/Rowset while the rest of the world has embraced JavaBeans as the component model. EJB, Spring, Struts, Hibernate, JDO or whatever. In fact, I think its safe to say that no Java framework will succeed in the enterprise arena without support for JavaBeans/POJO based domain models.

This is one BIG mistake and should be adressed as soon as possible.

Another related topic: what's with the N i JDNC? As far as I can see there are no truly network enabled components at version 0.7. Am I missing something?

On the positive side, there seems to be a lot of good stuff with new and improved Swing components like JXTable etc, but the aim is quite a bit higher than that isn't it?

/Ragnar

evickroy
Offline
Joined: 2004-07-23
Points: 0

> It's quite astonishing that the main focus has been
> on something as odd as the DataSet/Rowset while the
> rest of the world has embraced JavaBeans as the
> component model. EJB, Spring, Struts, Hibernate, JDO
> or whatever. In fact, I think its safe to say that no
> Java framework will succeed in the enterprise arena
> without support for JavaBeans/POJO based domain
> models.
For the last 10 years, every corporate application that I have developed requires accessing data from a relational database. Since Swing has never had a standard "binding" framework, we have always used something else. (VB, PowerBuilder, Oracle Forms, etc.) The industry has generated tons of new frameworks to support persistence and bridging the gap between objects and tabular data, but the biggest missing piece was binding. JDNC FINALLY gives Swing the standard binding layer that has been missing. From a certain viewpoint, the industry has wasted years recreating the same functionality that JDBC has always had. ;) I don't need yet-another-persistence-layer, I needed a binding framework 10 years ago.

>
> This is one BIG mistake and should be adressed as
> soon as possible.
I disagree completely.

>
> Another related topic: what's with the N i JDNC? As
> far as I can see there are no truly network enabled
> components at version 0.7. Am I missing something?
Don't forget the 'D' for Desktop. ;)

Just had to vent with all the DataSet bashing going on. ;)
Erik

Bill Snyder

On 5/25/05, jdnc-interest@javadesktop.org wrote:
> > It's quite astonishing that the main focus has been
> > on something as odd as the DataSet/Rowset while the
> > rest of the world has embraced JavaBeans as the
> > component model. EJB, Spring, Struts, Hibernate, JDO
> > or whatever. In fact, I think its safe to say that no
> > Java framework will succeed in the enterprise arena
> > without support for JavaBeans/POJO based domain
> > models.
> For the last 10 years, every corporate application that I have developed requires accessing data from a relational database. Since Swing has never had a standard "binding" framework, we have always used something else. (VB, PowerBuilder, Oracle Forms, etc.) The industry has generated tons of new frameworks to support persistence and bridging the gap between objects and tabular data, but the biggest missing piece was binding. JDNC FINALLY gives Swing the standard binding layer that has been missing. From a certain viewpoint, the industry has wasted years recreating the same functionality that JDBC has always had. ;) I don't need yet-another-persistence-layer, I needed a binding framework 10 years ago.

True, a lot of corporate apps use direct db access, but as Java gains
momentum on the desktop, I think we're seeing more apps built to
access enterprise services - more than likely serving up JavaBean
based results sets. I whole heartedly agree that more attention needs
to be paid to the JavaBeanDataModel/Binding APIs in order for JDNC to
be a successful took for corporate app development. I am not
questioning the decision to focus on the abular strucure first; I
just hope focus on the JavaBean model is not too far behind. (And it
sounds like it is not).

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

rbair
Offline
Joined: 2003-07-08
Points: 0

> On 5/25/05, jdnc-interest@javadesktop.org
> wrote:
> > > It's quite astonishing that the main focus has
> been
> > > on something as odd as the DataSet/Rowset while
> the
> > > rest of the world has embraced JavaBeans as the
> > > component model. EJB, Spring, Struts, Hibernate,
> JDO
> > > or whatever. In fact, I think its safe to say
> that no
> > > Java framework will succeed in the enterprise
> arena
> > > without support for JavaBeans/POJO based domain
> > > models.

> > For the last 10 years, every corporate application
> > that I have developed requires accessing data from a
> > relational database. Since Swing has never had a
> > standard "binding" framework, we have always used
> > something else. (VB, PowerBuilder, Oracle Forms,
> > etc.) The industry has generated tons of new
> > frameworks to support persistence and bridging the
> > gap between objects and tabular data, but the biggest
> > missing piece was binding. JDNC FINALLY gives Swing
> > the standard binding layer that has been missing.
> > From a certain viewpoint, the industry has wasted
> > d years recreating the same functionality that JDBC
> > has always had. ;) I don't need
> > yet-another-persistence-layer, I needed a binding
> > framework 10 years ago.
>
> True, a lot of corporate apps use direct db access,
> but as Java gains
> momentum on the desktop, I think we're seeing more
> apps built to
> access enterprise services - more than likely
> serving up JavaBean
> based results sets. I whole heartedly agree that more
> attention needs
> to be paid to the JavaBeanDataModel/Binding APIs in
> order for JDNC to
> be a successful took for corporate app development. I
> am not
> questioning the decision to focus on the abular
> strucure first; I
> just hope focus on the JavaBean model is not too far
> behind. (And it
> sounds like it is not).

That is correct, the java bean story has been thought out quite a bit as well, and the implementation will be done by the 1.0 release.

Richard

FriendVU

jdnc-interest@javadesktop.org wrote:

>
>> programs in Java
>>and yet does not want an object model is kind of an
>>oxi-moron to me
>>
>>
>
>
>
>
>
Ouch! Coming back at ya:

In Sttruts we learn Model should not know about DAO or O/R.
Struts Ex:
http://jakarta.apache.org/commons/beanutils/apidocs/org/apache/commons/b...

Or glaze lists in Swing, or you can read up at jGoodies List binding. It
would be too bad if the model layer in SwingX changes based on DAO (I
guess if .NET jumped of the bridge... what would we do?). Apprently that
is what .NET does, but I would not know :-) .
I do know Flash tools, they are collections based.

In anycase, I wrote a JDNC model/binding implementation for me that can
get a Map or a List of Values as a DTO, and if the DAO or SOA source
changes... my model (and vieew and controller ) do not :-P

No list for you!

Signed:
Oxi

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

hernansilberman
Offline
Joined: 2006-05-05
Points: 0

I have to agree that I too am a bit disappointed that the DataSet API currently forces the programmer to funnel everything into table structures. I've worked very hard over the past several months to build a Domain Object Model from my relational model. Putting my JavaBeans back into tables with keys and relations at the other end of my architecture is not an attractive option.

In my evaluation of JDNC .7 I was amazed by how well the DataSet API works, and how much I got for free once I had a proper DataSet modeled. The payoff is huge, and I definitely consider it to be a good thing. For the future, I would be in favor of a binding solution that didn't require me to break abstraction by forcing my java beans into table structures, it's way too tedius for those of us talking to RMI and Web services.

thanks...
Hernan

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey Hernan,

> I have to agree that I too am a bit disappointed that
> the DataSet API currently forces the programmer to
> funnel everything into table structures. I've worked
> very hard over the past several months to build a
> Domain Object Model from my relational model.
> Putting my JavaBeans back into tables with keys and
> d relations at the other end of my architecture is
> not an attractive option.

A lot of people have been tripped up by this. The DataSet documentation alludes to being able to use the DataSet over an object model, but this is definitely not the recommended practice for object domain models.

To clear up any confusion:

The DataSet API is designed first and foremost for relational data models. In particular, those that are closely related to a relational database, or other tabular data such as some XML documents or CSV files, DBASE, etc. are excellent candidates for modelling with a DataSet. Until now, we haven't had a good data structure in Java for dealing with relational data. ResultSet and by extension RowSet are, by design, meant to be used as a cursor-based data structure. Swing clients require a random access data structure. DataSet is primarily designed to fit this role.

The Binding framework abstracts the underlying data model from the bound components with a DataModel interface. The DataModelAdapter class in org.jdesktop.dataset.adapter is an implementation of DataModel for DataSets, however it isn't the only one. There is also a JavaBeanDataModel. The JavaBean binding story needs some work, it is true, but this will be finished prior to our 1.0 release.

Richard

Patrick Wright

Richard

>
> To clear up any confusion:
>

It seems that before 1.0 some piece of documentation needs to be
written to put this issue to rest. Like the 1.4/1.5 issue, it keeps
coming up. I'm not sure what needs to be changed. It may just be a
matter of how DataSet is referenced on the website(s) involved--it's
sort of prominent after the last release, which makes sense since it
was a big change in 0.7, and a significant amount of work--but somehow
the docs are confusing people who think that DataSet is JDNC's
solution to all data persistence problems.

Anyway, maybe this is something to think about--how to rephrase things
so that this is not a such a persistent question.

Regards
Patrick

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

aaime
Offline
Joined: 2003-06-10
Points: 0

First of all, sorry for my late answer, but I've been first ill, and then very busy trying to finish the work that accumulated in the meantime :-)

First, I'm happy to hear that JavaBeans are still under consideration, and from what I see, it seems to me that you're targeting the average VB developer... that's ok to me.
I concur with Vic, yet, someone that programs in Java and yet does not want an object model is kind of an oximoron to me ;-)
I also concur with Patrick that up and run quicky means dataset and not object models, it's just that around here the "bean counter" people are VB guys (mostly data edinting, very few business logic, if any), whilst the "complex problem" people usually do C# or Java.

Anyway, it seems that the DataModel API is what allows multiple data bindings to be carried out, each data model wrapping has just to conform to or adapt to the DataModel API to be binded. That's just fine to me.

I've searched a bit more, and found most of the things I put in my binder design also in JDNC (property adapters, component adapters, converters, validators). Yet I miss one thing: extensible factories.
In my design each factory is a lookup object that can be extended by the user, so that if I need a new kind of binding I can just add it to the factory.
For example, the component adapter factory comes out with a list of association from components to adapter. The list order tells what priority is used, each adapter is able to tell if it can map a certain component or not.

The factory has a generic method getComponentAdapter(Component component), this method scans the list in order trying to find an adapter that accepts to manage the component. If you need to add a new component, you just need to add it to the factory list once for all. The adapter will then have the responsibility of connecting the property to the component model.

Also the API usage is simplified, thought that can be done by adding some sugar to your existing API. In my design, to bind a component and add validation, the needed code is just:

Person person = new Person(...);
BeanBinder binder = new BeanBinder(person);
binder.bind(myTextBox, "name").addValidator(new RequiredValidator()).addValidator(new AlphabeticValidator());

and this binds the component, adds the validators, and also adds a validation status reporting component on the side of the binded component. Ease of use is important :-)

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Hi Andrea,

> First of all, sorry for my late answer, but I've been
> first ill, and then very busy trying to finish the
> work that accumulated in the meantime :-)
>

no problem :-)

> I concur with Vic, yet, someone that programs in Java
> and yet does not want an object model is kind of an
> oximoron to me ;-)

> I've searched a bit more, and found most of the
> things I put in my binder design also in JDNC
> (property adapters, component adapters, converters,
> validators). Yet I miss one thing: extensible
> factories.

They are difficult to find because yet mis-nomed (my fault): ComponentMap and BindingMap are the pluggable, extensible factories for creating Component and Binding instances, respectively. Component creation is based on the given MetaData, Binding creation is based on the given Component type and binds to a field in a DataModel. The implementation is ... ehhh ... raw... basically a quick extract from the DefaultFormFactory.

MetaData are in the center of interest when it comes to configuring components/bindings - your example re-formulated:

[code]
Person person = new Person();
DataModel personModel = new BeanDataModel(Person.class, listofPropertiesToBind);
MetaData nameMetaData = personModel.getMetaData("name");
nameMetaData.setRequired(true);
nameMetaData.addValidator(...);
BindingMap.getInstance().createBinding(myTextField, personModel, "name");
[/code]

This can be boring - but on the sunny side: the metaData properties can be declared whereever you want (in code, from xml, in the database itself, properties file...) which allows (will ) for very flexible auto-generation of forms.

In the above example, instead of binding manually to a component, you could leave it completely to a Form:

[code]

// configure the metaData
//....

form.bind(personModel);

[/code]

Jeanette

jlathiere
Offline
Joined: 2005-02-03
Points: 0

Hi Kleopatra,

I am also interested in binding a domain model but I can't find BeanDataModel or JavaBeanDataModel in the 0.7 jdnc release.

I once used org.jdesktop.jdnc.incubator.rbair.swing.data.JavaBeanDataModel,

What are now the best packages to try jdnc in relation with a POJO model ?

Thanks,

Junien.

Kleopatra

To throw in my own words (everything's already said during the night :-)

One lesson learnt in the last months was that there is no common "Data"
API for both the relational and object graph world (ducking... but we
did try really hard to find such a beast and failed). Accepting that
lesson led to splitting the "data-as-describing-the-world" from
"data-as-needed-for-ui-binding" - corresponding to the DataSet API for
relational data and the Binding API (which currently "speaks"
Tabular-/DataModel), respectively.

The advantage of this decoupling is that the Binding can evolve
independently, without caring about the chosen data abstraction - there
are/will be apropriate adapters (which is part of the price to pay -
besides duplicating certain aspects like selection/event
propagation/data structures).

We dearly need that independence to learn what we really need - can't
tell front-up, IMO. And we need at least one working "Data" API to play
on-top of - the decision to go for the relational model first was based
on perceived majority of developers needing it - so: pleading guilty of
temporarily neglecting the bean/object graph community :-)

Jeanette

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

Patrick Wright

> We dearly need that independence to learn what we really need - can't
> tell front-up, IMO. And we need at least one working "Data" API to play
> on-top of - the decision to go for the relational model first was based
> on perceived majority of developers needing it - so: pleading guilty of
> temporarily neglecting the bean/object graph community :-)

But the JavaBeanDataModel is part of swing.data--and will be supported,
correct? Looks like there are also some JB experimental classes (master
detail, for one) in Richard's incubator, but not sure if he is maintaining
those.

Maybe it would be good to have a page in the docs mentioning the the JBDM
does support ... aspects of beans.

Patrick

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

Richard Bair

>But the JavaBeanDataModel is part of swing.data--and will be supported,
>correct? Looks like there are also some JB experimental classes (master
>detail, for one) in Richard's incubator, but not sure if he is maintaining
>those.

The extact DataModel API might evolve a bit, but something like the
JavaBeanDataModel will always be around. If somebody absolutely *needed*
something as complex as what was in the incubator (with the
MasterDetailHandler and all), it did work quite well for the java bean case,
and didn't make the up-front assertion that the data was all cached locally
the way that the DataSet does.

>Maybe it would be good to have a page in the docs mentioning the the JBDM
>does support ... aspects of beans.

That would be good.

Richard

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

Richard Bair

Hi Andrea,

Yes, that's all very definately the case. JDNC is divided up between really
4 parts: the Data part, the Binding part, the UI Components and an
Application Framework (still to come...). The Data part is currently aimed
squarely at relational data like data bases. You can fit objects into that
framework, but the only reason you'd want to is if you were migrating from
objects to relational data, or vice versa.

However, the Binding framework should (and must) very well bind to object
graphs or relational data (via the DataSet) naturally. In the incubator
there are a couple of earlier versions fo the "DataSet" (before it was even
named DataSet) which is more like what you are looking for.

Many months ago Patrick (I think it was) astutely noted that the differences
between objects and relational data is enough that there isn't a silver
bullet framework that handles both equally well. The needs of both when
viewed as clients of network services are different enough as to be
difficult to reconcile. In fact, an attempt to do so renders the entire
framework so complex and unnatural that users get lost. For example, to DB
programmers the ideas of relations, primary keys, key based master/detail,
tables/columns/rows etc are all familar and natural terms. Yet for
developers with little or no relational history it can be a little
overwhelming. Meanwhile, masking relational concepts behind Java objects
(ala ORM) can be so convoluted for the poor little database app as to be
unwieldy.

I think you'll find that with the Binding layer in JDNC (in its finished
form, its not quite there yet, but it is useable) you'll be able to easily
take a collection of beans and bind to it, or take a DataSet full of
relational data and bind to it, and both will work equally well. At least,
that's the intent. The DataSet is not intended to be the end-all -- but it
works really really well for relational and table-based data (xls, csv,
etc).

Regards,
Richard

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

Patrick Wright

This is just my POV on Andrea's question, speaking for myself only of course.

Yet another way to put this debate is that there are very different modes
of working with data, and eventually one would like to support all of them
in some convenient fashion. For "desktop" apps which have a GUI, this
means they eventually can all be "modelled" and "bound" to the UI easily,
even if, individually, one has different APIs for them.

To be more specific--the DataSet API is a great start at what we need for
working with relational databases with low conceptual overhead. With it I
was already able to point to a database and get a nice, disconnected,
navigable data structure in just a few lines of code--easier than using
JDBC directly, background-threaded by default, and with what we'll be able
to do with it in a few months we'll be able to work pretty easily with any
relational database out there.

On the other hand, we have: bean object graphs; objects-are-not-beans
object graphs (e.g. no accessors or mutators unless necessary, see Allen
Holub for lots on this); record-based systems (especially legacy system)
that (traditionally) depend heavily on cursor processing; XML dialects;
Map-as-database (Berkeley DB), and so on.

I think a great goal for, say (pie in the sky), six months from now is
that we have a really solid front-end framework, and well-defined process
for how to write adaptors to other libraries. Berkeley DB is pretty
well-known and highly regarded: we should support it. But so is EDI, so is
D/XBase and FoxPro. There's a lot of stuff out there in these formats, and
we need to support them.

And JavaBean object graphs has been on everybody's mind since I joined the
list last summer.

I think the JDNC team (and I'm not a voting member, so not referring to
myself) made a good decision here, Andrea: target the problem that, out of
the gate, will let people get apps up and running quickly, but leave lots
of room for expansion moving forward. Up and running *quickly*, in 2005,
still means SQL and XML, not object graphs (IMHO). I don't know that there
is a good "solution" for XML in the works, but generally, that's an
industry-wide problem.

There are some existing packages to bind to Beans/graphs; I don't know
their state, but someone can please chirp in--Kleopatra?

Again, I'm just speaking for myself, because, at the end of the day (it's
midnight over here), I like to hear myself speak :). Besides, it's cold in
Berlin, and I need hot air to warm the room.

Cheers
Patrick

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

NetSQL

I think DataSet if for people that like .NET designs. ( if I did, I'd
use C#)
I just use TableModelExt and make my model out of collections, regadless
of what the domain "structure" is. Obsiosly, the UI layer should not
care or even know about domain.

.V

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

dhall
Offline
Joined: 2006-02-17
Points: 0

Andrea

How do you feel about the proposals in this thread:

http://www.javadesktop.org/forums/thread.jspa?threadID=8872&tstart=15

If I had to put a name to the type of structure I described there, conceptually it is sort of like a 'meta-DTO'. I think we need something between the GUI components and the direct representation of the back end data that generalizes the data structure.

Dave Hall
http://jga.sf.net/
http://jroller.com/page/dhall/