Skip to main content

Modeling Object Graphs

31 replies [Last post]
scottr
Offline
Joined: 2004-09-05

Hi all,

Having looked at the JDNC api, it occurs to me that it is mainly focussed on modeling simple, 1 dimensional DataModels.

Has anyone given any thought to supporting Object Graphs, where a field of a DataModel could itself be another DataModel? This would match to, for example, a JavaBean with other Javabeans (or collections of beans) as its properties.

Looking at the DataModel API, you could probably add two methods to achieve this:

<br />
/**<br />
 * @return the DataModel at named field, or null if field<br />
 *         holds a simple value<br />
 */<br />
public DataModel getDataModel(String fieldName);</p>
<p>/**<br />
 * Sets the DataModel to be held by named field<br />
 */<br />
public void setDataModel(String fieldName, DataModel value);<br />

Supporting the structure of the Object Graph at DataModel level, with appropriate MetaData to configure it, is a better option than relying on the application to ensure that disparate parent-child DataModels are kept in sync.

Another feature that would be useful is UI support for transaction demarcation. By that I mean that, a lot of client form programs I have seen will 'disable' entry into components outside of a transaction (ie. editing displayed data or creating a new data record, or even entering search criteria), and only enable field entry within a transaction. Likewise, certain operations (navigating through multiple records) are disabled during a transactional operation.

Regards,
Scott Russell

Reply viewing options

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

Hi Richard

>> Has anyone given any thought to supporting Object Graphs, where a field
>> of a DataModel could itself be another DataModel? This would match to,
>> for example, a JavaBean with other Javabeans (or collections of beans)
>> as its properties.

[snip]
> The loose coupled approach is by far the easiest to implement, but
> probably the hardest to use for modeling an object graph. But then, why
> does the DataModel need to model an object graph? If objects are used as
> the basis for your models, can't you just get the object from the
> DataModel (for instance, if JavaBeanDataModel had a 'getObject' method)
> and traverse the object's graph naturally?

This is what I do write now when I want to show my object on a JTable, and
it makes me hate JTables every time. I end up with a large case statement,
and I have to map, mentally, between the numbered columns, the named
column names, and the objects methods. It makes my hands ache before I
start typing. So, that is my motivation.

>
> Having given the topic extensive thought I can't see the benefits of
> having a DataModel support object graphs. Supporting an object graph would
> be simple if all DataModels were backed by objects. Unfortunately, this is
> not always the case. In fact, in the world of VB like controls I think
> this is never the case. Since VB, C++ builder and other RAD tools use SQL
> almost exclusively you are almost guaranteed that the backing model for
> DataModels of such easy-to-use tools are going to be ResultSet/RowSet.

We have all this metadata available through reflection, why not use it?
Doesn't have to be all-powerful. If the object is a bean, create a model
that has the names of the bean attributes to pull, "foo", "bar" and have
it figure out the basics.

The main issue for me is that in a number of cases, the loading
characteristics of objects are completely unpredictable in a way that
RDBMS queries are not, so for that reason, I would want to have control
over loading-paging behavior.

[snip]
>
> It has also been mentioned that by having DataModels model an object graph
> we could then use xpath like syntax to reach any variable in that graph.
> Besides the cool factor, why would this be a benefit? If you have the
> object graph available, why not use normal java code/syntax? If you don't
> have the graph available, then it becomes an absolute nightmare to try to
> provide this functionality over an asynchronous connection.

One reason to use XPath is that in Java, XPath paths can be represented as
Strings, which means they can be externalized, composed, copied, or
otherwise manipulated. That is incredibly powerful.

>
> The asynchronous nature of distributed computing is the biggest issue
> facing the use of object graphs of any kind in client applications. The
> client gui must remain responsive, and hence it *must* use asynchronous
> loading. If the bandwidth between the client and server is huge (as in,
> they reside on the same computer or on a local network), then the entire
> object graph can be transported from the server to the client via RMI,
> CORBA, java serialization, etc. However, if the bandwidth is small (DSL,
> dial-up, etc), sending the entire object graph is impossible. Thus,
> generalized distributed computing is at odds with object graphs!

You can't generalize SQL loading behavior, either. You need to look at
your queries, access patterns, size of query, ordering, estimated result
sets...

Look--someone sends me some XML with a list of employees and the new
business contacts they made this month. I want one table of employess, and
one of the contacts for the selected employee. This can be modelled as one
of the DOM flavors, but might also be in Employee and Contact objects.
Wouldn't it be nice to bind those up for display since I know they will be
in-memory?

I'm not saying anyone has to go out of their way to make this happen, just
that with normal Java there is a heck of a lot of typing between here and
there.

>
> Because an entire object graph cannot be guaranteed to be loaded into
> memory at any given time, synchronous access to variables is not
> guaranteed. If synchronous access cannot be guaranteed, then I cannot use
> the object graphs in renderers or event handlers! Pausing in an event
> handler or renderer would freeze the gui, and surely no renderer can do
> its business on a background thread!

Straw man! :)

Patrick

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

I think somewhere we lost meaning in what I meant to write and what you read. I think the term "modeling object graphs" might be the culprit :). Believe me, hand coding bindings between an object and a table is the LAST thing I ever want to code again! No sir, I want objects hidden within DataModels the same as RowSets or anything else! Indeed, I believe the DataModel *should* be the defacto interface that gui code works through.

>> Because an entire object graph cannot be guaranteed to be loaded into memory at any given time, synchronous access to variables is not guaranteed. If synchronous access cannot be guaranteed, then I cannot use the object graphs in renderers or event handlers! Pausing in an event handler or renderer would freeze the gui, and surely no renderer can do its business on a background thread!

>Straw man!

It might be... but not on purpose! Well, it was finely worded, you have to admit :). In my mind modeling the object graph *required* synchronicity, because method calls are synchronous (although they may perform work in a background thread, the call itself is synchronous). This mindset grew from an attempt to wrap RowSets in objects (which I assure you is a mine-field), which I am sorry to say appears to have colored my judgement!

In the end, as Scott mentioned in his last post, we're both saying the same thing with one exception: whether to have the DataModel know about its children, or to have a binding of some sort act as the intermediary between two DataModels. More on this in the next post.

Richard

Patrick Wright


> I think that you wouldn't just be able to wrap just any JavaBean in a any
> DataModel and have it work. The DataModel used would have to be
> pre-configured with meta-data that described the JavaBean structure
> expected, or discover that through reflection. Where you would run into
> problems witrh reflection would be with (non-generics) collection fields,
> where you would need to specify in meta-data an expected element type for
> those collections.

