Skip to main content

Databinding newbie entry-point ?

42 replies [Last post]
cmarchand
Offline
Joined: 2006-01-02

Happy new year everybody ,

I am a newbie to DataBinding, an I'm looking for a documentation/examples entry point. Could someone help ?

Thanks in advance,

Tophe

Reply viewing options

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

Hi Nicola,

>>Ya, I'm rather anti java.util.List at the moment.
>>During most of the development, java.util.List and
>>DataSet were my primary use cases. However,
>>java.util.List is lacking in many ways. First, it has
>>no event mechanism to alert the binding that items
>>have been added or removed. Second, there is no way
>>to know what contents are in the List (other than
>>annotations, which is still not the most friendly way
>>to do it).

We most definitely need an observable List and Map. It's something I'm
going to try and get done for 1.7.

> Yes, some kind of wrapper to make the list observable.
> Just for information, Apple solved the problem at the root in they
> binding framework (Cocoa Binding) by enhancing the root object to be
> observable, so every object inherits this feature.

Cocoa bindings are indeed very impressive!
In general they lack some of the type safety Java typically has. It
would be a hard sell, if not impossible, to enhance java.lang.Object as
Apple has done with their equivalent root object.

None-the-less there are many aspects of Apple's binding framework (key
value observing/coding) that apply to us. In particular I really like
being able to do:

target.bind("text", source, "sourcePath");

I think we'll want a bit more than this, but something close would be ideal!

-Scott

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

nicfagn
Offline
Joined: 2003-06-14

Hi Scott,

> We most definitely need an observable List and Map.
> It's something I'm
> going to try and get done for 1.7.
>

This would be a good step forward. Unfortunately Dolphin is certainly not around the corner...

> Cocoa bindings are indeed very impressive!
> In general they lack some of the type safety Java
> typically has. It
> would be a hard sell, if not impossible, to enhance
> java.lang.Object as
> Apple has done with their equivalent root object.
>

In fact I forgot to mention that what they did was possible thanks to the dynamic nature of Objective-C, in the line of Smalltalk.
Obviously all that comes to the expense of type safety, as you said. For such reason and others their approach is not practicable in Java, but is nonetheless very interesting for its generality.
So I was really curious to see how the problem was solved in this project :-)

> None-the-less there are many aspects of Apple's
> binding framework (key
> value observing/coding) that apply to us. In
> particular I really like
> being able to do:
>
> target.bind("text", source, "sourcePath");
>
> I think we'll want a bit more than this, but
> something close would be ideal!
>

That would be great! Any idea of the timeframe to see something like that implemented?

Thanks

Nicola

Scott Violet

jdnc-interest@javadesktop.org wrote:
> Hi Scott,
>
>
>>We most definitely need an observable List and Map.
>>It's something I'm
>>going to try and get done for 1.7.
>>
>
>
> This would be a good step forward. Unfortunately Dolphin is certainly not around the corner...
>
>
>>Cocoa bindings are indeed very impressive!
>>In general they lack some of the type safety Java
>>typically has. It
>>would be a hard sell, if not impossible, to enhance
>>java.lang.Object as
>>Apple has done with their equivalent root object.
>>
>
>
> In fact I forgot to mention that what they did was possible thanks to the dynamic nature of Objective-C, in the line of Smalltalk.
> Obviously all that comes to the expense of type safety, as you said. For such reason and others their approach is not practicable in Java, but is nonetheless very interesting for its generality.
> So I was really curious to see how the problem was solved in this project :-)
>
>
>>None-the-less there are many aspects of Apple's
>>binding framework (key
>>value observing/coding) that apply to us. In
>>particular I really like
>>being able to do:
>>
>>target.bind("text", source, "sourcePath");
>>
>>I think we'll want a bit more than this, but
>>something close would be ideal!
>>
>
>
> That would be great! Any idea of the timeframe to see something like
> that implemented?

I've got an *extremely* rough implementation of parts of this. I'll see
if I can push at least something rush into a separate branch/incubator
in the next couple of weeks.

-Scott

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

sse
Offline
Joined: 2006-01-16

Hi richard,

Extract of previous conversation ------------------------

> I too find it hard to visualise a use for
> parent/child BindingContexts. Maybe if you had a
> complex set of visual beans all displaying together.

My use case was a form with multiple panels on it. Each panel would be it's own BindingContext. BindingContexts have a loadAll/saveAll method to cause all the bindings within that context to either load the UI components or save to the domain data. So, I could recurse down through the BindingContext hierarchy. So if I only wanted to save the customer data and not the order data, I could go:

customerPanel.saveAll();

If I wanted to save everything I could say:

window.saveAll();

----------------------------------------------------------

Regarding ability to edit and save on multiple datasets at once.
As a senior software designer (in the real world, as one would say) things should be kept as simple as possible.

As one says in conversations about design (things should be kept as simple as possible). It is true aswell for the framework capabilites.

And in this area, the most followed idea, is that one should only edit (commit / undo) one piece of data at once. End-users need and request for simple data management processes.

One simple example : when you work on Customer Orders, you first create one and fill the order header, and then you fill it with items. No one feel useful to be able to edit the header while editing one line, and this can be dangerous as far as business rules are concerned for order object.

As for unrelated tables, end-users do not feel editing several different datasets on the same window is useful and they feel it is confusing for them.

(as an example we did lock of window in our ERP, to be able to edit only one dataset related data at a time).

So keep on this way as far as binding context is concerned.

On the other hand, i am rather a new guy here, but more experienced in (real world) software design and things must be made easy for developers to design database oriented applications.

i am thinking about things like:
- if i fire an adding process to a given dataset, will all the binded widgets become enabled for input ?
- if i fire a save process, will all the binded widgets become disabled ?

More questions to come.

Keep on ;)

rbair
Offline
Joined: 2003-07-08

Hi

> i am thinking about things like:
> - if i fire an adding process to a given dataset,
> will all the binded widgets become enabled for input
> ?
>
> - if i fire a save process, will all the binded
> widgets become disabled ?

Data-aware components become enabled the moment that data is available for them to edit. For example, if I have a screen containing customer detail information (name, address, etc), then when the Customer data becomes available (via "ctx.addDomainData("customer", custObj);"), the components are enabled. When the data is removed from the BindingContext, then the components are disabled. If you want to enable/disable components according to business logic (like, disable on save), then that is completely up to you.

The databinding framework tries very hard to do its job and not much else. I could have built an entire app framework around this with all of the CRUD calls etc, but intentionally avoided that.

One reason for avoiding this problem is that different app developers like to approach their UI differently. Take, for example, the second question you posed:

> - if i fire a save process, will all the binded
> widgets become disabled ?

The reason why I don't do this: how would you like the framework to disable the controls? By calling "setEditable(false)"/"setEnabled(false)", or by throwing up a fancy glasspane (like Romain does)?

I can see a "Swing on Rails" framework being built on top of Databinding and either Hibernate or DataSet, but this databinding framework doesn't aspire to be anything other than a lowly binding framework :)

Richard

sse
Offline
Joined: 2006-01-16

Hi richard,

I don't think you miss the effective goal on your project.

What I think nonetheless, is that at the end in "real world" project, we need to be very reactive.

