Replies: 12 comments 4 replies
-
|
@bpangburn @prasanthreddy-git Tweaked the glazedlists-tutorial, https://github.com/errael/glazedlists-tutorial, see https://glazedlists.github.io/glazedlists-tutorial/ for the text of the tutorial. After downloading, in the top level directory you can do to run example for chapter 7. Or A quick look at chapter 7 example, pretty cool. There's a list you can select a subset, and a text field for filtering, and a slider to set priority level. Column sort shows an arrow in heading, looks like a secondary sort column has a smaller arrow. |
Beta Was this translation helpful? Give feedback.
-
|
@errael Good summary above for 4.2. I'm about to try out some of the GL examples. Only preliminary comment I have on 4.2 / SSDataGrid / GL is that I do have some concerns about a GL-only solution based on the infrequency of their updates. It would be very unfortunately if they abandon/orphan GL and I don't want to try to maintain it. I guess if we lose GL and it strips some features, but doesn't break outright then that is OK. Probably not worth trying to do any dual implementations (ie., RowSorted and GL). |
Beta Was this translation helpful? Give feedback.
-
It seems like they already have. Admittedly they merged STRICT/CONTAINS to their dev branch. But they also said that a snapshot release would be "soon" (or something like that) and it never happened.
I don't quite understand that. Considering their track record, you don't expect them to fix something do you?
I'm not sure what you mean. If you decided not to use glazed, wouldn't any work added to your app that used sorting/filtering/... be broken? Could do something like |
Beta Was this translation helpful? Give feedback.
-
I'm still holding out some hope.
I'm hoping if they abandon it some other party will pick it up and keep it alive. I'm just being pragmatic. I already struggle to give SwingSet proper attention so saying that we (The Pangburn Group) could keep GL properly maintained and moving forward indefinitely is not very realistic. It is possible that GL works well enough for the original developers that we won't see an update unless they need to fix/update some component. If GL is truly orphaned then adding new SwingSet features that depend on GL might not be a good idea. I don't know that codebase at all, but I would be inclined to see if the bits we use for Combo filtering could be isolated and moved into SwingSet.
I'm making a distinction between loss of functionality and compile/runtime errors. If we had to pull GL then I would expect SwingSet users to be upset/annoyed, but ideally any apps using SwingSet would still run.
I agree. @prasanthreddy-git might feel differently, but the biggest SSDataGrid features I'd like to see are (1) ability to use SSComboBoxes & (2) dynamically sorting by column. Everything you outlined above would be great, but not terribly critical for our app. Masked editing consistent with new formatted fields (when complete) would be nice too. I'm waffling a bit, but I think if we feel GL is really orphaned then we need to consider not adding GL-based enhancements. Let's see what Prasanth thinks. |
Beta Was this translation helpful? Give feedback.
-
|
I think column based sorting can be accomplished without third party libraries. I agree using a abandoned library may not be good especially for adding new features.
…On 11/18/22 12:39 PM, errael wrote:
if they abandon/orphan GL
It seems like they already have. Admittedly they merged STRICT/CONTAINS to their dev branch. But they also said that a snapshot release would be "soon" (or something like that) and it never happened.
I don't want to try to maintain it
I don't quite understand that. Considering their track record, you don't expect them to fix something do you?
I'm not sure what you mean. If you decided not to use glazed, wouldn't any work added to your app that used sorting/filtering/... be broken?
Could do something like |SSDataGrid2| or |SSDataGridSort| or ??? And leave the current one. I would still expect/want the new one to plug in where the old one is.
—
Reply to this email directly, view it on GitHub <#152 (reply in thread)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATJNTDYRACOI7QXVNJJX7GTWI7EMPANCNFSM6AAAAAAR6RGIOQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Seems there's some philosophical issues relevant to GlazedLists.
I've seen online discussions about 1. 2 is a followup question to 1. Notice that 1 doesn't say "bug free". It seems clear that core developers consider glazedlists finished. I think the only reason that
When working on strict/contains, compliance with StrictContains, 2 and 3 are fixed in SwingSet through the GL fork. 1, 2, 3 have essentially been ignored by GL. I mention all this, because I'm confused. For all intents and purposes, GL is abandoned. It also seems to be very reliable, and has some good capabilities which SwingSet barely uses. There seems to be a strong sentiment that if a project is finished/abandoned then it shouldn't be used. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know enough about glazedlists. Because we are not using any other jars I am assuming there are no other dependencies for it (at least for using in swingset). The concern is what happens if
bugs/vulnerabilities are found or there is a compatibility issue with a later JDK? Would there be anyone to fix those or would we have to fork and fix them?
Thanks,
Prasanth
…On 11/28/22 3:13 PM, errael wrote:
Seems there's some philosophical issues relevant to GlazedLists.
1. Can a software project ever be complete/finished?
2. If a project is finished, is it distinguishable from unsupported?
I've seen online discussions about 1. 2 is a followup question to 1. Notice that 1 doesn't say "bug free".
It seems clear that core developers consider glazedlists finished. I think the only reason that |STRICT-CONTAINS| got traction is that some people long associated with the project wanted it (though
I'm not exactly clear of their association). There's a bug and two PRs:
1. glazedlists/glazedlists#702 <glazedlists/glazedlists#702>
2. glazedlists/glazedlists#701 <glazedlists/glazedlists#701>
3. glazedlists/glazedlists#700 <glazedlists/glazedlists#700>
When working on strict/contains, compliance with |strict mode violation| was pointed out. Later I discovered a |strict mode violation| in stock Glazed, opened an issue, no response from Glazed.
Added a workaround into SSDBComBox: #85 <#85>.
StrictContains, 2 and 3 are fixed in SwingSet through the GL fork. 1, 2, 3 have essentially been ignored by GL.
I mention all this, because I'm confused. For all intents and purposes, GL is abandoned. It also seems to be very reliable, and has some good capabilities which SwingSet barely uses. There seems to
be a strong sentiment that if a project is finished/abandoned then it shouldn't be used.
—
Reply to this email directly, view it on GitHub <#152 (comment)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATJNTDYSYSUGNEBBVUONOT3WKUN7HANCNFSM6AAAAAAR6RGIOQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I had to remember how to build GL; trick was to use JDK1.8. The build produces 26 jars for all kinds of features/integrations. Some, like jfreechart or swt, are included in the base jar. I guess they aren't referenced by SwingSet's code paths, so "class not found" is encountered; minimal security issue. Anyway, it's clear a non-glazed solution is required. A 2nd, compatible, glazed implementation is possible. It's worth noting that, AFAIK, SSComboBox's non glazed option isn't tested, so ... |
Beta Was this translation helpful? Give feedback.
-
|
One important question is: Are SSDataGrid and SSTableModel overriden by Pangburn Group apps. A big part of this question has to do with if/how GlazedLists might be an option. This post is mostly about Primary ColumnShouldn't the primary column stuff be part of the
HiddenColumnsThe hidden colum info, arrays, show up in both table and model, is this a visual thing or a model thing? Seems more like a view thing. If model, there could be a Considerations: There's TableColumn.identifier, I've seen recommendations against setting width to 0, Keep an array of TableColumns, just manipulate the TableColumnModel.
JTable.removeColumn isn't overriden, what would happen if it's called? SSDataGrid.setModelShould it be allowed to set table mode or throw an exception if it's tried. There's DataGrid.tableModel, and setModel(tableModel), but if grid.setModel() is called, doesn't change tableModel. Get rid of grid.tableModel, have setModel throw IllArg if model not instanceof SSTableModel such that restrict that can only set once, oh but bind can be called more than once. Other notesInsertion flags in both table/model. Is "multiple columns for a key" a thing? Does it matter for the grid? KeyListener in SSDataGrid for Ctrl-X Seems too low level (breaks my Ctrl Key). Using InputMap/ActionMap works, simplifies code. firePropertyChange What is Don't get the 'callExecute' comments in grid. Why rowCount/columnCount variables in both grid/model? |
Beta Was this translation helpful? Give feedback.
-
|
We don't extend SSDataGrid in the application. Without looking at the code, the general intent it that we make all the calls to SSDataGrid, it might pass some to SSTabelModel and some might be taken
care of in SSDataGrid itself.
JTable.removeColumn isn't overriden, what would happen if it's called? *Never tried it.
*Will look at the code and get back to you.*
*
…On 2/23/23 5:34 PM, errael wrote:
One important question is: *Are SSDataGrid and SSTableModel overriden by Pangburn Group apps*.
This post is mostly about |SSDataGrid| cleanup and/or reorganization. Some of this is discussed as part of #165 <#165>.
Primary Collumn
Shouldn't the primary column stuff be part of the |SSTableModel|, not the view?
|SSDataValue interface|
The interface name doesn't seem right given the method name. Might be that I /don't get the context/.
One method: |getPrimaryColumnValue|
|SSTableModel| has one.
There's |SSDataGrid.setPrimaryColumn| which depends on there being this and bounces to tableModel.setPrimaryColumn.
HiddenColumns
The hidden colum info, arrays, show up in both table and model, is this a visual thing or a model thing? Seems more like a view thing. If model, there could be a |SSTableColumnModel| or an arrya of
|TableColumn| or |SSTableColumn|.
Considerations: There's TableColumn.identifier, I've seen recommendations against setting width to 0, Keep an array of TableColumns, just manipulate the TableColumnModel.
|SSDataGrid.setHiddenColumns(array)|
The hidden columns array ends up in |SSTableModel|, it's never copied so it can be modified by the original caller. And there are two references, but looks like the one in |SSTableModel| is never used.
JTable.removeColumn isn't overriden, what would happen if it's called?
SSDataGrid.setModel
Should it be allowed to set table mode or throw an exception if it's tried.
There's DataGrid.tableModel, and setModel(tableModel), but if grid.setModel() is called, doesn't change tableModel. Get rid of grid.tableModel, have setModel throw IllArg if model not instanceof
SSTableModel such that restrict that can only set once, oh but bind can be called more than once.
Other notes
Insertion flags in both table/model.
Is "multiple columns for a key" a thing? Does it matter for the grid?
KeyListener in SSDataGrid for Ctrl-X Seems too low level (breaks my Ctrl Key). Using InputMap/ActionMap works, simplifies code.
Don't understand the key adapter for COPY/PASTE support.
firePropertyChange
|callExecute|, |columnWidth|, |insertion|, |messageWindow|, |rowSet|
What is |messageWindow| used for? How widespread?
Don't get the 'callExecute' comments in grid.
Why rowCount/columnCount variables in both grid/model?
—
Reply to this email directly, view it on GitHub <#152 (comment)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATJNTD2DZWDDTI3KO5QNPVTWY7XZRANCNFSM6AAAAAAR6RGIOQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
That makes it easier to have an interface that could be implemented by Glazed if wanted. SSDataGrid could be made final at least until things are sorted out. And it sound like SSTableModel is never used by the app.
Doubt that it's worth spending any time checking, certainly at this point. I'm just wondering about how easy it might be to break things. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, and if it not overridden, then anything protected is fair game ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Is your thinking to have applications call dataGrid.getTableModel and then set things directly to table model rather than having the method in SSDataGrid and then SSDataGrid calling TableModel methods?
…On 2/24/23 12:52 PM, errael wrote:
We don't extend SSDataGrid in the application.
That makes it easier to have an interface that could be implemented by Glazed if wanted. SSDataGrid could be made final at least until things are sorted out. And it sound like SSTableModel is
/never/ used by the app.
JTable.removeColumn isn't overriden, what would happen if it's called?
Never tried it. Will look at the code and get back to you.
Doubt that it's worth spending any time checking, certainly at this point.
I'm just wondering about how easy it might be to break things. |interface SSDataGrid| might be a way to go and leave out the problematic methods; and have some static methods, like
|SSDataGrid.get(...)|. Could always have something like |getComponent()| for emergencies.
—
Reply to this email directly, view it on GitHub <#152 (reply in thread)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATJNTD6CXNYQC2KWKTOOBNDWZD7PJANCNFSM6AAAAAAR6RGIOQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
No. I was thinking maybe have This only works seamlessly if there is no direct reference to members, all access has to go through methods. This kind of thing might be easier than trying to keep problematic methods from doing bad things. When adding sorting I noticed that Stuff like this gets messy, and I see that there's something missing, there should be in there, since I think I thought even setting it to a new SSTableModel could wreak havoc. Maybe this new check could be avoided if SSTableModel was package private, not public. But it's nice to have it public, then an application could build there own |
Beta Was this translation helpful? Give feedback.
-
|
I don't think we access/set the table model for the grids. We do access the column model a good bit to set the width of columns. I don't think we ever tired to make it fool proof.
…On 2/24/23 1:40 PM, errael wrote:
Is your thinking to have applications call dataGrid.getTableModel and then set things directly to table model rather than having the method in SSDataGrid and then SSDataGrid calling TableModel
methods?
No. I was thinking maybe have |interface SSDataGrid| which has all the methods needed for application usage. Could be hundreds of methods for all I know, but without /dangerous/ methods. The
application would not have to change, except to use various |SSDataGrid.get(existing_constructor_arg_lists)| static methods instead of constructors. Could even avoid any changes at all with
something like
|class SSDataGrid implements SSDataGridInterface { private BaseDataGrid grid; SSDataGrid(constructor args) { grid = new BaseDataGrid(constructor args); } /** cast following as needed, use only in
case of emergency */ JTable getComponent() { return grid; } // All methods delegate to grid, for example void someMethod() { grid.someMethod(); } } |
This only works seamlessly if there is no direct reference to members, all access has to go through methods. This kind of thing might be easier than trying to keep problematic methods from doing bad
things. When adding sorting I noticed that |grid.setModel()| should never be used from outside the class, I decided to see if I could harden it, ended up with
***@***.*** public void setModel(TableModel dataModel) { if(!(dataModel instanceof SSTableModel)) { if(tableModelSet) throw new IllegalArgumentException("Must be SSTableModel");
super.setModel(dataModel); return; } super.setModel(dataModel); tableModelSet = true; tableModel = (SSTableModel) dataModel; checkCreateAddSorter(true); } |
Stuff like this gets messy, and I see that there's something missing, there should be
|if(tableModelSet) throw new IllegalStateException("SSTableModel already set"); |
in there, since I think I thought even setting it to a new SSTableModel could wreak havoc. Maybe this new check could be avoided if SSTableModel was package private, not public. But it's nice to
have it public, then an application could build there own |XXDataGrid extend BaseDataGrid| and take responsibility for things.
—
Reply to this email directly, view it on GitHub <#152 (reply in thread)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATJNTD7IRG3YMQ3NYUAYEJDWZEFERANCNFSM6AAAAAAR6RGIOQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
[January 2024] Which originated from PR #165. The PR was manually copied/closed (rather than rebased) so here's a copy of the original comment which contains questions for reviewers. (If it's no longer relevant, ignore the noise) Three commits
Try this stuff using Example5. This PR fixes primary issues. It does not handle the 4.x specific stuff like #12 and #8. Or new features like filtering #127, or #6 or #9. But note that Swing's sorting includes filtering capability, need an SS API. open questions to consider during review
|
Beta Was this translation helpful? Give feedback.
-
v4.2 targets
SSDataGridfixes/enhancements. Following is a list of issues that @bpangburn identified which involveSSDataGrid. They coverStandard javax.swing vs glazed grid
Java 1.6 introduced RowSorter. Glazed suports both sorting and filtering.
Is it required to support both? If so, then Glazed is the choice.
Could consider a scheme where SSDataGrid is more like an interface for basic capabilities that work within SwingSet. Application programmer builds screen with either Glazed mechanisms or standard Swing and implements the SSDataGrid that is used with the rest of SwingSet. Not sure what that would look like; perhaps this is a direction for now involving simplifications in API.
Cleanup and integration and notes
Beta Was this translation helpful? Give feedback.
All reactions