IMO--your point is well made, but there is some advantage in terms of
building interfaces quickly to asking that a JavaBean (or Collection of
them) be the source for a DataModel, and have reasonable defaults used in
pulling data from the JavaBeans. The API should allow metadata
specification, of course, but it would be nice to whip out a table, tree,
form bound to a JavaBean with just one or two API calls.

Among other cool things, if this was available, is that toolkits such as
Jaxen (http://jaxen.sourceforge.net) to use XPath on top of JavaBean
declarations, thus looking up some subset of our beans and passing them
into our models...a very quick way of filtering.

To summarize: using a JavaBean as a data source should be available,
defaulting to a basic reflected set of the bean properties as data
elements.

Patrick

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

scottr
Offline
Joined: 2004-09-05

>
> IMO--your point is well made, but there is some
> advantage in terms of
> building interfaces quickly to asking that a JavaBean
> (or Collection of
> them) be the source for a DataModel, and have
> reasonable defaults used in
> pulling data from the JavaBeans. The API should allow
> metadata
> specification, of course, but it would be nice to
> whip out a table, tree,
> form bound to a JavaBean with just one or two API
> calls.
>

I agree that a purely dynamic approach is useful also. In most cases, Introspection on BeanInfo can provide most information a DataModel would require (field names, etc). In the case of collection properties, you'd just have to rely on run-time determination of collection type, or rely on Java5 generics for type information.

> Among other cool things, if this was available, is
> that toolkits such as
> Jaxen (http://jaxen.sourceforge.net) to use XPath on
> top of JavaBean
> declarations, thus looking up some subset of our
> beans and passing them
> into our models...a very quick way of filtering.
>

There are a number of projects out there that provide Object Graph navigation syntax. JXPath (http://jakarta.apache.org/commons/jxpath/) provides XPath syntax for navigating javabeans, collections and maps. OGNL (http://www.ognl.org/) provides a similar but slightly more powerful navigation language. And of course you have JSP expression language which is similar and Jakarta Commons BeanInfo which is fairly basic.

I had considered that you could have a rich object graph attached at the root to a form, and rather than manually walking down to individual DataModels to bind components, you could declaratively specify each component binding as a path expression. This makes the wiring up of master-detail and master-detail-detail (and so on) views easier. Binding an object graph to a form becomes a simple matter of binding the form to the root of an appropriate DataSource. Each Binding then queries the DataSource using its path expression to pull or push its data as needed.

Scott

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> Hi all,
>
> Having looked at the JDNC api, it occurs to me that it is mainly focussed on modeling simple, 1 dimensional DataModels.
>
> Has anyone given any thought to supporting Object Graphs, where a field of a DataModel could itself be another DataModel? This would match to, for example, a JavaBean with other Javabeans (or collections of beans) as its properties.
>
> Looking at the DataModel API, you could probably add two methods to achieve this:
>
> [code]
> /**
> * @return the DataModel at named field, or null if field
> * holds a simple value
> */
> public DataModel getDataModel(String fieldName);
>
> /**
> * Sets the DataModel to be held by named field
> */
> public void setDataModel(String fieldName, DataModel value);
> [/code]

Actually, nested data models *are* supported by the current API,
although not as strongly typed as your API above. You should just
be able to add a DataModel object (with its associated MetaData
descriptor) as a field in the parent data model.

I suspect we haven't yet fully implemented this in the
JavaBeanDataModel wrapper, but we should make nested beans work
automagically.

Aim

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

scottr
Offline
Joined: 2004-09-05

>
> Actually, nested data models *are* supported by the
> current API,
> although not as strongly typed as your API above.
> You should just
> be able to add a DataModel object (with its
> associated MetaData
> descriptor) as a field in the parent data model.
>
> I suspect we haven't yet fully implemented this in
> the
> JavaBeanDataModel wrapper, but we should make nested
> beans work
> automagically.
>
> Aim
>

I think that the strong typing helps, especially if you want to support meta-data to describe the child DataModels eg. specific DataModel implementor to use.

Also, I think you'd want to retain the ability to query the DataModel for the normal field value (JavaBean or collection), and add the ability to retrieve the DataModel also as needed. This gives the developer the flexibility to retrieve DataModel or field value as needed.

regards,
Scott

rbair
Offline
Joined: 2003-07-08

> >
> > Actually, nested data models *are* supported by
> > the current API,
> > although not as strongly typed as your API above.
> > You should just
> > be able to add a DataModel object (with its
> > associated MetaData
> > descriptor) as a field in the parent data model.

How? If a bean is being wrapped by a DataModel and somebody calls "setDataModel" on it, how can you set that rows/objects "List list" field to a DataModel? I guess if we tried to extract the data from the model or something.

As for a RowSet based DataModel, you have the problem of MetaData telling you no-way when you try to set the field to be something of the wrong type.

> Also, I think you'd want to retain the ability to
> query the DataModel for the normal field value
> (JavaBean or collection), and add the ability to
> retrieve the DataModel also as needed. This gives the
> developer the flexibility to retrieve DataModel or
> field value as needed.

I can see some benefit to being able to do a 'getDataModel("orders")', or 'getObject("orders")', but again it seems the getDataModel would be acting in a convenience role only. I don't see how setDataModel is supposed to work in a generic situation unless it is orthogonal to the setting of field values.

Here's what I'm seeing are the issues you're trying to solve:

1) master/detail
2) master/detail bindings in xml
3) convenience in specifying the binding (xpath, jakarta bean utils path syntax a.b.c)
4) convenience in getting a data model to wrap a collection or some other object

Are there any I missed?

Message was edited by: rbair

scottr
Offline
Joined: 2004-09-05

> How? If a bean is being wrapped by a DataModel and
> somebody calls "setDataModel" on it, how can you set
> that rows/objects "List list" field to a DataModel? I
> guess if we tried to extract the data from the model
> or something.
>
> As for a RowSet based DataModel, you have the problem
> of MetaData telling you no-way when you try to set
> the field to be something of the wrong type.

> I can see some benefit to being able to do a
> 'getDataModel("orders")', or 'getObject("orders")',
> but again it seems the getDataModel would be acting
> in a convenience role only. I don't see how
> setDataModel is supposed to work in a generic
> situation unless it is orthogonal to the setting of
> field values.

I think you're right there. Originally I included a setDataModel method out of habit (pairing get/set methods for properties). But the getDataModel(String) method is more useful for navigating a DataModel graph matching to an underlying object graph.

> Here's what I'm seeing are the issues you're trying
> to solve:
>
> 1) master/detail
> 2) master/detail bindings in xml
> 3) convenience in specifying the binding (xpath,
> jakarta bean utils path syntax a.b.c)
> 4) convenience in getting a data model to wrap a
> collection or some other object
>
> Are there any I missed?

