Re: Using JXTreeTable, a first draft

Hi Alex,

at last I can get back to you, sorry for the delay.

> As promised here is my first draft of my documentation on how to properly implement JXTreeTables in your application. 
>   

great start!

A couple of comments (don't want to cite too much, hope it's clear enough):


> Using JXTreeTable
>
> Introduction
> This document is an introduction to an attempt to define a best practice for implementing SwingX JXTreeTables. 
>   
Just wondering: what's the target audience? Maybe you could add a 
sentence or two about the assumed pre-knowledge, from the content later 
on, looks like a certain familiarity with core swing modeling/rendering 
is good enough. On the nitpicking side about wording: "implementing ... 
JXTreeTable" is a no-no - the views are _used_ as-are :-) Custom code 
implements/extends smaller building blocks which are plugged into the 
view to achieve the required functionality, as you state in the 
following section

>
>
> What to subclass to implement your functionality
> It is suggested that the user should be able to accomplish everything they want by using the DefaultTreeTableModel class directly and subclass AbstractMutableTreeTableNode, ColumnFactory, and whatever highlighter/renderer/editor classes they need to implement their functionality. 
>
>   

Being a separatist (and a despostic one :-) I would suggest to clearly 
draw a line between the modeling of data (into a form understandable by 
SwingX) on the one side and the visual config on the other. As to the 
modeling: it's a treeModel extension (something often overlooked) and 
quite analogous to core treeModel there are two basic approaches:

- the data itself has a hierarchical structure: implement a custom 
Tree/Table/Model (SwingX: extend AbstractTreeTableModel)
- the hierarchical structure is externally glued to the data: implement 
a custom MutableTree/Table/Node (SwingX: extend 
AbstractMutableTreeTableNode) and use it in a DefaultTreeTableModel.


[snippet very clear hands-on how-to]

until a slight itch:
> What is editable ...
> This means if you want to control editing solely at the column level via your ColumnFactory, you must override this and hard code it to return true (by default it always returns false). 
>   

technically that's true: but beware - it's the model's responsibility to 
protect itself! That's why the abstract implementation is false (to be 
on the safe side) and subclasses must explicitly enable if allowed. So 
generally, it's not the best of ideas to put the control completely into 
the column (or the table itself).


> Sample Code
> This sample code shows definition and instantiation of the TreeTableNode subclass and basic setup (full runnable code is below).
>
>   

I'm aware that sample is just that - a sample :-) Nevertheless, the 
MyTreeTableNodeInterface is a bit ... over-constructed, IMO. So I would 
suggest to implement something slightly more useful, like f.i. a node 
wrapping a list or an array. The XRendererDemo in the swinglabs-demos 
has one, f.i.
> For simplicity and maintainability, I think it is better to have a one-to-one relationship between UI tables and ColumnFactorys so that each Table can be modified individually with no side effects on other tables, so I recommend using the per table implementation, and will do so for the remainder of the document.
>   

While that's definitely a very valid option, it's not how it is meant to 
be used: in my vision the factory has application scope by default and 
can be made instance scope in the special case. Again, an example is in 
the swinglabs-demos. Which requires a) to re-define the model's 
columnName meaning the identifier and b) reasonably unique identifiers 
across the application. Which we can't enforce in the general case (no 
longer having such a nice thingy as a MetaDataProvider back in the early 
days ... ;) That said: we need field experience with both, so any 
feedback highly welcome.
> Controlling column title and header appearance
> TableColumnExt allows you to set a column's title (setTitle()) or even a custom renderer for the column's header (setHeaderRenderer()). 
>   

a slight beware: per-column header renderers typically aren't consistent 
with LAF if the default has some "active" state like rollover.

cool work - keep it coming!

CU
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: [jdnc-unsubscribe@masked-domain]
For additional commands, e-mail: [jdnc-help@masked-domain]

Other messages in this topic