I've been reading the Swing tutorial "How to Use Tables", and although it has been very informative for the JTable newbie, I am instantly hitting roadblocks the second I try to veer away from the examples and strike out on my own.
So, if you want your Swing app to have a nifty, custom table, it looks like their are several core classes you'll be working with at the very least:
JTable
TableModel
TableModelListener
TableModelEvent
TableColumnModel
TableColumnModelListener
TableColumnModelEvent
Just from reading the tutorials and JavaDocs, it is not obvious to me what the difference is between a TableModel and a TableColumnModel, and how they relate to each other. Obviously, the column model pertains just to a single column or all the columns (?), whereas the table model is more general. But how do they relate to one another? What areas of responsibility does each one handle? Does TableModel manage, control or somehow contain the TableColumnModel?
Closely related to the first question, in which model do I specify cell editors and renderers?
I assume that, for each of these objects I should subclass/implement them so I can customize them for my project. Is that the generally-accepted way of customizing tables (subclassing the JTable "core" classes), or are these powerful enough to support any kind of table creation?
Usually, you just define a TableModel (by subclassing AbstractTableModel), and construct a JTable instance with this table model as argument.
If you implement getColumnClass() correctly in your table model, JTable will automatically choose an appropriate renderer for each of your column. If some cells are editable (you tell by overriding isCellEditable() in the table model), the appropriate cell editor will also be associated with the column. You'll have to trigger events (using one of the fireXxx methods in AbstractTableModel) when the model changes.
Of course, if you have special objects in your cells (i.e. something other than String, Boolean, Integer, etc.), you'll have to associate a renderer to a column (and an editor if the cells in these cells are editable). This is done by setting the renderer/editor on the column of the column model. The column model is automatically created by the JTable from the table model, though. You usually don't have to creat one by youself.
So, to answer your specific questions:
TableModel is used to hold the data displayed in the JTable. You must implement it yourself. TableColumnModel is automatically created by the JTable and is typically used to associate a renderer and editor to specific columns.
If you want a specific renderer for the nth column, you get the nth column from the column model of the JTable, and you set a renderer on this column.
Usually subclassing AbstractTableModel is sufficient.
Related
I am trying to implement the model for a DataGrid. The documentation:
http://help.adobe.com/en_US/flex/using/WS0ab2a460655f2dc3-427f401412c60d04dca-8000.html#WS0ab2a460655f2dc3-427f401412c60d04dca-7fff
indicates that I need to use an implementation of IList which contains rows. What the docs do not indicate however is what interface I need to use to implement a row class. The examples are all in XML, which suggests static content.
What I need is a row implementation that can receive changes from the underlying model and provide them to the DataGrid, and likewise, receive changes from the DataGrid and provide them to the underlying model.
The documentation you cite suggests using an ArrayList class as one of the possible implementations of IList as a data provider. And the ArrayList manual states that the row class is plain Object, and all the property change handling and notification is done within ArrayList instance using its methods for add, update, delete and set index operations. So, either use this class, or ArrayCollection, or write your own IList implementation that will handle data update notification process in itself, without referring to row class.
I also think that making row class update its container list is rather pointless, because rows are designed to be just data, without any "sanity", and lists are what actively process that data, including reordering, sorting, filtering and so on. Thus, adding such a functionality to row class overturns this (working) model, thus is not needed.
I am designing a form at work where I need to be able to set "Properties" for a large number of (accounting) "structures". I have a "Value" field where the user enters the value that property must take and then I have 1 column for every structure where the user must be able to check / uncheck each property for each structure. Also, I need to be able to suggest checkbox values (aka mapping of properties to structures) to the user so that he/she doesn't have to manually click all the checkboxes that will always need to be ticked. Finally, the number of properties (rows) and the number of structures (columns) should not be assumed to be fixed though I don't want the user to be able to modify it himself. I just want it so that a dev (probably me) doesn't have a hard time adding or removing structures.
For now I have used a local table where each structure is a column and I have hardcoded my properties (which is good). However, I am not sure that using a local table is good design. We normally avoid having forms and tables in the same Access DB to separate forms and data. Also, I'm wondering if there is an elegant solution that I am missing. There will be at least 10-15 structures and 11 properties, that would make 110 (11*10) checkboxes to handle so I cannot do it manually (i.e. create 110 checkboxes and check 110 values everytime...).
Here you can see what that part of the form looks like for now.
I know this will be a chattier question but I really need a design check on this so here are a few questions that I try to make as general and objective as possible:
In Access, how is it possible to create a matrix of controls where 1 column contains a fixed (but changeable by a dev) number of properties, a "value" field that can take text and then 10+ columns with Yes/No values ?
Is it possible to do it without a local table ?
VBA is perfectly admissible.
Thanks.
In Access, how is it possible to create a matrix of controls where 1 column contains a fixed (but changeable by a dev) number of properties, a "value" field that can take text and then 10+ columns with Yes/No values ?
I've never seen any VBA code that does what you describe. VB6 allowed the creation of "control arrays" to logically group controls (and work around some limitations on the number of controls on a form), but I've never seen that mentioned for VBA.
Is it possible to do it without a local table?
Is it possible? Maybe, since you can modify a form via code by opening it in Design View and using CreateControl() to add controls.
Is it practical? Probably not, because the "Access Specifications" section of Access Help mentions the following limit...
"Number of controls and sections that you can add over the lifetime of the form or report: 754"
..so it sounds like code that repeatedly modifies a form could very well break after a while.
My recommendation would be to create a temporary table, use it, and then discard it. If you're worried about front-end bloat then you could create the temporary table in a temporary .accdb file and then link to it.
Maybe I'm missing something, but it seems pretty easy to me.
Make each structure a record.
Then in another table, make each property a record with a 1-many relationship with the structure table. So, each structure will have many properties.
Then a form based on the structure with a sub-form based on it's properties.
Default property values can be set in the table structure.
And of course the tables can be linked from another DB.
In Access, how is it possible to create a matrix of controls where 1 column contains a fixed (but changeable by a dev) number of properties, a "value" field that can take text and then 10+ columns with Yes/No values?
I'm still not certain why you want multiple bits/booleans in a single column, but you might be able to utilize bit logic and long integer column. VBA does something like this with its constants. For instance, in a MsgBox, you make your type = vbCritical + vbYesNo. Its result is in an integer value that VBA interprets to make a Critcal MsgBox with only a Yes and a No button. The reason this works is because the value of each constant is so distinct that any summation with like constants results in a unique value that can be de-parsed. It's fairly elegant from a user perspective, but I'd hate to do the math on the back-end to make such a function work.
It might be better to maintain a separate table of available properties and/or property sets and build / maintain your property sheet that way. You could assign property sets as well as individual properties to particular controls. You could also specify in either table whether there is a default value for that property and/or what that value is.
It is also likely that you do not need that many bits. I'd be happy to narrow my answer to your situation if you could update your question with more detail regarding the nature of your bit need(s).
Is it possible to do it without a local table?
You might be able to create a DAO.Recordset dynamically in Access.
It might be better to adjust your properties table(s) (see above) to be a permanent table in one of your databases rather than re-populating the same data every time.
You could take more of a master/detail approach, combining your bit fields into a string description describing the boxes which are checked.
For example, if you have a structure named 'structure1', value 100, and 5 condition bits set, you could have one string column with text 'cond1, cond2, cond7, cond8, cond9' and then another button allowing them to modify that set of conditions for that single structure.
You'd have fewer checkboxes, anyways.
The only thing I can think of equivalent to 'a matrix of controls where 1 column contains a fixed (but changeable by a dev) number of properties' is an editable query result set.
You'll need a table for your structure -> default conditions set, if nothing else, but it doesn't have to be in the same db as the front end.
HTH
Is it possible with LINQ to do a cross tab query to add new columns? These columns come from a second and third table and need to be converted to JSON to be displayed in a Telerik table.
One table contains the name of the columns that need to be displayed and the other contains the value for the rows of each column, and this relates to the first table, which has the main related data.
I have investigated dynamically creating the extra columns, but also come unstuck as they need to go through JSON serialization, as well as the difficulties of creating new properties within any class dynamically.
Any ideas would be helpful.
Regards
Mark
I hope this helps, although I'm not sure I understand completely what you're asking ...
Since you're serializing to JSON anyway (and so presumably are not overly concerned with schema/type info), I would suggest just using a Dictionary and populating your data that way. It sounds like you could run some kind of nested loop, cycling through the column names from the one table, and pulling the values from each column from the second table.
EDIT
BTW, it is possible to do dynamic properties using System.ComponentModel, although this seems like overkill from how you described your scenario (you don't require data binding, for instance). Here's a good post on SO, if you're interested: Data binding dynamic data
I want to design an object for loading and showing customized data, for example, the object firstly loads all employees in database, then look up whether login user in the list, if so then show the login user, otherwise show dummy data "all employees"(means null). But another scenario is the component should "remember" last time user selected data and show in another page, any good design suggestion?
You describe four major pieces of function:
checking the user against a list
identifying one of two scenarios
remembering selected data
using the remembered selected data
Overall I don't think you've decomposed the problem enough yet to start thinking about design patterns - patterns become important once you've identified some candidate classes and start to look at how to decouple them. So my next step would be to design some classes to do these 4 tasks and then critically example the resulting Object model, see whether refinement is needed. THe first step: identify classes with clear interfaces and responsibilities.
my questions targets at editable JTables (using TableCellEditor).
Some tools (like SQLDeveloper) allow the user to edit multiple records, create new one or delete existing records. The table shows the modified records, but the modifications are local only, until the user clicks a "save" button (or "commit" in case of SQLDeveloper). The user can also revert all his changes.
What is the best way to implement this behaviour in a Swing application with a JTable?
I don't think, that a tool like SQLDeveloper creates a copy of records listed in the table. My first idea was to create a TableModel that wraps another TableModels (this allows me to use an arbitrary implementation of TableModel) and stores only the values of the modified cells. This works fine, when the number of rows does not change. But how to handle inserting or removing rows?
Thanks in advance for any hints.
Markus
Inside your TableModel your can register a TableModelListener with the parent TableModel and process the events for insertion or deletion accordingly also within your model.