I think that sums it up well. On point 1, a detail model should itself be able to be a master for another detail model, to allow for chaining.

I guess the core aim is to make it easy to bind a complex object model to a form, and automate lower level plumbing like keeping details synchronised with their master, and pulling/pushing data between the components on the form and elements on the graph, at any depth.

Scott

rbair
Offline
Joined: 2003-07-08

> I think you're right there. Originally I included a
> setDataModel method out of habit (pairing get/set
> methods for properties). But the getDataModel(String)
> method is more useful for navigating a DataModel
> graph matching to an underlying object graph.

I kind of like this idea. The gui needs to work in terms of DataModels in every situation possible. It seems to me that the gui should NEVER be knowledgeable about the backend data store (whether it be an object, a collection of objects, a rowset, or something more exotic). The gui should always remain on the DataModel/binding level. In this way, the gui is loosly coupled with the backend implementation and people are then free to use JDO, EJB, rowsets, CORBA, JDBC, or whatever on the backend.

That being the case, a nice convenience method for wrapping a fields value in a data model can't be bad. The only question then becomes whether to return the SAME data model every time it is called for the same field, or a new data model every time.

> > Here's what I'm seeing are the issues you're
> trying
> > to solve:
> >
> > 1) master/detail
> > 2) master/detail bindings in xml
> > 3) convenience in specifying the binding (xpath,
> > jakarta bean utils path syntax a.b.c)
> > 4) convenience in getting a data model to wrap a
> > collection or some other object
> >
> > Are there any I missed?
>
>
> I think that sums it up well. On point 1, a detail
> model should itself be able to be a master for
> another detail model, to allow for chaining.
>
> I guess the core aim is to make it easy to bind a
> complex object model to a form, and automate lower
> level plumbing like keeping details synchronised with
> their master, and pulling/pushing data between the
> components on the form and elements on the graph, at
> any depth.

Absolutely. Master/Detail relationships must be able to be arranged in massive hierarchies.

Lets take these one at a time:

> > 1) master/detail
As I mentioned before, there are a lot of ways to look at approaching this problem. In my own framework I developed last year, the approach I took was to have a "setMaster" public method on data models which then registered themselves with the "master" model. The master then notified the children whenever a change was made in the master. It was, and I think is, a pretty solid design.

I've thought about using the binding framework from JDNC for accomplishing this same functionality. The upside is that the notification code is already functional, and a generic binding framework that binds to things other than components has some real flexibily. The downside is it feels ... weird ... to be binding one DataModel to another through a Binding.

I'm not sure that a master detail relationship can be established via the getDataModel method because the logic that is required to dictate *how* to generate the contents of the detail DataModel is very dependent on the underlying object models (CORBA, JDBC, RowSet, Object, etc).

For instance, you may have a "Customer" data model loaded with 10 customers. Then you may have an "Order" data model that will be filled with data for the current customer. We could call 'customerDataModel.getDataModel("orders")' to get the data model. If the customerDataModel was filled with full fledged Customer objects *with their complete object graphs*, then this is ok. However, if the object graph is not complete (due to partial loading, for instance), then at the 'getDataModel("orders")' method call some code would have to execute to fetch the orders from the backing store (JDBC, web server, whatever). In many cases this may be a calculated list (getDataModle("lateOrders")) which almost gaurantees some kind of delayed loading.

Transferring an entire object graph over the network isn't always a feasible option. My performance with vanilla JDO was horrendous due to the fact that JDO tried to do that very thing. If I need only a few fields and I'm a continent away from the data source, I surely don't want the entire object graph! Yet, I may later (say, after a user clicks a "details" button).

> > 2) master/detail bindings in xml

In light of the concerns posted above, I'm not sure how to handle this one. While I am personally very interested in how the xml realization occurs, I'm not using it in real life so I'm not the one to address this. What are your thoughts about how this can be achieved for each of the 3 master detail scenario's we've discussed?

> > 3) convenience in specifying the binding (xpath,
> > jakarta bean utils path syntax a.b.c)

This is a really cool idea to me. I think with the getDataModel convenience method you could do it. The only problem, again, is detailed under #1 above.

> > 4) convenience in getting a data model to wrap a
> > collection or some other object

See #1. Not a problem for a simple wrapper, but using this method for master/detail might not work so well.

Phew, sorry for the tome.

Richard

scottr
Offline
Joined: 2004-09-05

>
> I kind of like this idea. The gui needs to work in
> terms of DataModels in every situation possible. It
> seems to me that the gui should NEVER be
> knowledgeable about the backend data store (whether
> it be an object, a collection of objects, a rowset,
> or something more exotic). The gui should always
> remain on the DataModel/binding level. In this way,
> the gui is loosly coupled with the backend
> implementation and people are then free to use JDO,
> EJB, rowsets, CORBA, JDBC, or whatever on the
> backend.
>
> That being the case, a nice convenience method for
> wrapping a fields value in a data model can't be bad.
> The only question then becomes whether to return the
> SAME data model every time it is called for the same
> field, or a new data model every time.
>

I would say that a master DataModel would return the same child DataModel, for a specific field index, for every call to getDataModel(String field). The TableModelAdapter keeps a record of the current selected row, and returns that row's value in response to getField(String field). So I think that a Master DataModel that wrapped a collection would do the same. Only the data within the child DataModel would change upon changes in the parent.

>
> Absolutely. Master/Detail relationships must be able
> to be arranged in massive hierarchies.
>
> Lets take these one at a time:
>
> > > 1) master/detail
> As I mentioned before, there are a lot of ways to
> look at approaching this problem. In my own framework
> I developed last year, the approach I took was to
> have a "setMaster" public method on data models which
> then registered themselves with the "master" model.
> The master then notified the children whenever a
> change was made in the master. It was, and I think
> is, a pretty solid design.
>

I agree that you need some method in the API to link a master/parent DataModel to its detail/child DataModel/s. The question is whether the onus would be on the child to specify its parent, or vice versa, or both. Ultimately though, I believe that it is the repsonsibility of the service serving up the DataModel to ensure that it is correctly wired up in appropriate parent-child structures. The view should not need to do any of that wiring.

> I've thought about using the binding framework from
> JDNC for accomplishing this same functionality. The
> upside is that the notification code is already
> functional, and a generic binding framework that
> binds to things other than components has some real
> flexibily. The downside is it feels ... weird ... to
> be binding one DataModel to another through a
> Binding.
>

My thoughts were that the Binding exists as the 'glue' between the actual form components and their corresponding DataModel. Hence I thought of the linking of parent & child DataModels to be through API extensions of the DataModel interface itself.