- A new business rule, a new screen to introduce between one and another, a new tab with new table/fields and rules for them : that is what happens to us every day or so.

So while I think the framework you are building is a good thing, we here in software design companies, need rapid and easy development tools, with a high level designed framework.

Things like CRUD management in framework provided must be handled (hopefully with options to choose the behaviour).

This may not be the goal of your present project, but must be the goal of an effective "java desktop software design framework", for it to be successfull on the market.

Finally, keep on, ;), i find nonetheless that open projects like this, with discussions, make project design much better.

NB : I don't know much projects that deal with high level CRUD functionnalities. If you know serious and workable one, don't hesitate to tell me.

Regards.

rbair
Offline
Joined: 2003-07-08

Hey Seguron

> So while I think the framework you are building is a
> good thing, we here in software design companies,
> need rapid and easy development tools, with a high
> level designed framework.
>
> Things like CRUD management in framework provided
> must be handled (hopefully with options to choose the
> behaviour).
>
> This may not be the goal of your present project, but
> must be the goal of an effective "java desktop
> software design framework", for it to be successfull
> on the market.

Yes, I hope we can do some more work on the RAD framework side in the future to make certain types of applications really easy to write. I guess right now we're still working on plugging holes in the lower level technologies, but we definitely need higher level frameworks for making CRUD like applications easier to write!

Cheers
Richard

rbair
Offline
Joined: 2003-07-08

Hey Nicola,

Brave soul, digging into all that code :). Thanks for taking the time!

> I also wanted to use a List as domain data but it
> worked only using annotations. I think annotations
> should be used carefully, since they introduce
> dependencies on the annotated classes (e.g. to
> annotate my domain model with a swingx annotation I
> have to make it dependent on swingx).

Ya, I'm rather anti java.util.List at the moment. During most of the development, java.util.List and DataSet were my primary use cases. However, java.util.List is lacking in many ways. First, it has no event mechanism to alert the binding that items have been added or removed. Second, there is no way to know what contents are in the List (other than annotations, which is still not the most friendly way to do it).

Really, no matter what binding solution is used in the end, a new BindingList implementation needs to be written (would be great to get some help from GlazedLists on that!) to handle event notification and to be able to describe what datatype the List contains.

In the meantime, I really like Array because it solves one of the two problems for us.

Of course, DataSet doesn't have any of these problems, and works with the binding framework reasonably well today.

> In conclusion I can say, that after some little :-)
> adjustement, it worked like a charm, at least for
> this specific example.

:). Feel free to push the boundaries.

> So keep up the good work.

Thanks
Richard

nicfagn
Offline
Joined: 2003-06-14

> Hey Nicola,
>
> Brave soul, digging into all that code :). Thanks for
> taking the time!
>

Just had the entire week available and was interested in implementation details and to see if this could be usable for my applications.
The way you committed things to CVS forced me to understand more than I wished :)
If I were you, after doing such a large commit, I would always checkout a fresh copy from CVS in an empty directory to see if at least compiles...

> > I also wanted to use a List as domain data but it
> > worked only using annotations. I think annotations
> > should be used carefully, since they introduce
> > dependencies on the annotated classes (e.g. to
> > annotate my domain model with a swingx annotation
> I
> > have to make it dependent on swingx).
>
> Ya, I'm rather anti java.util.List at the moment.
> During most of the development, java.util.List and
> DataSet were my primary use cases. However,
> java.util.List is lacking in many ways. First, it has
> no event mechanism to alert the binding that items
> have been added or removed. Second, there is no way
> to know what contents are in the List (other than
> annotations, which is still not the most friendly way
> to do it).
>

That was in fact one of the details I was interested in, how were managed lists.

> Really, no matter what binding solution is used in
> the end, a new BindingList implementation needs to be
> written (would be great to get some help from
> GlazedLists on that!) to handle event notification
> and to be able to describe what datatype the List
> contains.
>

Yes, some kind of wrapper to make the list observable.
Just for information, Apple solved the problem at the root in they binding framework (Cocoa Binding) by enhancing the root object to be observable, so every object inherits this feature.
Another solution that come to my mind is that adopted by Hibernate, a persistence framework. They use bytecode enhancing to intercept all the changes to the List that have to be persisted, or at least this is what I understood.

> In the meantime, I really like Array because it
> solves one of the two problems for us.
>

But Array are less flexible so I tend to use the collection framework, in particular with Java 5.0 code.
And If you give the prerequisite that the collection be homogeneous, you can guess the collection type from its first element if there is no annotation.
If the collection is empty you don't really don't care what it contains. And if the problem is to get the metadata for displaying the list (eg in a table), in most cases you have to explicitly specify what has to be shown, its display name, the preferred width,...

> Of course, DataSet doesn't have any of these
> problems, and works with the binding framework
> reasonably well today.
>

But Vic doesn't seem very happy with this approach...:-)
No really, there are situations where DataSet can just be the right solution, but in other cases they don't seem to fit so naturally.

> > In conclusion I can say, that after some little
> :-)
> > adjustement, it worked like a charm, at least for
> > this specific example.
>
> :). Feel free to push the boundaries.
>
> > So keep up the good work.
>
> Thanks
> Richard

I did some other experimentation and obviously have other questions and feedback to give.
For example:
- Found strange that for JXFrame are used two different BindingContexts. This could generate some confusion: which one has the priority?
- Why SelectionModels have to be named? They are implicitly identified by the BindingContext and DataPath in which they are created so why impose to the developer the burden of choosing a unique name for them? It could be a conventional one.
- There is a problem in SelectionModel update on JXTableBinding, because are used view indices instead of model indices causing incorrect behavior when filters or sorters are applied.

Should I open a thread for each one?

Besides, I could translate to italian if you don't have anyone yet. I can assure you that I'm much better understanding english and translating to italian than my written english could make think.

Bye

Nicola

rbair
Offline
Joined: 2003-07-08

Hey Nicola

> Another solution that come to my mind is that adopted
> by Hibernate, a persistence framework. They use
> bytecode enhancing to intercept all the changes to
> the List that have to be persisted, or at least this
> is what I understood.

Yes, I suppose byte code enhancements could be done. Sounds rather... hacky though. I'd prefer API if I could get it.

> > In the meantime, I really like Array because it
> > solves one of the two problems for us.
> >
>
> But Array are less flexible so I tend to use the
> collection framework, in particular with Java 5.0
> code.

Oh, I agree. If I had to do this though, I'd do it like so:

[code]
ctx.addDomainData("person", list.toArray(new Person[list.size()]));
[/code]

> And If you give the prerequisite that the collection
> be homogeneous, you can guess the collection type
> from its first element if there is no annotation.
> If the collection is empty you don't really don't
> care what it contains. And if the problem is to get
> the metadata for displaying the list (eg in a table),
> in most cases you have to explicitly specify what has
> to be shown, its display name, the preferred
> width,...

Ya. If you look into DetailDataModel, there are stubs for implementing that exact logic. I just feel uneasy about it. It doesn't feel right. I liked the idea of annotating the List, but that is kind of hacky too (since you have to annotate a class, not an instance).

I think some BindingList is still the best approach because it can wrap any arbitrary List, and provide both the type and event notification.

