Skip to main content

Want to close issue 70

2 replies [Last post]
siva
Offline
Joined: 2003-07-15

Hi, I logged issue 70 a few days back. Now I found a workaround while browsing the source code. So, I thought I can go to the issue tracker and provide the workaround and close it. However, I don't seem to be able to update the issue.

Here is the workaround. The model that extends the TreeTableModel should have a method with the signature

public String convertValueToText(Object obj);

as the renderer being used in JXTreeTable is JXTree which seems to look for a method of the above form in the model and if it exists, it uses it to get the text value.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Mark Davidson
Offline
Joined: 2006-02-17

Hi Siva,

I can log your workaround in the body of Issue 70. I'm not really clear if this code is still working. In the current repository, the references to this method from JXTreeTable appear to be commented out. Are you still using convertValueToText?

I have always regarded convertValueToText as a hack. JXTree uses reflection voodoo on the TableModel to infer this method but there is no indication that this method may exist - it is declared only in DOMAdapter. I would rather see it explicitely declared on an interface rather than rely on reflection to "see if it exists". Furthermore, the method naming is a holdout from an earlier time. We have sinced consolidated type conversion to use the org.jdesktop.swing.data.Converter interfact (encode/decode methods).

If the objective is to be able to have control over the display of some model data then perhaps we should try to leverage the existing Swing rendering model. Additionaly, the renderers could have the flexibilty to use the Converter registration mechanism (org.jdesktop.swing.data.Converters) and perform a text translation to/from a type.

Your original requirements in Issue 70 state that you want to display plain text or "****" if source data is encrypted. From my reading of the problem, it appears that both converters and renderers play different parts of the solution.

If you wish to display the encrypted data as clear text then I would say that your converter should decrypt the text for display. However, if you just wish to diplay "*****" to indicate that the backing store data is encrypted then use a renderer.

--Mark

siva
Offline
Joined: 2003-07-15

Mark, yes, I am using the convertValueToText and it works fine. I looked at the CVS again, and it should work. Because, the ClippedTreeCellRenderer extends the DefaultTreeCellRenderer which calls the convertValueToText in the getTreeCellRendererComponent and sets it to the label using the setText. So, by the time the paint method is invoked on the ClippedTreeCellRenderer, the label is already set. convertValueToText of the JXTree is still supporting reflextion based method call.

Yes, I totally agree that the reflection thing is more like a hack and completely against OOD. Infact, I myself will be changing the toString() function of my Tree node so that I don't need the ER (issue 70).