> I'm not sure that a master detail relationship can be
> established via the getDataModel method because the
> logic that is required to dictate *how* to generate
> the contents of the detail DataModel is very
> dependent on the underlying object models (CORBA,
> JDBC, RowSet, Object, etc).
>

Well, the justification I saw for a getDataModel(String) method is that it would allow controlling code (eg. code that binds a root model to a form) to 'walk' the tree of children with ease. Likewise, I presume a getParentModel() method would be similarly useful.

> For instance, you may have a "Customer" data model
> loaded with 10 customers. Then you may have an
> "Order" data model that will be filled with data for
> the current customer. We could call
> 'customerDataModel.getDataModel("orders")' to get the
> data model. If the customerDataModel was filled with
> full fledged Customer objects *with their complete
> object graphs*, then this is ok. However, if the
> object graph is not complete (due to partial loading,
> for instance), then at the 'getDataModel("orders")'
> method call some code would have to execute to fetch
> the orders from the backing store (JDBC, web server,
> whatever). In many cases this may be a calculated
> list (getDataModle("lateOrders")) which almost
> gaurantees some kind of delayed loading.
>
> Transferring an entire object graph over the network
> isn't always a feasible option. My performance with
> vanilla JDO was horrendous due to the fact that JDO
> tried to do that very thing. If I need only a few
> fields and I'm a continent away from the data source,
> I surely don't want the entire object graph! Yet, I
> may later (say, after a user clicks a "details"
> button).
>

I agreee that a DataModel implementation should support lazy loading if needed, and that is true for a simple graph or even a complex graph. But that is for the DataModel implementation to worry about. As far as the view code (ie. the form) and the Bindings are concerned, they only see a DataModel, and bind components to various nodes on the DataModel graph in an agnostic way.

As I see it, a DataModel describes the 'structure' of the underlying data (javabeans, maps of maps, etc) as well supporting read/write to that underlying data. The Binding classes glue view elements (eg. swing components) to nodes on that structure, either by evaluating path expressions, or by manually walking the DataModel tree down to the DataModel node it wants to bind to. The DataModel draws its knowledge of the structure from MetaData, which can be configured from XML, or introspection on BeanInfo, or WSDL, or by some other service.

Thus, when initially creating the form, the form can be built from the DataModel even when the model is only partially or not at all loaded, because it binds components based on the structure, not the value of the underlying data.

Then, at rendering time, all the form Bindings request actual values from the DataModel node they bind to (via 'pull' methods). When the view changes (eg. a user clicks a different row in a master table, or clicks a 'next' button), the form Bindings re-request values from the model. It is up to the specific lazy-loading strategy the DataModel employs to decide at what point it requests fresh data to fill gaps in the graph, and to provide event notification to a Binding that has requested data if that data is going to take a while to load (eg. an image or text blob).

By putting all the emphasis on the DataModel to handle these issues, the view becomes very 'dumb'. It would not be very difficult to modify the Binding interface in this case to bind to any generic object (ie. instead of a Swing component), and you can then re-use the same DataModel API to bind to other view technologies (eg. JSF, etc). But that is probably outside of this discussion though.

> In light of the concerns posted above, I'm not sure
> how to handle this one. While I am personally very
> interested in how the xml realization occurs, I'm not
> using it in real life so I'm not the one to address
> this. What are your thoughts about how this can be
> achieved for each of the 3 master detail scenario's
> we've discussed?
>

I believe that the xml would only need to describe:
a) the structure of the data graph,
b) specific sub-classes of DataModel for any particular node, or even a default sub-class,
c) a suitable lazy loading strategy. This could even get a finely grained as to specify at what points in the graph loading of lazy data gets triggered off.

But xml is only one way of doing it. If you are serving DataModels up from some service, it is up to that service to build the appropriate DataModel for the data that is requested.

Scott

rbair
Offline
Joined: 2003-07-08

> I would say that a master DataModel would return the
> same child DataModel, for a specific field index, for
> every call to getDataModel(String field). The
> TableModelAdapter keeps a record of the current
> selected row, and returns that row's value in
> response to getField(String field). So I think that a
> Master DataModel that wrapped a collection would do
> the same. Only the data within the child DataModel
> would change upon changes in the parent.

I agree, definately

> I agree that you need some method in the API to link
> a master/parent DataModel to its detail/child
> DataModel/s. The question is whether the onus would
> be on the child to specify its parent, or vice versa,
> or both. Ultimately though, I believe that it is the
> repsonsibility of the service serving up the
> DataModel to ensure that it is correctly wired up in
> appropriate parent-child structures. The view should
> not need to do any of that wiring.

Oh certainly. I don't want to give the impression that the view should be doing anything. It should be as dumb as possible.

> I agreee that a DataModel implementation should
> support lazy loading if needed, and that is true for
> a simple graph or even a complex graph. But that is
> for the DataModel implementation to worry about. As
> far as the view code (ie. the form) and the Bindings
> are concerned, they only see a DataModel, and bind
> components to various nodes on the DataModel graph in
> an agnostic way.
[snip]

Ok, here I sense is where we are talking past each other. You seem to be suggesting that there would be, by necessity, many custom implementations of DataModel whereas I'm looking at it from the generic-DataModel-implementation-only-please perspective.

If we take the custom implementation approach then any 'ole DataModel implementation can ensure that the proper DataModel is returned by the getDataModel(String) method for the proper field. So that getDataModel("orders") returns immediately, for instance, and getDataModel("lateOrders") would return another data model that is to be loaded lazily.

My thoughts were from the perspective of a generic DataModel that couldn't possibly know that much information about the data model. Thus, the data model would have to be loaded by some other code (but not gui code!) and hence it wouldn't fit with paradigm of a getDataModel method.

Ah, it all makes sense now :-)

Unfortunately, the solution still isn't clear, for which path is more architecturally sound? Is it better to strive for few DataModels, where each DataModel implementation essentially implements a specific type of backing store (RowSetDataModel, JavaBeanDataModel, etc), or for DataModel implementations to proliferate in the manner that TableModels do today?

I'm going to have to sleep on this one tonight, but right now your approach feels really good on a gut level. Or... what about DataModels using an interface for the actual construction of child data models related to a specific field? The interface would be something like:

public interface DataModelGenerator {
public DataModel getDataModel(String fieldName);
}

The DataModel would then have a getDataModel(String fieldName) method as you outlined.

The AbstractDataModel would then have a constructor and a pair of methods for setting the DataModelGenerator for the DataModel. It then defers the getDataModel call to the generator.

In this way, we would be able to maintain the simplified "walking" behavior you outlined, and still be able to maintain a few core DataModels that would serve most purposes.