> > Of course, DataSet doesn't have any of these
> > problems, and works with the binding framework
> > reasonably well today.
> >
>
> But Vic doesn't seem very happy with this
> approach...:-)
> No really, there are situations where DataSet can
> just be the right solution, but in other cases they
> don't seem to fit so naturally.

Definitely. In fact, I have 3 basic types I want to support out of the box: DataSet (database), Object graphs, DOM trees. I think that constitutes the 80%+ of use cases.

> - Found strange that for JXFrame are used two
> different BindingContexts. This could generate some
> confusion: which one has the priority?

Its usually not a problem because of the way that hierarchical BindingContexts relate -- SwingX components wire up automatically to the first BindingContext they find (which would be the JXRootPane). If the domain data is available in the parent (the JXFrame), it will be available to the children (the JXRootPane).

But I agree, it is both confusing and, as per my other message, overkill.

> - Why SelectionModels have to be named? They are
> implicitly identified by the BindingContext and
> DataPath in which they are created so why impose to
> the developer the burden of choosing a unique name
> for them? It could be a conventional one.

Can you start a new thread for this question? This one is getting unwieldy.

> - There is a problem in SelectionModel update on
> JXTableBinding, because are used view indices instead
> of model indices causing incorrect behavior when
> filters or sorters are applied.

Doh. Do you have a diff? :D

> Besides, I could translate to italian if you don't
> have anyone yet. I can assure you that I'm much
> better understanding english and translating to
> italian than my written english could make think.

That'd be great! Once I have reasonable documentation to be translated :)

Cheers
Richard

nicfagn
Offline
Joined: 2003-06-14

> > - Why SelectionModels have to be named? They are
> > implicitly identified by the BindingContext and
> > DataPath in which they are created so why impose
> to
> > the developer the burden of choosing a unique name
> > for them? It could be a conventional one.
>
> Can you start a new thread for this question? This
> one is getting unwieldy.
>

I'll do after I have the time to formulate it clearly.

> > - There is a problem in SelectionModel update on
> > JXTableBinding, because are used view indices
> instead
> > of model indices causing incorrect behavior when
> > filters or sorters are applied.
>
> Doh. Do you have a diff? :D
>

To make it work correctly I did as per the following patches:

In JTableBinding.java:

[code]
*** JTableBinding.java
--- JTableBinding.java
***************
*** 85,91 ****
selectionListener = new ListSelectionListener() {
public void valueChanged(ListSelectionEvent e) {
if (!e.getValueIsAdjusting()) {
! int[] indices = getSelectionIndices();
List rows = new ArrayList();
for (int i=0; i rows.add(getDataModel().getRow(indices[i]));
--- 85,91 ----
selectionListener = new ListSelectionListener() {
public void valueChanged(ListSelectionEvent e) {
if (!e.getValueIsAdjusting()) {
! int[] indices = ((JTable)getComponent()).getSelectedRows();
List rows = new ArrayList();
for (int i=0; i rows.add(getDataModel().getRow(indices[i]));
***************
*** 97,106 ****
table.getSelectionModel().addListSelectionListener(selectionListener);
}

- protected int[] getSelectionIndices() {
- return ((JTable)getComponent()).getSelectedRows();
- }
-
public void doRelease() {
JTable table = (JTable)super.getComponent();
if (oldModel != null) {
--- 97,102 ----

[/code]

And in JXTableBinding.java

[code]
*** JXTableBinding.java
--- JXTableBinding.java
***************
*** 9,14 ****
--- 9,20 ----
*/

package org.jdesktop.swingx.binding;
+ import java.util.ArrayList;
+ import java.util.List;
+ import javax.swing.JTable;
+ import javax.swing.event.ListSelectionEvent;
+ import javax.swing.event.ListSelectionListener;
+ import org.jdesktop.binding.DataModel;
import org.jdesktop.swingx.JXTable;
/**
* A binding implementation that binds a JTable to a DataModel.
***************
*** 26,32 ****
--- 32,49 ----
JXTable table = (JXTable)super.getComponent();
super.doInitialize();
}
+
+ protected int[] getSelectionIndices() {
+ JXTable table = (JXTable)super.getComponent();
+ int[] indices = table.getSelectedRows();
+ for( int i = 0; i < indices.length; i++ ) {
+ indices[ i ] = table.convertRowIndexToModel( indices[ i ] );
}
+ return indices;
+ }
+
+ }
[/code]

I did the diff with the original files in your downloadable zip file, didn't have time to see if CVS checkout is now working.

Bye

Nicola

rturnbull
Offline
Joined: 2005-08-27

[i]>Let me know how it goes.[/i]

Richard
Tried your demo program.
Ran into a few problems.

When trying to bind came to DataBoundUtils.findBindingContext
code is
if (component instanceof BindingContext) {
ctx = (BindingContext)component;

Component (JXTable) not instanceof BindingContext, but is instanceof DataAware
so changed to
if (component instanceof DataAware) {
ctx = ((DataAware)component).getBindingContext();

This got me a bit further, but then ran into problems getting Column class.
Part of stack on debug:
ObjectDataModelSupport.getType(String) line: 96
ObjectDataModel.getType(String) line: 97
JTableBinding$DataModelToTableModelAdapter.getColumnClass(int) line: 253
JXTable(JTable).getColumnClass(int) line: 1833

At ObjectDataModelSupport.getType(String) line: 96
had
return metaData.get(columnName).type;

The dreaded metadata rears its ugly head. :)

Any suggestions.
I'm not sure why its using ObjectDataModel. I would have thought ArrayDataModel

Looks pretty easy once its working.

Richard Bair

Ray, thanks for the feedback.

In reverse order:

>Any suggestions.
>I'm not sure why its using ObjectDataModel. I would have thought
>ArrayDataModel

I committed yesterday afternoon (before posting the message) a couple fixes
to databinding (on the binding branch, of course) for this. The problem (for
anybody interested) is that the DataModelFactory that automatically creates
the appropriate DataModel for a given object wasn't handling the Array case
properly. I assumed that the parent of Person[] would have been Object[],
but alas, it ain't. Its Object. So, I had to add some special case
"clazz.isArray()" code for the array case.

>When trying to bind came to DataBoundUtils.findBindingContext
>code is
> if (component instanceof BindingContext) {
> ctx = (BindingContext)component;
>
>Component (JXTable) not instanceof BindingContext, but is instanceof
>DataAware
>so changed to
> if (component instanceof DataAware) {
> ctx = ((DataAware)component).getBindingContext();

Can you please try it with the version of SwingX in
http://download.java.net/javadesktop/swinglabs/releases/dev/swingx/bindi...?
Something is wrong with CVS/NB such that some of the latest code isn't
committing. (Incidently, the problem is only with SwingX. So use the latest
Databinding from the "binding" branch, but SwingX from the above link).

BTW, to provide a little background to the above error. What it's trying to
do is look up the component hierarchy and see if there is a component that
is a binding context. If it finds one, it'll use it. This "saves" you from
having to specify the BindingContext manually all the time (whereas in the
example, I explicitly specified the BindingContext to avoid confusion). I
say "saves" because I'm not altogether sure it is a good idea to be doing
this behind the scenes :)

Richard

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

nicfagn
Offline
Joined: 2003-06-14

> Ray, thanks for the feedback.
>
> In reverse order:
>
> >Any suggestions.
> >I'm not sure why its using ObjectDataModel. I would
> have thought
> >ArrayDataModel
>
> I committed yesterday afternoon (before posting the
> message) a couple fixes
> to databinding (on the binding branch, of course) for
> this. The problem (for
> anybody interested) is that the DataModelFactory that
> automatically creates
> the appropriate DataModel for a given object wasn't
> handling the Array case
> properly. I assumed that the parent of Person[] would
> have been Object[],
> but alas, it ain't. Its Object. So, I had to add some
> special case
> "clazz.isArray()" code for the array case.
>
> >When trying to bind came to
> DataBoundUtils.findBindingContext
> >code is
> > if (component instanceof BindingContext)
> {
> > ctx = (BindingContext)component;
> >
> >Component (JXTable) not instanceof BindingContext,
> but is instanceof
> >DataAware
> >so changed to
> > if (component instanceof DataAware) {
> > ctx =
> ((DataAware)component).getBindingContext();
>
> Can you please try it with the version of SwingX in
> http://download.java.net/javadesktop/swinglabs/release
> s/dev/swingx/binding/binding-update-5Jan2006.zip?

I tried with the sources downloaded from the above link but had the same problems as Ray.

> Something is wrong with CVS/NB such that some of
> of the latest code isn't
> committing. (Incidently, the problem is only with
> SwingX. So use the latest
> Databinding from the "binding" branch, but SwingX
> from the above link).
>
> BTW, to provide a little background to the above
> error. What it's trying to
> do is look up the component hierarchy and see if
> there is a component that
> is a binding context. If it finds one, it'll use it.
> This "saves" you from
> having to specify the BindingContext manually all the
> time (whereas in the
> example, I explicitly specified the BindingContext to
> avoid confusion). I
> say "saves" because I'm not altogether sure it is a
> good idea to be doing
> this behind the scenes :)

Since, in these sources, JXTable implements DataAware and not BindingContext, I made what Ray suggested.
The binding wasn't workink yet because the DataModelFactory returned a ObjectDataModel for the Array, as you mentioned above.
Then I modified DataModelFactoryImpl class as follows:
- Added this line in the constuctor

mappings.put(Object[].class, ArrayDataModel.class);

- after the line

Class modelClass = model.getClass();

in the method getDataModel() I inserted

if( modelClass.isArray() ) {
modelClass = Object[].class;
}

After rebuilding, I was able to see at last the table automatically filled with data, but the textfield was not updated selecting a row in the table as expected.
The problem is that the table is bound to the DataModel when one sets the data path on the table, and the SelectionModel is created during this process. There are three ways to solve this:
- move the line that sets the selection model name on the table before the line that sets the data path on the table:

table.setSelectionModelName("selected");
table.setDataPath("people");

- or, change the selection model name on textfield data path to 'tableSelection' (the default on a JXTable):

field.setDataPath("people[@tableSelection].firstName");

in this case there is no need to set the selection model name.
- or (the ideal solution) modify the method setSelectionModelName in JXTable class so that it recreates the binding and updates the selectionModel:

public void setSelectionModelName(String selectionName) {
selectionName = selectionName == null ? "" : selectionName;
if (!this.selectionModelName.equals(selectionName)) {
DataBoundUtils.unbind(this, ctx);
this.selectionModelName = selectionName;
if (DataBoundUtils.isValidPath(this.dataPath)) {
if( ctx != null ) {
ctx.bind(this, this.dataPath);
}
else {
ctx = DataBoundUtils.bind(this, this.dataPath);
}
}
}
}

This is what I did to make this example work, I hope could be useful for anyone interested.
I also wanted to use a List as domain data but it worked only using annotations. I think annotations should be used carefully, since they introduce dependencies on the annotated classes (e.g. to annotate my domain model with a swingx annotation I have to make it dependent on swingx).
In conclusion I can say, that after some little :-) adjustement, it worked like a charm, at least for this specific example.
So keep up the good work.

Bye

Nicola

rturnbull
Offline
Joined: 2005-08-27

Have now bound a DataTable to a JXTable and JTextFields, and works fairly well.
Very easy.

Trying to work out how to tailor it a bit came across displayHints in AbstractDataModel, but can't find how to set them.

Anyway while trying things I did the JXTable.setDataPath before doing JXTable.setBindingContext and program looped in DataBoundUtils.findBindingContext
because component.getBindingContext returns null.

Should we start a new thread for all this?

Message was edited by: rturnbull
Probably caused by my change :( - must investigate further

Message was edited by: rturnbull
Yes it was.
Need to change DataBoundUtils.findBindingContext to
BindingContext ctx = null;
while (ctx == null && component != null) {
// if (component instanceof BindingContext) {
// ctx = (BindingContext)component;
if (component instanceof DataAware) {
ctx = ((DataAware)component).getBindingContext();
[b]if (ctx == null) {
component = component.getParent();
}[/b]
} else {
component = component.getParent();
}
}
return ctx;
or similar.
Also need, as per prior post from Nicola, keep the
JXTable.setSelectionModelName ahead of
JXTable.setDataPath

rbair
Offline
Joined: 2003-07-08

> Trying to work out how to tailor it a bit came across
> displayHints in AbstractDataModel, but can't find how
> to set them.

Yes, let's start a new thread about this. In the API I think this is provided for fairly well, in the implementation I don't think I'm paying attention to any display hints yet.

As for the other problems: I'm still getting mixed messages from different people online and offline about where the compilation problems are.

As for setDataPath and setBindingContext --
there are two issues conspiring here that I don't really like. First, BindingContext is hierarchical. So you can have parent contexts and child contexts. In theory it sounds nice (almost like a "and we'll throw in hierarchical binding contexts absolutely free if you call within the next 7 minutes!"), but in practice I've not found it useful and it adds LOADS of complexity to the implementation.

Second, (and this is related to the first), there was a notion of Swing containers being BindingContexts. Because BindingContexts were hierarchical and Swing has a containment hierarchy -- it looked perfect. Well, I'm far less enthusiastic about it than I once was.

The one real benefit that comes from having a JXFrame/JXRootPane be a binding context is for convenience. Instead of having to specify two properties to effect a binding (BindingContext and DataPath), you only have to specify one (DataPath). The SwingX components will look up the containment hierarchy, looking for a BindingContext. If they find one, and the dataPath is set, then the binding is established. addNotify and removeNotify handle the case of the SwingX component being added or removed from the containment heirarchy -- binding and unbinding as necessary. All in all, kind of hairy for a little convenience.

This really deserves a different thread, and probably doesn't mean a lot to most folks right now. But for Ray and Nicola who are digging into the first layers of the code, I thought a little explanation might be nice about what you're seeing. And also a warning about digging into AbstractBindingContext -- I felt like I did a pretty good job in there overall, until I had to add the hierarchical feature to it. Then it got pretty hairy pretty fast. So have mercy on me :)

Cheers
Richard

rturnbull
Offline
Joined: 2005-08-27

Hi Richard

> Yes, let's start a new thread about this. In the API
> I think this is provided for fairly well, in the
> implementation I don't think I'm paying attention to
> any display hints yet.
>
I will start a new thread

Have to be a bit careful here.
This is an impressive set of packages - I understand now why we had to wait :) Worth it though.

However some of my comments may be wrong due to a lack of understanding, or failure to notice the obvious, so feel free to correct me.

> As for the other problems: I'm still getting mixed
> messages from different people online and offline
> about where the compilation problems are.
>
Not having any compilation problems except for WSDataConnection trying to import org.apache.xmlrpc.XmlRpcClient

> As for setDataPath and setBindingContext --
> there are two issues conspiring here that I don't
> really like. First, BindingContext is hierarchical.
> So you can have parent contexts and child contexts.
> In theory it sounds nice (almost like a "and we'll
> throw in hierarchical binding contexts absolutely
> free if you call within the next 7 minutes!"), but in
> practice I've not found it useful and it adds LOADS
> of complexity to the implementation.
>
> Second, (and this is related to the first), there was
> a notion of Swing containers being BindingContexts.
> Because BindingContexts were hierarchical and Swing
> has a containment hierarchy -- it looked perfect.
> Well, I'm far less enthusiastic about it than I once
> was.
>

You invented it. If you don't like it, get in quick and change it. ;)

I too find it hard to visualise a use for parent/child BindingContexts. Maybe if you had a complex set of visual beans all displaying together.

Anyway I'm a great believer in keeping things as simple as possible.
If we want to link BindingContexts, perhaps it should be done outside.

> The one real benefit that comes from having a
> JXFrame/JXRootPane be a binding context is for
> convenience. Instead of having to specify two
> properties to effect a binding (BindingContext and
> DataPath), you only have to specify one (DataPath).
> The SwingX components will look up the containment
> hierarchy, looking for a BindingContext. If they find
> one, and the dataPath is set, then the binding is
> established. addNotify and removeNotify handle the
> case of the SwingX component being added or removed
> from the containment heirarchy -- binding and
> unbinding as necessary. All in all, kind of hairy for
> a little convenience.
>

I find nothing wrong in having to specify the BindingContext for a component. I think the code

BindingContext ctx = new BindingContextSupport(this);
table.setBindingContext(ctx);
table.setSelectionModelName("selected");
table.setDataPath("property");

looks OK.
In fact I don't even see the need for the 'this' in the new BindingContextSupport.
If each SwingX component has its BindingContext attached, adding and removing would be easier.
Making things much more complex to save 1 line of code is overkill IMO.

Anyway we could always add
table.setBinding(BindingContext ctx, String dataPath)
if we really want to

I later found ctx.bind(table, dataPath) which seems to work, although it has a minor problem in that it does not actually set the path in the component.
(This caused a problem in some of my own code)
But it seems to bind OK.

Also, and I haven't delved into this yet, how easy is it going to be to bind my own components.

Consider this very positive feedback :D

(I've used all the faces I know except :( in this post)

Message was edited by: rturnbull

rbair
Offline
Joined: 2003-07-08

> Have to be a bit careful here.

Don't worry, you can beat me up about it all you want. Got plenty of bruises already :)

> This is an impressive set of packages - I understand
> now why we had to wait :) Worth it though.

Thanks

> You invented it. If you don't like it, get in quick
> and change it. ;)

I was thinking of tagging the branch as "hierarchical-binding-context" and then removing the hierarchical part. Should would make the code clearer

> I too find it hard to visualise a use for
> parent/child BindingContexts. Maybe if you had a
> complex set of visual beans all displaying together.

My use case was a form with multiple panels on it. Each panel would be it's own BindingContext. BindingContexts have a loadAll/saveAll method to cause all the bindings within that context to either load the UI components or save to the domain data. So, I could recurse down through the BindingContext hierarchy. So if I only wanted to save the customer data and not the order data, I could go:

customerPanel.saveAll();

If I wanted to save everything I could say:

window.saveAll();

> Anyway I'm a great believer in keeping things as
> simple as possible.
> If we want to link BindingContexts, perhaps it should
> be done outside.

I agree.

> In fact I don't even see the need for the 'this' in
> the new BindingContextSupport.

And in fact, it is only there because BindingContextSupport is actually an internal support class for SwingX Frames,Dialogs,RootPanes (and at one point) JXPanels. The "this" allows the BindingContextSupport to build the heirarchy based on the Swing component heirarchy.

All nasty if you ask me :)

> If each SwingX component has its BindingContext
> attached, adding and removing would be easier.
> Making things much more complex to save 1 line of
> code is overkill IMO.

+1

> I later found ctx.bind(table, dataPath) which seems
> to work, although it has a minor problem in that it
> does not actually set the path in the component.
> (This caused a problem in some of my own code)
> But it seems to bind OK.

Yes, what you are seeing is the layers involved in the API.

At the root level, there are DataModels and Bindings. You could create these manually like so:

[code]
Person[] people = createPeople();
DataModel dm = new ArrayDataModel(people);
JTextField tf = new JTextField();
JTextComponentBinding binding = new JTextComponentBinding(tf);
binding.setColumnName("firstName");
binding.setDataModel(dm);
[/code]

And that single text field is now bound. I could similarly configure master/detail or overview/detail relationships and such, albeit a bit more lenghty.

[code]
Person[] people = createPeople();
DataModel dm = new ArrayDataModel(people);

JList list = new JList();
JListBinding listBinding = new JListBinding(list);
listBinding.setDataModel(dm);
SelectionModel sm = listBinding.getListSelectionModel();

//configure for overview/detail
DataModel detailDM = new DetailDataModel(sm, null);

JTextField tf = new JTextField();
JTextComponentBinding binding = new JTextComponentBinding(tf);
binding.setColumnName("firstName);
binding.setDataModel(detailDM);
[/code]

On top of this very basic binding layer is the BindingContext. It aggregates multiple bindings together, and handles all the master detail logic. It also aggregates saveAll, loadAll, and validation events, as well as whether any of the bindings within the BindingContext have been edited (that is, whether any of the Bindings registered a change in their UI components, requiring a saveAll operation).

So (as you by now know) the above overview/detail code can be reduced to:

[code]
Person[] people = createPeople();
BindingContext ctx = new BindingContextSupport(this);
ctx.addDomainData("people", people);
JList list = new JList();
ctx.bind(list, "people");
JTextField tf = new JTextField();
ctx.bind(tf, "people[@listSelection].firstName");
[/code]

Here again, I'm using raw Swing components. If you write and register a Binding impl for a 3rd party or custom component with the BindingFactoryImpl (ya, there's a hole in the API right now -- the BindingFactory should have a method for registering a new impl), then you can use custom components in the Binding framework as well.

On top of BindingContext dwells the data-aware components. These guys (JX*) do two important things. First, any configuration options for the Binding impls can be defined in the data aware components via normal bean properties. This means you can configure these components in any visual builder. Second, they hide the "ctx.bind" and "ctx.unbind" calls. Again, this makes them work well within gui builders.

So, your code becomes:
[code]
Person[] people = createPeople();
BindingContext ctx = new BindingContextSupport(this);
ctx.addDomainData("people", people);

JXList list = new JXList();
list.setBindingContext(ctx);
list.setDataPath("people");
JXTextField tf = new JXTextField();
tf.setBindingContext(ctx);
tf.setDataPath("people[@listSelection].firstName");
[/code]

Which incidently is longer. 2 lines of code longer (since BindingContext is specified explicitly). However, they are all normal JavaBean method calls following normal JavaBeans patterns -- meaning that any java GUI builder can wire these properties up. That's important.

> Also, and I haven't delved into this yet, how easy is
> it going to be to bind my own components.

Let's use JXDatePicker as an example. First, you have to create a Binding implementation. There are basically 2 kinds of Bindings: those that operate over a collection of items (table, list, tree), and those that bind the GUI component to a single column in the DataModel. JXDatePicker is one of these latter types. You'll notice that the JXDatePickerBinding extends SwingColumnBinding, indicating that it is binding to a single Column value.

Column bindings support several things that model bindings (like those used by tree, table, and list) don't. First, column bindings support validation. Second, they support type conversion (if it is an "int" in the domain data and needs to be a String, then it will attempt to convert the value). Third, column bindings allow you to specify a strategy for coercing multiple values down to a single displayed value.

For example, if I'm handling multiple selection in a JList, then when multiple customers are selected, perhaps I want to show their average credit rating in a JXLabel. I should be able to set the strategy on the column binding to be "avg". It will then attempt to convert the data (if necessary) to a Number and then perform the calculation over the range of selected customers.

Similarly, I could have a "concatenate", "union", "difference" and other strategies. I say "could have", because I haven't actually written them yet. Just provided for them in the API. See the ColumnBindings doSave and doLoad methods for the //TODO references :)

Anyway, back to the JXDatePicker. Here is the Binding impl.

[code]
public class JXDatePickerBinding extends SwingColumnBinding {
private Date oldValue;

public JXDatePickerBinding(JXDatePicker datePicker) {
super(datePicker, Date.class);
}

public JXDatePickerBinding(JXDatePicker datePicker, String fieldName) {
super(datePicker, fieldName, Date.class);
}

protected void doInitialize() {
oldValue = getComponent().getDate();
}

public void doRelease() {
getComponent().setDate(oldValue);
}

protected void setComponentValue(Object value) {
getComponent().setDate(value == null ? new Date() : (Date)value);
}

protected Date getComponentValue() {
return getComponent().getDate();
}

public JXDatePicker getComponent() {
return (JXDatePicker)super.getComponent();
}
}
[/code]

I'm using a covariant return type for getComponent() -- basically just doing the cast for me from Object to JXDatePicker everywhere. The API is pretty self explanatory. Basically, doInitialize will do whatever it needs to do to the GUI component to initalize the binding. In the case of JTableBinding, this replaces the TableColumnModel and TableModel. doInitialize is also supposed to save off the old state and restore it, [i]if possible[/i] after the binding is broken. So if a JXDatePicker had a Date in it, say, my birthday 21 December (I'll let you guess the year :)), then that date should be saved off in doInitialize, and restored in doRelease.

Now, this would give you enough of an impl to wire this together by hand. If you want it to work with a BindingContext, then you must register the JXDatePickerBinding with the BindingFactoryImpl (again, BindingFactory should have API to do this. Just didn't have time to do it). Something like:

[code]
BindingFactoryImpl factory = (BindingFactoryImpl)BindingFactory.getInstance();
factory.addMapping(JXDatePicker.class, JXDatePickerBinding.class);
[/code]

I'm doing this in BindingContextSupport (IIRC). In 3rd party components I've written, I do it at the beginning of the component in a static block. For 3rd party components I'm going to use -- I'll leave it up to you to find somewhere to make this call.

Once that is done, I can use my 3rd party component via "ctx.bind(thirdPartyComp, "path");" calls. If you want the component to be data aware -- well its all busy work. Just read the code for JXDatePicker. This is probably the dirtiest corner of my code -- could be much better here.

> (I've used all the faces I know except :( in this
> post)

:)

Richard

rturnbull
Offline
Joined: 2005-08-27

>> Have to be a bit careful here.

> Don't worry, you can beat me up about it all you want. Got plenty of bruises already

Wasn't worried about you Richard :D
It's me who doesn't want to look stupid

rbair
Offline
Joined: 2003-07-08

Ray, Noel

> Downloaded the new binding but am having difficulty
> working out how it all hangs together.

The first bit of advice: forget about everything you've learned :). The old APIs required you to know about Binding and DataModel. The new APIs don't. More below...

> Is it in a state where it can be used (played with)?

Yes (assuming I've committed everything, which I believe I have)

> If so would it be possible to get a small demo
> program linking some data (preferably a DataTable) to
> a JXTable and JTextField.

Ya, I knew this was coming. I'll try to get a master/detail/subdetail example here shortly.

> How does the MetaData tie in. (If it does). I can't
> find any references to it outside the metadata
> package.

Doesn't, yet. There was a discussion internally about metadata -- some (quite senior) folks were against it. So we're seeing how far we get without it. Personally, I haven't needed it in this new API. As always, feedback is always appreciated.

> Do we have to extend class ColumnBinding to bind to
> JTextField etc. (Or is that still to come)
> BindingFactoryImp mappings is empty.
>
> What class binds to a JXTable?

To answer this (and Noels question): the binding implementations are in the SwingX project in its "binding" branch. Databinding used to depend on the SwingX project because the binding impls were in Databinding. On the "binding" branch, the opposite is now true (I haven't updated the project files, which may be causing some confusion).

The reasoning is this: in SwingX "binding" the components are data aware, so SwingX will have to have a reference to databinding. Databinding may be used on either the web or client tiers, so it shouldn't have a build dependency on Swing.

> A lot of questions, but we've been looking forward
> for this. Can't wait to start using it.

Well, here's a short tutorial to get you headed in the right direction. I hope to put together a full tutorial soon, but don't quote me on it :)

Lets start with a basic code sample:
[NOTE: get the latest from CVS. While the API is stable, the implementations are still not 100% complete. As a result, code paths I haven't tested may have bugs. I fixed one such bug this morning with regards to object Arrays].

[code]
public class MyFrame extends JFrame {
private JXTable table = new JXTable();
private JXTextField field = new JXTextField();

public MyFrame() {
initComponents();
initBindings();
}

private void initComponents() {
//construct the UI here -- nothing special need be done
}

private void initBindings() {
BindingContext ctx = new BindingContextSupport(this);
table.setBindingContext(ctx);
table.setDataPath("people");
table.setSelectionModelName("selected");
field.setBindingContext(ctx);
field.setDataPath("people[@selected].firstName");
ctx.addDomainData("people", createDomainData());
}

private Person[] createDomainData() {
Person[] p = new Person[5];
p[0] = new Person("Mary", "Campione",
"Snowboarding", 5, false);
p[1] = new Person("Alison", "Huml",
"Rowing", 3, true);
p[2] = new Person("Kathy", "Walrath",
"Knitting", 2, false);
p[3] = new Person("Sharon", "Zakhour",
"Speed reading", 20, true);
p[4] = new Person("Philip", "Milne",
"Pool", 10, false);
return p;
}

public static final class Person {
private String firstName;
private String lastName;
private String sport;
private int numYears;
private boolean vegetarian;
public Person(String fn, String ln, String s, int n, boolean v) {
this.firstName = fn;
this.lastName = ln;
this.sport = s;
this.numYears = n;
this.vegetarian = v;
}

public String getFirstName() {return firstName;}
public String getLastName() {return lastName;}
public String getSport() {return sport;}
public int getNumYears() {return numYears;}
public boolean isVegetarian() {return vegetarian;}
}
}
[/code]

I included the domain data as well so we have a common class to base our discussions on. As you can see from this code example, you don't have to do anything with DataModels or Bindings in order to bind your data. You'll also notice that I'm binding directly to beans. I've also set up a little overview/detail form, where whenever a row is selected in the table the firstName for the item at that row will be displayed in the text field.

The essential bit of this API is the BindingContext and the data aware components. [NOTE: before I get lynched, if you don't use or have a data aware component you can bind a component by calling the ctx.bind(component, dataPath) method].

The BindingContext manages a set of selection models, DataModels, and Bindings. Whenever a datapath indicates that it needs a certain selection model, the BindingContext finds it and does all the master/detail/subdetail magic behind the scenes.

The idea is that you only really want to define that a UI component binds to some data, and you name that data via a dataPath. Likewise, when data becomes available, you make it available for binding by adding it to the BindingContext.

To help simplify the code requirement, it is not required that you specify the BindingContext explicitly if your components are on a JXFrame. The JXFrame and JXRootPane are both BindingContexts. That isn't overly important at this point though.

Also notice that I specified the "selectionModelName" for the JXTable. This name must match the one used in the dataPath. This allows you to have multiple selection models in a BindingContext (including non-visual ones you add yourself!) and your dataPath indicates which one to use.

Since I know this is the next question: without MetaData, how can you change the column names, order, etc in the JXTable? The answer is: by defining a TableColumnModel *before* the binding takes place.

The JTableBinding uses the TableColumnModel to discover which columns should be shown, and any special properties related to those columns. If you want the columns autogenerated, then create an empty TableColumnModel on the JXTable. One additional note: If you specify the column model and later specify a TableModel, the TableColumnModel is blown away by JTable which then creates a new TableColumnModel based on the TableModel. Since you are using databinding, you shouldn't ever have to specify the TableModel, so this shouldn't be a problem.

For example:
[code]
private void initBindings() {
//...
TableColumnModelExt model = new DefaultTableColumnModelExt();

TableColumnExt col = new TableColumnExt(0);
col.setIdentifier("firstName");
col.setTitle("First Name");
model.addColumn(col);

col = new TableColumnExt(1);
col.setIdentifier("lastName");
col.setTitle("Last Name");
model.addColumn(col);

col = new TableColumnExt(2);
col.setIdentifier("sport");
col.setTitle("Favorite Sport");
model.addColumn(col);

col = new TableColumnExt(3);
col.setIdentifier("numYears");
col.setTitle("# of Years");
model.addColumn(col);

col = new TableColumnExt(4);
col.setIdentifier("vegetarian");
col.setTitle("Vegetarian");
model.addColumn(col);

table.setColumnModel(model);
table.setBindingContext(ctx);
table.setDataPath("people");
table.setSelectionModelName("selected");
//...
}
[/code]

Let me know how it goes.

Richard

rturnbull
Offline
Joined: 2005-08-27

Richard

[i]>To answer this (and Noels question): the binding implementations are in the SwingX project in its "binding" branch. Databinding used to depend on the SwingX project because the binding impls were in Databinding. On the "binding" branch, the opposite is now true (I haven't updated the project files, which may be causing some confusion).[/i]

Ah! No-one told me there were changes to swingx also :)
You've been busy.

Downloaded the rest and found errors. Some of the main causes listed here:

org.jdesktop.swingx.PatternModel in binding branch is version 1.3. Version 1.19 (latest) in main branch has constants and methods required by a number of classes.

A number of classes have the method:
public List getChildrenContexts() {
return ctxSupport.getChildrenContexts();
}
ctxSupport.getChildrenContexts() returns a BindingContext[]
method in BindingContextSupport incorrectly implements method from BindingContext interface

Can't find WindowUtils.findWindow(owner) in JXErrorDialog
In MAIN branch v1.9 but not in binding v1.3

Need later version of class LookAndFeelAddons (MAIN v1.15, binding v1.7)

I think we need latest version of org.jdesktop.swingx.action.ServerAction.
binding version uses Debug - doesn't compile.

Most of the classes in package org.jdesktop.swingx.binding extend FieldBinding.
I think this has been renamed ColumnBinding, but I also think these classes should extend SwingColumnBinding.
If I change to extends SwingColumnBinding and rename methods initialize/release to doInitialize/doRelease they compile OK.

method getTitleHeight in BasicTaskPaneUI has been made final. A number of PLAF classes attempt to override it.
IMO the overrides can be removed.

Thanks for the reply. Very detailed.
I think it covers everything I need for now.
I can also fix most of the errors in my checkedout version of the source.
(I sent a JCA just before New Year but it hasn't worked through the system yet so I can't send any fixes back)

Message was edited by: rturnbull
I seemed to reply to a message in the middle without reading right through the thread.
Sorry

scesbron
Offline
Joined: 2004-07-26

Maybe I have missed something but I picked the latest cruise control build here http://www.javadesktop.org/cruisecontrol/index.jsp

The date of these builds are 01/04 but in the javadoc I don't find the JXTextArea class nor the "setDataPath" method in the JXList class

Ok sorry, I am stupid, I juste realize that all this stuff is not on the HEAD but on the binding branch. I will checkout this branch. Do you know where all of this will be merged into the main branch ?

Richard Bair

>Ok sorry, I am stupid, I juste realize that all this stuff is not on the
>HEAD but on the binding branch. I will checkout this branch. Do you know
>where all of this will be merged into the main branch ?

No, I don't. It depends in large part on the feedback we get. I don't want
to railroad these changes through, but get proper feedback.

Richard

---------------------------------------------------------------------
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

Hey Tophe,

Unfortunately, there isn't a real easy way to get started right now. The best we have today is in the http://www.jroller.com/page/gfx/?anchor=desktop_java_presentation that Romain and I gave (actually, I think this is the link to the modified version Romain gave in Paris, but it is essentially the same).

As Scott mentioned, within the next month I'll have pushed the latest databinding code out. Along with that will come some examples and documentation.

Thanks for your patience.
Richard

cmarchand
Offline
Joined: 2006-01-02

Thanks richard, I'm going to wait until this anouncement.

The major problem I had was I cann't find the API used in this presentation.... I checked out from CVS, but no setDataPath(...) method anywhere ; does the presentation refers to your future post ?

Tophe

rbair
Offline
Joined: 2003-07-08

> The major problem I had was I cann't find the API
> used in this presentation.... I checked out from CVS,
> but no setDataPath(...) method anywhere ; does the
> presentation refers to your future post ?

Yes. I didn't see the point of talking about API that was about to be replaced. I'll be committing stuff back into the binding branch today.

Richard

scesbron
Offline
Joined: 2004-07-26

Ok but it seems that it lacks some stuff in the swingx branch too.
Do you have any idea on when this stuff will be committed.

Thanx

Seb

Richard Bair

>Ok but it seems that it lacks some stuff in the swingx branch too.
>Do you have any idea on when this stuff will be committed.

It should have all been commited last night...

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

rturnbull
Offline
Joined: 2005-08-27

> It should have all been commited last night...

I have downloaded the Binding branch from CVS and seem to be missing a couple of classes:

org.jdesktop.validation.ValidationListener
org.jdesktop.validation.ValidationEvent
org.jdesktop.conversion.StringConverter - there is one in org.jdesktop.conversion.Converters but it is not visible
org.apache.xmlrpc.XmlRpcClient (not too concerned about this)

Any suggestions

Richard Bair

> > It should have all been commited last night...
>
>I have downloaded the Binding branch from CVS and seem to be missing a
>couple of classes:
>
>org.jdesktop.validation.ValidationListener
>org.jdesktop.validation.ValidationEvent
>org.jdesktop.conversion.StringConverter - there is one in
>org.jdesktop.conversion.Converters but it is not visible
>org.apache.xmlrpc.XmlRpcClient (not too concerned about this)

Weird. Just recommitted those. Oh, sorry about the XmlRpc one, that one
snuck in there (associated with a Web service DataProvider. Pretty cool, but
not a dependency I want in the trunk)

Richard

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

Noel Grandin

OK, I can now build src/java if I exclude the provider.ws package.
src/test is completely broken, but I suppose that is because the unit
tests are out of date.

Will have a look and see how it works with my project.

Richard Bair wrote:

>> > It should have all been commited last night...
>>
>> I have downloaded the Binding branch from CVS and seem to be missing
>> a couple of classes:
>>
>> org.jdesktop.validation.ValidationListener
>> org.jdesktop.validation.ValidationEvent
>> org.jdesktop.conversion.StringConverter - there is one in
>> org.jdesktop.conversion.Converters but it is not visible
>> org.apache.xmlrpc.XmlRpcClient (not too concerned about this)
>
>
> Weird. Just recommitted those. Oh, sorry about the XmlRpc one, that
> one snuck in there (associated with a Web service DataProvider. Pretty
> cool, but not a dependency I want in the trunk)
>
> Richard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com

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

Noel Grandin

Hi

Am I missing something?

the binding branch does not contain any swing binding code e.g.
ComboBoxBinding, etc?

Regards,
Noel

NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html

If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com

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

rturnbull
Offline
Joined: 2005-08-27

Downloaded the new binding but am having difficulty working out how it all hangs together.

I have a few questions:

Is it in a state where it can be used (played with)?

If so would it be possible to get a small demo program linking some data (preferably a DataTable) to a JXTable and JTextField.

How does the MetaData tie in. (If it does). I can't find any references to it outside the metadata package.

Do we have to extend class ColumnBinding to bind to JTextField etc. (Or is that still to come)
BindingFactoryImp mappings is empty.

What class binds to a JXTable?

A lot of questions, but we've been looking forward for this. Can't wait to start using it.

scesbron
Offline
Joined: 2004-07-26

You can download joplin on java.net, I guess it features swingx+databinding

scesbron
Offline
Joined: 2004-07-26

Sorry, I don't think I am a complete newbie but I can't manage to compile the binding branch

The databinding ok is near ok and I managed to change it to compile but I have a lot of errors in the swingx project.

I am trying to use the new databinding+swingx for 2 days but I am not able to create two dist jars that I can use. Would it be possible to have some help or could someone give me some jars I can use

I tried to use the joplin ones but they have dependencies on joplin code (?) and they don't seems to work with an arraylist of javabean

If somebody can help me I would really appreciate

Thanx

Seb

Bill Snyder

Rich,

Am I missing something? The swingx binding branch seems to depend on
FieldBinding - which is not in the databinding binding branch. I can't do a
ctx.bind without it...

--Bill

On 1/6/06, jdnc-interest@javadesktop.org
wrote:
>
> Sorry, I don't think I am a complete newbie but I can't manage to compile
> the binding branch
>
> The databinding ok is near ok and I managed to change it to compile but I
> have a lot of errors in the swingx project.
>
> I am trying to use the new databinding+swingx for 2 days but I am not able
> to create two dist jars that I can use. Would it be possible to have some
> help or could someone give me some jars I can use
>
> I tried to use the joplin ones but they have dependencies on joplin code
> (?) and they don't seems to work with an arraylist of javabean
>
> If somebody can help me I would really appreciate
>
> Thanx
>
> Seb
> ---
> [Message sent by forum member 'scesbron' (Sebastien Cesbron)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=134643
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
[att1.html]

rbair
Offline
Joined: 2003-07-08

Hey Bill,

> Am I missing something? The swingx binding branch
> seems to depend on
> FieldBinding - which is not in the databinding
> binding branch. I can't do a
> ctx.bind without it...

I'm looking into this now. I've been getting clean builds on my end, and my IDE says that everything has been committed to the branch. However, I just did a clean checkout on a different machine and am getting [i]hundreds[/i] of errors, among which are the mysterious FieldBinding errors (FieldBinding was renamed ColumnBinding some time ago. So this indicates that the state of SwingX is quite different from what my IDE is telling me....grrrrr)

Richard

rbair
Offline
Joined: 2003-07-08

Incidently, I did a merge with the trunk prior to committing, which may also be the source of some problems. But again, I'm not getting any errors over here when I clean and build. Yet clearly, what is in CVS is borked.

Richard

Bill Snyder

borked? :)

On 1/6/06, jdnc-interest@javadesktop.org
wrote:
>
> Incidently, I did a merge with the trunk prior to committing, which may
> also be the source of some problems. But again, I'm not getting any errors
> over here when I clean and build. Yet clearly, what is in CVS is borked.
>
> Richard
> ---
> [Message sent by forum member 'rbair' (Richard Bair)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=134677
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
[att1.html]

rbair
Offline
Joined: 2003-07-08

Alright, I've posted the code that builds here: http://download.java.net/javadesktop/swinglabs/releases/dev/swingx/bindi...

If any of you CVS gurus out there can help me figure out why cvs commit doesn't commit the files that are obviously different from what is in the repository, I'll be much obliged.

Meanwhile, you guys can play around with binding.

Richard

Roger Keays

jdnc-interest@javadesktop.org wrote:
> Alright, I've posted the code that builds here: http://download.java.net/javadesktop/swinglabs/releases/dev/swingx/bindi...
>
> If any of you CVS gurus out there can help me figure out why cvs commit doesn't commit the files that are obviously different from what is in the repository, I'll be much obliged.

$ yum remove cvs
$ yum install subversion

;)

>
> Meanwhile, you guys can play around with binding.
>
> Richard
> ---
> [Message sent by forum member 'rbair' (Richard Bair)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=134691

--
----------------------------------------
Ninth Avenue Software
p: +61 7 3870 8494 (UTC +10)
f: +61 7 3870 8491
w: http://www.ninthavenue.com.au
e: info@ninthavenue.com.au
----------------------------------------

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

Richard Bair

>>If any of you CVS gurus out there can help me figure out why cvs commit
>>doesn't commit the files that are obviously different from what is in the
>>repository, I'll be much obliged.
>
>$ yum remove cvs
>$ yum install subversion
>
>;)

:D If only collabnet would let us... *sigh*

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