Navigators, events and listeners

[errael]

Note: I'm using the term NavGroup for a collection of navigators and components generally working together and associated with the same RowSet.

There are two primary goals here.

1. Maintain the state, modified/error, of all the components in a NavGroup.
2. Extend the navigators so that its buttons reflect the state of the components.

There are additional things that can be done given 1. For example providing visual feedback for which components are modified and/or in error.

An example of navigator button state would be only enable the commit button if one of it's components is modified and no component is in error. The navigation could have modes, for example an AutoCommit mode; if AutoCommit is false, then when something becomes modified the forward/backward/first/last buttons become disabled.

[errael]

Here's an exploration of implementation concepts.

Say the NavGroup navigator is in charge of events and maintaining the NavGroup state. All NavGroup components notify the Navigator when its state changes. Here some example situations on how this would work together.

Whenever a component is modified, rs.updateXxx() or simply changing a JTextField, it notifies its navigator. A component notifies the navigator not only if something is modified, but if it goes into an error state.

The navigator notifies its components to read from RowSet (could be because of next, refresh, cancel or the row has changed). The navigator notifies its components when moving to the insert row.

With this model, a component does it's own thing sending notification the navigator of state changes. Navigator can send events such as READ, SAVE. SAVE is sent if the commit button is pushed. A next button push would broadcast SAVE if in auto commit mode, do a next on the RowSet, then broadcast READ.

I think that's basically it. A lot of the implementation would be about what types/info are put in events. It seems like only the navigator would need to listen to the rowset (but maybe not even the navigator).

I haven't thought much about insert/delete in this context.

[bpangburn]

Any thoughts on how to catch changes that are made programmatically to a JComponent? I guess overriding to intercept is an option. The existing listeners certainly leave something to be desired and don't always catch what you think they will catch and/or when.

Is eventual goal to replace all listeners or to supplement?

[errael]

catch changes that are made programmatically to a JComponent

Off the top, events is the only way I know of. Overriding stuff to catch it, seems like it could get pretty weird.

I'd see an SSComponent using events with the UI element it owns, for modifications, for internal local use.

EventBus looks like a good way for events between things. It's possible that JComponent events could be coalesced and then broadcast to their owner SSComponent, haven't thought about it.

The SwingSet situation seems like a perfect fit for EventBus. Rather than relying on RowSet sevent, you can design and set up whatever you need; which seems to be focused around the navigator.

It could also provide a mechanism for communication between screens/NavGroup if that is ever a thing.

[errael]

In the weeds... The previous post is maybe stuff. This is just random thoughts that may, or may not, be relevant or useful.

One issue is how the components get hooked up, currently it's through the rowset. If the rowset object was in the event, that's all you'd need. If the event didn't have "my" rowset, then ignore it.

The event bus isn't integral to this, but I think it would make the whole thing a lot easier to implement. Conceivably, all the screens could share the same event bus. Using the rowSet field of the event to decide if the event was worth looking at.

Rather than a single/global event bus, a possibility would be to have a separate event bus for each NavGroup. Remembering that code I saw, where the component hierarchy was searched looking for a root JPanel or whatever, you could put the event bus as a client property to the groupRootContainer. A component can find its event bus from its addNotify method.

Beyond this basic concept, if an event had a rowset (maybe implied) and the column, and a type of event (modify/error/...) an SSComponent bound to the same column could track; still might want to designate a SSComp as the primary and others bound to the same column as secondaries. Or they could track.

A bound UI component would still use swing events to work with its UI component, text field, combo,...

There could also be a global event bus, for? One thought is that an event could include the table, if one navGroup modified a table, rs.updateRow(), it could broadcast that and if any other windows cared about that table, they could highlight a badge indicating who knows what. That may not make sense or be useful.

Anyway, some random thoughts on getting rid of the java listener communications and rolling your own simpler version in the future.

[errael]

This post refers in particular to the NavGroupSate PR #43

Note the properties, with getters/setters

• v3Buttons
  all button behave as in pre v4, for example save/undo always enabled.
• autoCommit - if v3buttons true then forced invisibly true
  • When false: if the current row is modified then buttons that change the row, like next/prev, are disabled.
  • When true: navigating away from a row commits any modifications.

In RowSetOps look at updateColumnText to see how postRowSetModified(comp, _rowSet) is used; and in SSCommon#setBoundColumnText postRowSetModifiedError(getSSComponent(), getRowSet()) may be executed. These methods post a RowSetModificationEvent to the event bus. In SSDBNavigator look at BusReceiver to see how the navigator gets these events.

Note that if v3Buttons is true then these RowSetModification events don't matter. You get the old behavior.

With this in place, it is trivial to add a NavigationEvent that is broadcast by a navigator to coordinate a RowSet's components; such an event can have a type like SAVE, READ. It may be that an INSERT event is needed. More types could be added, but it's not clear they are needed. For example, before changing rows, the navigator posts a SAVE; after moving to a new row post a READ. It seems like a CANCEL or REFRESH is not not needed, the navigator can just post a READ. With this in place, components should not need to listen to RowSet events.

[bpangburn]

Is the Data Navigator as modified broadcasting any Navigation events? If I'm reading the above correctly, you're saying it would be easy to add, but nothing has been added yet.

[errael]

You got it right. The DataNav is only receiving events. And yes, it is simple/quick to add.

[errael]

As stated in the first post, a primary goal is to

Maintain the state, modified/error, of all the components in a NavGroup.

Early experiments with smart nav buttons revealed that there was no way to determine if a row was "dirty" (in other words, would rs.updateRow do anything). The implications and extent of update issues escaped me.

To summarize, there is no way to track the progress in updating a particular row. There is no way to find out if intermediate changes were made, or what the changes are. There is no way to determine if you are on the insert row. The jdbc 4.2 spec, 15.2.4.1 Updating a Row, is interesting reading.

One thought (overkill?) is that when navigator goes to a new row, it first reads the row values of each column as a string and/or object and then broadcast the "READ" ("NEW_ROW"?) event to the SSComponents; I guess it could even include the new object/string in the event. Then later, setBoundColumnText can always do the rowset.updateField, but only set dirty if there's a difference. May want to track which columns have been changed. Reading the values is pretty low overhead compared to getting to a new row.

I consider it an open issue as to whether once dirty is set, if it can get reset through changing a value back to the original or only through commit/refresh.

Additional issues

Navigator undo

Currently, the navigator undoButton does not return the values to what they were before the user started editing a row. The undo button does two things

1. rs.cancelRowUpdates
2. rs.refreshRow

The first forgets about modifications staged with rs.updateXxx, the second reads the current row values from the database. If there were changes to the database, the user will get the new values rather than the values when editing started. This could give an inconsistent view of the the data; and consider if the user has mulitple screens with info from different tables.

auto commit

Currently, any navigation that changes the current row does an rs.updateRow. The javadocs are mildly ambiguous as to whether or not this touches the server if new modifications are staged, but doing rs.updateRow fires rowChanged event even if nothing was changed; so I wouldn't be surprised if the database was touched. Only doing rs.updateRow if there was a change could save database/network traffic.

checking resultset metadata

There's a variety of metadata that describes database/rowset capabilies. Should these be checked beforehand. Or just let database exceptions happen. Probably makes sense to assume the app checks these things... This question is here just because. Overall, if there are assumptions or things in SwingSet that require certain capbilities, they should be specified. It's possible there are some things that could/should be considered and behavior adjusted as appropriate; or ?

[errael]

@bpangburn With #144 coming to resolution, and while you're remembering it, it'd be great to note your thoughts on what simplified communications which are used/handled by SSSyncManager might look like.