Rich

PS> Sorry if its a bit incoherent. Its kinda late :)

scottr
Offline
Joined: 2004-09-05

>
> Ok, here I sense is where we are talking past each
> other. You seem to be suggesting that there would be,
> by necessity, many custom implementations of
> DataModel whereas I'm looking at it from the
> generic-DataModel-implementation-only-please
> perspective.
>

I too am looking at a generic version of DataModel, but with a lot more functionality, with differences expressed in different state.

Most of the stuff I was talking about, lazy loading strategies, parent-child structure, etc, could be specified in the initial DataModel state when configuring. I wouldn't want to go down the track of having different DataModels coded for every scenario (like swing's TableModel).

A DataModel implementation would defer a lot of this stuff to helper properties that encapsulate that functionality, and are set initially when wiring it up, eg:

GraphStructureInfo - to describe the parent and children DataModels, if applicable
LazyStrategy - to describe properties that trigger off fetching of data
DataSource - describes a class and methods (probably declaratively) to invoke to retrieve or commit data (or sections of), and has the ability to invoke them.
WrappedDataSource - if you want to have another DataSource hold the actual value data, and thus remain agnostic about whether the data is a javabean, a RowSet, a Map, etc
...
and so on

All that information is encapsulated as static state for the DataModel. By that I mean it is set up once, initially, by a factory when the DataModel is first requested, and after that it doesn't change (well, unless you want it to). After that, the only thing that changes in the DataModel is the data itself that it holds.

> If we take the custom implementation approach then
> any 'ole DataModel implementation can ensure that the
> proper DataModel is returned by the
> getDataModel(String) method for the proper field. So
> that getDataModel("orders") returns immediately, for
> instance, and getDataModel("lateOrders") would return
> another data model that is to be loaded lazily.
>
> My thoughts were from the perspective of a generic
> DataModel that couldn't possibly know that much
> information about the data model. Thus, the data
> model would have to be loaded by some other code (but
> not gui code!) and hence it wouldn't fit with
> paradigm of a getDataModel method.
>

Yes, I think the DataModel implementation has to be generic enough to be reuseable across many different situations. Individual differences can be configured as static state within a DataModel. You would probably use a factory to wire up DataModels, and factory instances might employ some stategy or another to find that configuration information (eg. xml files).

Currently xml configuration of DataModels is supported, and specifies simple details about a DataModel like field display names, read-only, and so on, which is stored in the MetaData of the DataModel. I think that that could be fleshed out to provide a lot more information as described.

Scott

Message was edited by: scottr

rbair
Offline
Joined: 2003-07-08

> GraphStructureInfo - to describe the parent and
> children DataModels, if applicable
> LazyStrategy - to describe properties that trigger
> off fetching of data
> DataSource - describes a class and methods (probably
> declaratively) to invoke to retrieve or commit data
> (or sections of), and has the ability to invoke
> them.
> WrappedDataSource - if you want to have another
> DataSource hold the actual value data, and thus
> remain agnostic about whether the data is a javabean,
> a RowSet, a Map, etc
> ...
> and so on

I'm looking at this and seeing a much, much more complex API than was first proposed. I'd love to see it in action and be able to take it for a spin. Do you have this idea mocked up in code yet? Is there a chance I could see it and try it out?

Rich

scottr
Offline
Joined: 2004-09-05

> I'm looking at this and seeing a much, much more
> complex API than was first proposed. I'd love to see
> it in action and be able to take it for a spin. Do
> you have this idea mocked up in code yet? Is there a
> chance I could see it and try it out?
>

Gee, I wish. No, if I had this in code I'd have posted something already.

In the company I work for, we have a huge amount of legacy 4gl code and forms, that we want to port to Java. So I've spent some time modeling on paper a client-side API that we could use to quickly and easily write Java swing forms. Some of it was in code, but mainly the component binding stuff.

Some of the goals are that such an API would need to be easy to use by programmers without a lot of experience with Swing (but understanding the logic and layout required). It would also have to support transactional and navigational logic. I can see that it will also need to support lazy loading, given that some tables can contain upwards of a million records, and you can't trust a user not to do a search with no filters.

The JDNC API is a good start in that direction, but I can see the need for the features I've described for it to stand on an equal footing with other forms generators.

I expect that as I work more on it, I will scope out these ideas in UML then code up the relationships. I think that it probably sounds more complex than it would actually be, but there are some tricky areas to consider.

Scott

rbair
Offline
Joined: 2003-07-08

Hey Scott,

One more thing: modeling the object graph as outlined in this thread would, by definition, limit us to one bound DataModel per property, correct?

I'm not saying that's good or bad (I don't have a use case where you'd want two DataModels bound to the same property). Just something to be considered.

Along these lines, I remember Borland C++ builder (and I think Visual Basic?) had a DataSource object. You bound data sources together by telling whichever DataSource was going to be the detail what it's master was. I don't remember the specifics, though, its been a while. Anyway, the question is between loose coupling and tight coupling.

Richard

scottr
Offline
Joined: 2004-09-05

> One more thing: modeling the object graph as outlined
> in this thread would, by definition, limit us to one
> bound DataModel per property, correct?
>

Per property yes. However, a DataModel node could itself merely wrap another DataModel containing the data, in which case you could have some swap-ability of the data type (eg. Java bean, RowSet, etc)

I think that keeping the same DataModel for a property is important, as the UI only needs to bind to one instance and forget about it.

Scott

rbair
Offline
Joined: 2003-07-08

> I think that keeping the same DataModel for a
> property is important, as the UI only needs to bind
> to one instance and forget about it.

Most definately. Loose coupling will not deny this either. Instead of calling myDM.getDataModel("whatever"), you just construct the whateverDM ahead of time, just like the myDM.

Rich

scottr
Offline
Joined: 2004-09-05

>
> Most definately. Loose coupling will not deny this
> either. Instead of calling
> myDM.getDataModel("whatever"), you just construct the
> whateverDM ahead of time, just like the myDM.
>

Sorry, but I'm not entirely clear on what you're descibing as loose coupling. Could you elaborate on that a little?

Scott

rbair
Offline
Joined: 2003-07-08

Scott,

> Having looked at the JDNC api, it occurs to me that it is mainly focussed on modeling simple, 1 dimensional DataModels.

> Has anyone given any thought to supporting Object Graphs, where a field of a DataModel could itself be another DataModel? This would match to, for example, a JavaBean with other Javabeans (or collections of beans) as its properties.

The discussion has changed from answering this question originally posed in this thread to answering the bigger question of how to achieve master/detail functionality. In this reply I'm going to address both the coupling question and your original question.

