• Post Reply Bookmark Topic Watch Topic
  • New Topic

Generalized table maintenance design  RSS feed

 
Mike Cheung
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Heena Agarwal wrote:
Heena wrote:It may reflect some of those changes that happened after you created the iterator but there is no guarantee. I think the state changes that take place after you start iterating are never reflected. But these are implementation details. As such we know that iterating through a ConcurrentHashMap may not give us the most recent updates that happened to the Map ( the ones that happened after we created the iterator ). We would use it if we either don't care about missing some of the updates or if we know that such updates are not likely and we want maximum concurrency in that kind of a setting.

This isn't the case with the iterator returned by a LinkedHashMap or a synchronized view of a LinkedHashMap.


There are some small but significant incorrect things I have said in my response. Here is a better response.

It may reflect some of those structural changes that happened after you created the iterator but there is no guarantee. I think the state changes that take place after you start iterating are never reflected. But these are implementation details. (This is an just an untested observation. Not even an implementation detail. As such we know that iterating through a ConcurrentHashMap may not give us the most recent structural updates that happened to the Map ( the ones that happened after we created the iterator ). We would use it if we either don't care about missing some of the structural updates or if we know that such updates are not likely and we want maximum concurrency in that kind of a setting.

Hi there. Thanks for the clarifications. I've since been looking at the new TableView class made available via JavaFX from this Oracle tutorial here. It looks like I can do the following:
1) Create a POJO class that contains the columns as properties of the class. Each object of the class represents a row. Neat!
2) Create a TableView class that contains a list of the new POJO class from 1) above. Any insertion of additional POJO class from 1) represents a new row inserted into the TableView class and this gets reflected immediately and automagically on the JavaFX GUI.

This is all great! But how do I do the following:
1) Access a specific cell in the table via a row name and col name?
2) Return all cells in a column as an array, by specifying the col name?
3) Have more than one GUI data binded to this TableView?
4) Specify the POJO class dynamically at run time? If I want to create an interface (say a web service) that allows someone to add columns, remove columns, etc at run time and this needs to be reflected both internally in memory and externally on all the connected GUIs?
 
Heena Agarwal
Ranch Hand
Posts: 262
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're probably not asking your questions to me. But if you are, I'm the worst person you could have chosen. Anything that starts with javax.swing is too complex for me. Not that other things are easy but that import statement itself scares me.

Sorry. Perhaps someone else might have suggestions for you. Good luck.
 
Paul Clapham
Sheriff
Posts: 22509
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You have a lot of questions there. But on the other hand there's a lot of information in that tutorial which you probably haven't gone through in detail. For most of your questions I would suggest finding some similar tools which are actually supported by the class, and then write helper code which maps your requirements into the ones actually supported.

Also:

3) Have more than one GUI data binded to this TableView?


One of the methods documented says something about "Forwards the given DocumentEvent to the child views that need to be notified of the change to the model." So you should look into how to set up child views. In a regular GUI you would be updating the model rather than the view, and have more than one view component listening to changes in your single model component. But it looks like the TableView class blurs that design somewhat. Or maybe not. But you should look into that.

4) Specify the POJO class dynamically at run time?


The TableView component appears to be more designed to use existing classes for data entry, rather than to design data entry forms. I expect it would be an advanced topic to make the Element object which you feed into the TableView be dynamically controlled, or perhaps there would be a better way than TableView. You would have to make that determination after becoming more than a 10-minute expert with TableView.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!