Some experiments ...
... to tackle a couple of issues that popped up in the past and raised my interest.
Yeah, it's a pain to have a zip on my site instead of pulling from cvs at javadesktop - but somebody at Sun needs to be punched for that nuisance ... I'm always quick to point fingers :) And beware! Everything is very raw, unordered and unstripped - best to start with the examples (in de.kleopatra.jdnc) and then crawl from there - don't forget to read the comments, they sometimes warn about the deeper pits To compile, you'll need a fairly current version of JGoodies Binding and make BindingBorder public. To run correctly in all aspects, issues 78 and 86 need to be fixed.
Personnally, I like the abstraction as is: It's main responsibility is "record level" - providing generic access to named parts of that record and notify about any changes in them. It has a notion of being contained somewhere which is weak - I see this weakness as a strength because the "container" can be anything. To illustrate my view of it:
As DataModel is nicely bounded, simple and complete - as far as the record-targeted functionality goes - the part labeled as "Controlling Model" in the diagram should not be moved into the DataModel, doing so will blur the boundaries of DataModel's responsibilities considerably.
So I tried to exercise the DataModel with the lessons learnt from Goodies Binding: If you have a XXModel to generically access arbitrary objects by name then think, eat and breathe that XXModel - in code that's equivalent to nest and chain XXModels.
One output is a changed implementation of TabularDataModelAdapter (see XTabularDataModelAdapter) which delegates to a DataModel to handle the value/notification specifics and concentrates on being the middle woman between the adaptee and that background working horse. Now adapting different data sources is simplified because it mostly only needs to provide the adaptee specifics - examples are XAdapter.
Another output is the ControllingDataModel (yeah, it shows again, I'm not too good with names...). The primary point is that it exposes the data source, the adapter and the selection as _values_ (and of course is responsible for keeping them reasonably in synch). Now clients can access them generically. Yes, some like TableBinding/ListBinding have to know what to expect - but that's general enough (we gave up type safety anyway). The examples of using them are ControllingXXOverview - they will create a nested form with the overview on the main and the details on a subform.
Just to be clear: I don't say that there is no need for a "unified notifying collection model with generic cell access" (though I'm not overly optimistic about the outcome - Einstein was kind of unhappy ever since he started hunting for the "unified field-theory" :-) - I only would like to explore the current possibilities in depth before moving on.
The thing I tried was to use it interchangeably in the context of jdnc. DataModel and ValueModel are similar enough to do so - the similarity being the generic access. DataModel and BeanAdapter/PresentationModel are similar in that they handle a collection of "properties". The distinction comes at the precise moment when actually transfering data from a XXModel to/from a component, the former being a strict push/pull while the latter is direct synchronization by default.
It's straightforward to support the jdnc way with goodies binding (the ValueModelBinding internally uses a BufferedValueModel to mimic it). The advantage of using them in that way is that the framework comes with many (and thoroughly tested) adapters which support most of the swing widgets (examples and serving classes either start with a "G" or contain "Value" in the name)
And open question is how are the plans to support direct synchronization (f.i. field level) in jdnc? Technically I could call a binding.push() any time - but currently there's nothing that triggers it automatically. Can imagine something equivalent to AUTO_VALIDATE, f.i.
As a side-effect I refactored the component/binding creation a bit - just one way of making it easier to plug-in custom components/bindings.
Comments, opinions, critics? I'll take the blame :-)