Tight Coupling Approach: Having the DataModel know about its detail DataModels (this only counts as tight coupling if it adheres to the "one detail per field" rule).

Medium Coupling Approach: Having a detail data model know about its master (allows more than one detail per field)

Loose Coupling Approach: Having neither data model know about the other, and letting an intermediary (ala Binding) coordinate between the two.

The loose coupled approach is by far the easiest to implement, but probably the hardest to use for modeling an object graph. But then, why does the DataModel need to model an object graph? If objects are used as the basis for your models, can't you just get the object from the DataModel (for instance, if JavaBeanDataModel had a 'getObject' method) and traverse the object's graph naturally?

Having given the topic extensive thought I can't see the benefits of having a DataModel support object graphs. Supporting an object graph would be simple if all DataModels were backed by objects. Unfortunately, this is not always the case. In fact, in the world of VB like controls I think this is never the case. Since VB, C++ builder and other RAD tools use SQL almost exclusively you are almost guaranteed that the backing model for DataModels of such easy-to-use tools are going to be ResultSet/RowSet.

It's also not necessary to traverse the object graph for binding to gui components. Instead, you have two DataModels, workOrderDM and customerDM for instance, and components are tied to the workOrderDM or the customerDM. The two DataModels are then bound to each other in a master/detail relationship and you're done.

It has also been mentioned that by having DataModels model an object graph we could then use xpath like syntax to reach any variable in that graph. Besides the cool factor, why would this be a benefit? If you have the object graph available, why not use normal java code/syntax? If you don't have the graph available, then it becomes an absolute nightmare to try to provide this functionality over an asynchronous connection.

The asynchronous nature of distributed computing is the biggest issue facing the use of object graphs of any kind in client applications. The client gui must remain responsive, and hence it *must* use asynchronous loading. If the bandwidth between the client and server is huge (as in, they reside on the same computer or on a local network), then the entire object graph can be transported from the server to the client via RMI, CORBA, java serialization, etc. However, if the bandwidth is small (DSL, dial-up, etc), sending the entire object graph is impossible. Thus, generalized distributed computing is at odds with object graphs!

Because an entire object graph cannot be guaranteed to be loaded into memory at any given time, synchronous access to variables is not guaranteed. If synchronous access cannot be guaranteed, then I cannot use the object graphs in renderers or event handlers! Pausing in an event handler or renderer would freeze the gui, and surely no renderer can do its business on a background thread!

If supporting an object graph doesn't give the binding framework any more power, and it doesn't support synchronous access to variables, then what is gained?

Richard

scottr
Offline
Joined: 2004-09-05

Hi Richard,

I can see what you're getting at, but I think we're both talking about the same functionality, just approaching it from different directions.

As I see it, there are a few essential features that need to be supported, and which I believe could be mostly automated.

1) Synchronisation of parent (master) and child (detail). In other words, if the parent value changes, the detail is notified and refreshes itself.
2) Lazy loading. A DataModel node in the parent-child-child (etc) tree does not immediately load its value, but only when requested (eg. upon parent change).
3) Caching lazy loaded data. So you don't reload the same data again that was loaded previously.
4) Flexible DataModel node implementation. In other words, the parent could be a JavaBean, but the child could be a RowSet if desired.
5) Transactional demarcation. Beyond mere push and pull, being able to have a start and commit which could encapsulate multiple pushes and pulls.
6) Auto wiring up of a DataModel tree to perform the operations requested by the GUI.

As far as tight versus loose coupling, I had thought that the coupling would be to a DataModel interface, as I have already described earlier, via get/set parent DataModel, and/or add/remove child DataModel methods. Since the binding is only to an interface, this allows eg. a RowSet parent DataModel to be coupled to a JavaBean child DataModel. It is unlikely that different parent/child DataModels would be mixed, but it would be possible. This manner of coupling is functionally equivalent to the MasterDetailBinding you have described. I just prefer this approach for reasons I have descibed earlier in this thread, but its six of one, half a dozen of the other.

Having a single child DataModel per (complex) field is important, because the DataModel in the framework I am describing is sufficiently complex (ie. encapsulating lazy loading policy, transactional semantics, etc) to suggest that it should be 'pre-wired' by some sort of factory, rather than created on the fly. In spite of this complexity, each DataModel 'node' in the tree or graph is relatively light-weight - it only acts as a facilitator to read and write to underlying data. The data itself does not need to be loaded when the DataModel tree is wired up - that can come later, on demand.

Hence the need to support lazy loading. If a user for example clicks a 'next' button or selects a different parent row in a parent (master) table, then that can be the trigger to lazy load the child (detail) DataModel's data. But the GUI must remain responsive, and to support this you need some sort of asynchronous event notification to the GUI when loading completes. But you'd need that anyway to support lazy loading, regardless of whether object graphs are supported or not.

As far as the value of the path syntax for binding, its icing on the cake, but allows a form to need only to be aware of the root DataModel, and bind each component to a pathed element, rather than manually walk down the tree to the element it needs to bind to. But you should understand that I am not referring to using the path syntax to query the underlying data per se, which would require the underlying data to be fully loaded. I am rather using the path syntax as an alternative to walking the DataModel tree.

eg. Consider a form displaying a student register, with its list of students as a table, and each student's subjects as a detail table, and for each subject, the test exam paper (stored as a CLOB).

Walking the tree:
form.bind(registerModel.getChildDataModel("students").getChildDataModel("subjects"), "testExamPaper", textArea1);

vs.

Binding to a path:
form.bind(registerModel, "students.subjects.testExamPaper", textArea1);

But supporting this path-like syntax suggests that having actual child DataModels could be done away with in favour of having the root DataModel handle all path queries. But there is value in having each child element wrapped in its own DataModel - it modularises the tree overall, and allows for the mixed value types and differing policies.

eg. In the example above, I might specify in my service and DAO layer that the students and their subjects get loaded together in an outer join query for efficiency. But the selected test exam paper, being a BLOB, should load only on demand. So I configure the DataModel graph with a lazy value loader for the testExamPaper DataModel, but not for the students or subjects DataModel.

The advantage of placing so much of the onus for this functionality on the DataModel implementations and their helper classes, is that it separates this stuff from the GUI quite effectively. The same DataModel could then be bound to a Swing form using Bindings, or to a JSF or other web page using an equivalent API.

I know this all sounds quite complex, but it is probably less complex than my explanation makes it sound ;). And all in all, it is no less complex than what a form developer would have to face trying to achieve the same functionality. I believe that most of this boiler-plate wiring and loading code can be automated and hidden away, allowing the form developer to concentrate on creating the GUI form.

Scott

