I do not know what a DataStore is and why it would be needed on a client/view/application. Seems like you are trying to do too much.
Do one thing and be good at it - in this case the view.
Also, I have no idea what you would want any data model to be multi threaded. A model is bond to a view, a table or a form. What is on a form is different than what in a table. You do not want to retrive to many columns when you are retriving many rows. Do you realy need all the colums for the row 100 on page 3 of the table?
Master detail means that when you click on a row in table, you get more detail rows, large CLOB colums likely.
Sharing the data is for toys, and not real applications. When you displays the detail, you may edit it, and want freshest data, so you do not have colisions. (do I realy have to say this ?)
If JDNC could focus on writing a good presentation, that would be best. DataStore and transactions are for DAO/JDO, not even services layer.
I think you are tyring to force a Client/Server on this or are trying to write enithre applicaitons in JDNC. No, no, JDNC should be just presentation, the service and data layers still must exist as primary way's.
Let me give you a use case:
A client has a Struts web app that use JDO. (ex: jPetStore from Apache/iBatis)
They are thinking about RiA and have played w/ Flex, but found the UI slow for master-detail. So they decide to migrate their presentation layer to JDNC.
They already have unit tested DAO services, they have DTO/VO.
They have screen shots of HTML screens, that they just want to convert to JDNC. Of course, effort and resources (time) are key, so they think that it be faster to do it in Java, than have developers learn ActionScript.
So now... convert jPetStore to JDNC.
> I do not know what a DataStore is and why it would be
> needed on a client/view/application. Seems like you
> are trying to do too much.
> Do one thing and be good at it - in this case the
The DataStoreConnection represents a connection to the DataStore. Every client side application needs this, obviously, or else you wouldn't have any back end data store to save your data too! I don't care if you are using JDO, WebServices, direct Database access, or a custom situation. All client code needs to be able to get data from a DataStore and send data to a DataStore. The DataStoreConnection is simply that -- a connection to the data store.
> Also, I have no idea what you would want any data
> model to be multi threaded.
I never said anything about having the DataModel being multithreaded. Indeed, I think the DataModel ought to live on the event dispatch thread. However, the DataStoreConnection needs to be multithreaded to prevent freezing the GUI.
> I need to do a master-detail (containing two tables,
> clicking on the top one changes the content of the
> bottom table).
I presume that your detail table has columns for name and value, and rows for each of the fields? JDNC includes a master-detail demo that tracks selection in the "master" table, and populates a "detail" form record. You could use the same approach for populating the detail table in your case.
> Previously I've done it by having one tablemodel for
> the master table, listening to a mouse click,
> retreiving the right data, looking up that data in a
> hashmap, giving the detail tablmodel access to the
> new datasource and calling a datachanged event.
> It looks like it should be much simpler to do such a
> thing using filters...
Could you please elaborate on how you would use filters for this?
> but I don't see a way of
> dynamically inserting/removing filters...only adding
> a whole filterpipeline.
Even with that simplification, Filters design is quite complex. We want to make sure static pipelines are robust before we consider investing in dynamic pipelines.
> Secondly, could the treetablemodel have some
> relevance here?
It depends on what you want to show in your columns. It is possible to hold master records in treetable nodes, and detail as children nodes. Each child node could have even finer detail nodes, and so on. Note that TreeTableModel can hold generic Objects as nodes, so you can put anything you want.
Since you are using a table to show the detail, it is obvious that the detail is "rectangular". So, JXTreeTable should work for master-detail in your case. I think you could model this as a two-level treetable. Expanding the master node will show the detail for that node, but the detail nodes would all be leaves.
> Finally, do I still have to listen for clicks in the
> master table, retreieve row information, get the cell
> that contains the parameter used by the detail table,
If you stick to your current design (with two tables), then, instead of listening for clicks, my recommendation is to listen for selection events, and respond to them by retrieving row informaton, populating the detail, and so on. If you use a treetable, then you only need to set up the detail for each master node the first time it is expanded.
> By the way, I accidently discovered the
> ColumnControlButton...something I was dreading having
> to implement...wonder what else is hidden in there :)
We wanted to release this project by Easter, but it was delayed :-)
> Could you please elaborate on how you would use
> filters for this?
Unfortunately I haven't had time to implement my solution, but I was thinking something like the following:
1. Extend JXTable with function:
public void linkedTo(JTable source, TableColumn sourceColumn, TableColumn destinationFilterColumn);
2. In the detail table, I would call this function, set source to the 'master' table, set sourceColumn to the column in master table containing the 'foreign key' or input parameter to the detail table. Set destinationFilterColumn to the matching 'foreign key' in the detail table.
3. In the detail table, I would listen to selection events generated by the master tabel.
4. After getting the row from the event, I would get value from the sourceColumn, create a new filter which would set the destinationFilterColumn=sourceColumn
(guess I should've just implemented the method in the time it took me to write this :) )
The result of this would be that if I select a row in the master table, the detail tabel would automatically filter intelligently...although I don't know what kind of performance problems it might have.
You can imagine that several tables could be linked to each other in such a way.
By the way, even though I used the term 'foreign key,' my actual use for this is going to be with JMS/MQ/TIBCO and not relational dbs.
> Since you are using a table to show the detail, it is
> obvious that the detail is "rectangular". So,
> JXTreeTable should work for master-detail in your
> case. I think you could model this as a two-level
> treetable. Expanding the master node will show the
> detail for that node, but the detail nodes would all
> be leaves.
actually tree table model will probably not work for me, since data sources for master and detail tables might be different datasets, and I may want to keep them seperate rather than stuff them into the same model
I'm not in favor of handling master-detail at the JXTable/JNTable/JTable level, and would rather see this functionality placed in the DataModels. DataModels need to implement this functionality anyway, so why have the tables support it as well?
Rather, the table should be bound to a data model. The table notifies the underlying data model whenever its selected row changes. The DataModel then notifies the detail data models that they need to be reloaded, and they in turn notify their bindings which repopulate the child tables.
> Rather, the table should be bound to a data model. The table notifies the underlying data model whenever its selected row changes. The DataModel then notifies the detail data models that they need to be reloaded, and they in turn notify their bindings which repopulate the child tables.
This is pretty much how JDNC handles it today, although, as many of you
have pointed out, there are some definite issues (lazy fetch of detail,
fields as object graphics, etc).
The demo we showed at JavaOne was a master-detail. I promised weeks ago
I'd send out the source code for this demo, and I'm wayyy late on that
promise. I suppose I could skip making it pretty and just send it out
in its demo-warted form....
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
> The demo we showed at JavaOne was a master-detail. I
> promised weeks ago
> I'd send out the source code for this demo, and I'm
> wayyy late on that
> promise. I suppose I could skip making it pretty and
> just send it out
> in its demo-warted form....
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.