rbair
Offline
Joined: 2003-07-08

Scott,

Very well said.

> I know this all sounds quite complex, but it is probably less complex than my explanation makes it sound

Not at all, it was very well reasoned (at least to my 10:00am brain ;)).

As I mentioned in my previous post to Patrick, I think I see where I am in error in perceiving an imagined shortcoming in your model.

>I can see what you're getting at, but I think we're both talking about the same functionality, just approaching it from different directions

I think so too. In the end, I think there is still a little bit of a difference, but not a very big one. The only difference in the approaches that I can see (and this is my 5:00pm brain, not nearly as coherent as my 10:00am brain!) is that with the DataModel.getDataModel approach there can only be one DataModel per child field (that is, dm.getDataModel("blah") will always return the same field) and the dm->binding->dm approach would allow several DataModels to be bound to the same "blah" field on the master DataModel.

As I see it, the advantages of DataModel.getDataModel are:

1) Simple & straightforward API. A newbie looking at the architecture can see how it is supposed to work

2) One DataModel per form/window/panel/whatever is all that is necessary since the detail data models can be retrieved by the getDataModel call

3) Passing save/revert/commit methods to detail models is straightforward

The disadvantages are:

1) One DataModel per field (again, why anybody would want to use more than one is a mystery to me, but I don't pretend to be omniscient)

2) DataModel implementations *may* be more complex (this is a gut feeling, it could be an unfounded fear).

The advantages of the dm->binding->dm approach are:

1) Division of responsibilities *could* lead to easier development of different types of data models

2) Allows for binding as many DataModels to a field (or fields) of the parent as you want

The disadvantage would be:

1) The higher level of abstraction brings a higher level of unintuitive complexity. That is, thinking in the "customer.orders.name" mode is much friendlier than thinking in the "customer->binding->orders.name" mode.

Anyway, that's what my (now) 5:30 brain thinks. What do you think?

Richard

PS> Just for interest sake, I don't see why the dm.getDataModel approach couldn't be implemented by the dm->binding->dm beneath the covers.

scottr
Offline
Joined: 2004-09-05

Hi Richard,

The are a number of reasons for preferring a single DataModel per child field (excluding simple String, Date, int, etc fields,of course). You detailed some of those reasons in your last post.

Other reasons include:
1) Multiple child DataModels bound to the same field would conflict with each other, in that they are both meant to facilitate access/modification of the same underlying data. Either they both wrap the same data, in which case more than 1 model becomes redundant. If they don't both wrap the same data, you have synchronicity issues.
2) Transactional problems arise for multiple child DataModels on the same field. Which child DataModel contains the data to commit, or do both commit their data?
3) The DataModel is already an abstraction away from the underlying data. Adding in a binding element between parent and child adds an extra level of abstraction that is probably unnecessary.

I can see where you are getting at with supporting multiple DataModel per field approach, but I think that any gains could probably be better handled by adding functionality to the DataModel implementations. The coupling between parent and child DataModels is limited to interfaces anyway, so implementations should be able to be mixed and matched without much pain.

But all in all, the question of how to couple the parent and child DataModels to each other only covers the wiring up of the DataModel tree, which is only one of the issues. And this wiring could well be implemented by a coupling class under-the-covers, like you mentioned, and hidden from the user.

The functionality required for transactions, lazy loading, caching, etc, would be more complex. My preference is for this complexity to be handled by DataModel implementations and enclosed helper classes. I think this is similar to what you were getting at, but your approach appears to be to have the complexity encapuslated into the coupling classes instead, and the DataModel implementations kept rather simple.

regards,
Scott

rbair
Offline
Joined: 2003-07-08

Scott,

Let's move this discussion over to thread http://www.javadesktop.org/forums/thread.jspa?threadID=4171. It looks to me like the two have intersected and instead of maintaining two conversations we can all work together on one.

Richard

scottr
Offline
Joined: 2004-09-05

> Scott,
>
> Let's move this discussion over to thread
> http://www.javadesktop.org/forums/thread.jspa?threadID
> =4171. It looks to me like the two have intersected
> and instead of maintaining two conversations we can
> all work together on one.
>
> Richard

Sounds like a good idea. I only noticed a few days ago that other thread discussing the same topic, and by then I was way behind in the thread. I guess it pays not to rely on email notification alone of these things.

-Scott

rbair
Offline
Joined: 2003-07-08

At first I was going to write and say, yes it supports it, but honestly right now I don't remember whether it does or not...I've made too many modifications to the source tree to remember what the original looked like :-)

Seriously though, it shouldn't be much of an issue. If you use a JavaBeanDataModel, then you have a data model that wraps a POJO. You can easily get at any field (which returns an object), so you can also get your hands on a collection or whatnot if you use reflection (I wrote a ListBinding that did just this. It checked for a collection, or an array to see if it could use the data as the model for a JList).

Adding explicit getDataModel(String)/setDataModel(String, DataModel) methods may not be the best approach in that it would be unreliable. For instance, if I had a generic java object that I loaded into a data model, how will the data model know whether it should return a data model as opposed to a collection on a field that is a collection in the java object (or perhaps an array)?

On the other hand, these methods could just be convenience methods that take whatever field value lies at fieldName and wraps it in a DataModel. Its a little more cumbersome going the other route, however.

musing....

Rich

scottr
Offline
Joined: 2004-09-05

> At first I was going to write and say, yes it
> supports it, but honestly right now I don't remember
> whether it does or not...I've made too many
> modifications to the source tree to remember what the
> original looked like :-)
>
> Seriously though, it shouldn't be much of an issue.
> If you use a JavaBeanDataModel, then you have a data
> model that wraps a POJO. You can easily get at any
> field (which returns an object), so you can also get
> your hands on a collection or whatnot if you use
> reflection (I wrote a ListBinding that did just this.
> It checked for a collection, or an array to see if it
> could use the data as the model for a JList).
>
> Adding explicit
> getDataModel(String)/setDataModel(String, DataModel)
> methods may not be the best approach in that it would
> be unreliable. For instance, if I had a generic java
> object that I loaded into a data model, how will the
> data model know whether it should return a data model
> as opposed to a collection on a field that is a
> collection in the java object (or perhaps an array)?
>
> On the other hand, these methods could just be
> convenience methods that take whatever field value
> lies at fieldName and wraps it in a DataModel. Its a
> little more cumbersome going the other route,
> however.
>
> musing....
>
> Rich

I think that you wouldn't just be able to wrap just any JavaBean in a any DataModel and have it work. The DataModel used would have to be pre-configured with meta-data that described the JavaBean structure expected, or discover that through reflection. Where you would run into problems witrh reflection would be with (non-generics) collection fields, where you would need to specify in meta-data an expected element type for those collections.

Perhaps the most important benefits I perceived would be that, given a DataModel structure as described, each DataModel and its configured children could be auto-bound to components easily, using the Binding implementations. Also, child DataModels could be automatically updated upon changes in the parent. eg. a Master-Detail-Detail view, where selecting a different element in the first detail view, should automatically re-populate the second detail view.

regards,
Scott

rbair
Offline
Joined: 2003-07-08

> I think that you wouldn't just be able to wrap just
> any JavaBean in a any DataModel and have it work. The
> DataModel used would have to be pre-configured with
> meta-data that described the JavaBean structure
> expected, or discover that through reflection. Where
> you would run into problems witrh reflection would be
> with (non-generics) collection fields, where you
> would need to specify in meta-data an expected
> element type for those collections.

But how is this any worse, or any different, than having to specify a data model explicitly?

> Perhaps the most important benefits I perceived would
> be that, given a DataModel structure as described,
> each DataModel and its configured children could be
> auto-bound to components easily, using the Binding
> implementations. Also, child DataModels could be
> automatically updated upon changes in the parent. eg.
> a Master-Detail-Detail view, where selecting a
> different element in the first detail view, should
> automatically re-populate the second detail view.

I think the question of master/detail is a really, really important one. Two other approaches to consider for implementing m/d relationships:
1a) Have a "setMasterModel" method that allows you to tie a child to a master
1b) Have a "addChildModel" method that allows you to tie a child to a master
2) Use a MasterDetailBinding to bind one data model to another (which would require the binding framework to bind to objects rather than Components)

Cheers,
Rich

PS> Sorry, I kind of turned into Devil's Advocate here :)

scottr
Offline
Joined: 2004-09-05

> But how is this any worse, or any different, than
> having to specify a data model explicitly?
>

Just that you could configure meta-data about child DataModels in advance (eg. in xml), such as the class of DataModel to use, the field names, etc.

This then takes the onus off the client code to link the master and detail DataModels manually. If a master DataModel changes (eg. a Tabular data model changes the selected row), then it can keep its children updated.

>
> I think the question of master/detail is a really,
> really important one. Two other approaches to
> consider for implementing m/d relationships:
> 1a) Have a "setMasterModel" method that allows you to
> tie a child to a master
> 1b) Have a "addChildModel" method that allows you to
> tie a child to a master
> 2) Use a MasterDetailBinding to bind one data model
> to another (which would require the binding framework
> to bind to objects rather than Components)
>
> Cheers,
> Rich
>
> PS> Sorry, I kind of turned into Devil's Advocate
> here :)

I think the MasterDetail approach you are describing is very similar to what I am descibing also. I had thought to keep the 'wiring' between Master and Detail out of the Binding classes, just simply because I saw those classes as the 'glue' between the model and its rendering (Swing components, etc).

The API would need to allow for the possibility of complex, chained relationships, eg. master-detail-detail and so on. And also the ability to auto-configure such a relationship through the xml configuration.

regards,
Scott

siva
Offline
Joined: 2003-07-15

Your requirement of javabean as a property of a javabean can be modelled using the JTreeTable. If the property is a simple property such as int/Integer/Color etc, you can provide a simple renderer/editor for it. If not, make it a node and when the user clicks on the node, you can expand it further. You will be able to go to any depth of object navigation.

scottr
Offline
Joined: 2004-09-05

> Your requirement of javabean as a property of a
> javabean can be modelled using the JTreeTable. If the
> property is a simple property such as
> int/Integer/Color etc, you can provide a simple
> renderer/editor for it. If not, make it a node and
> when the user clicks on the node, you can expand it
> further. You will be able to go to any depth of
> object navigation.

I disagree. I've taken a good look at JTreeTable and TreeTableModel, and it merely adds a heirarchical element to a single vertical dimension, while keeping all horizontal dimensions the same. In other words, the model expects that for all children nodes in the heirarchy, all will possess the same column classes, and be rendered with the same column namees. In the JavaBeans model, this would translate to a bean where the only children it possessed are instances of itself.

In modelling an Object Graph, child properties can be a simple property (ie. integer, String, etc), a sub-graph (eg. a singular JavaBean), or a list of sub-graphs (eg. a collection of JavaBeans).

I agree that you could model this as a JTree, but not a JTreeTable, since the latter assumes all nodes possess common properties. But in any event, TreeTableModel does not adapt to the DataModel interface at all.

What is really needed is a modification or sub-interface of the DataModel interface, that supports navigation to child DataModels. This would also allow the model to be auto-bound to Binding implementations at any node.

I don't think this is a unique requirement for data binding. As far as I can see, most programs will work with header-detail data that would need to be simply translated onto a form.

-Scott

Message was edited by: scottr

siva
Offline
Joined: 2003-07-15

> > Your requirement of javabean as a property of a
> > javabean can be modelled using the JTreeTable. If
> the
> > property is a simple property such as
> > int/Integer/Color etc, you can provide a simple
> > renderer/editor for it. If not, make it a node and
> > when the user clicks on the node, you can expand
> it
> > further. You will be able to go to any depth of
> > object navigation.
>
>
> I disagree. I've taken a good look at JTreeTable and
> TreeTableModel, and it merely adds a heirarchical
> element to a single vertical dimension, while keeping
> all horizontal dimensions the same. In other words,
> the model expects that for all children nodes in the
> heirarchy, all will possess the same column classes,
> and be rendered with the same column namees. In the
> JavaBeans model, this would translate to a bean where
> the only children it possessed are instances of
> itself.
>
> In modelling an Object Graph, child properties can be
> a simple property (ie. integer, String, etc), a
> sub-graph (eg. a singular JavaBean), or a list of
> sub-graphs (eg. a collection of JavaBeans).
>
> I agree that you could model this as a JTree, but not
> a JTreeTable, since the latter assumes all nodes
> possess common properties.

No. You can implement the TreeTableModel in whatever way you want. I am infact working on a property editor which takes a bean, uses reflection and let's the user navigate the object tree. Ofcourse, my requirement is for a simple property sheet, but I am trying to make it generic and so far didn't have any issues.

>But in any event,
> TreeTableModel does not adapt to the DataModel
> interface at all.
>
> What is really needed is a modification or
> sub-interface of the DataModel interface, that
> supports navigation to child DataModels. This would
> also allow the model to be auto-bound to Binding
> implementations at any node.
>
> I don't think this is a unique requirement for data
> binding. As far as I can see, most programs will work
> with header-detail data that would need to be simply
> translated onto a form.
>
> -Scott
>
>
> Message was edited by: scottr