Re: Using JXTreeTable, a first draft

Hi guys,

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

Sorry as well been busy putting my research to use :)

> 
> great start!
> 

Thanks :)

> 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
> 

The target audience is my coworkers :). I just thought I would send to you guys as it is IMHO certainly at least as useful as the documentation I found when I first started looking...

> >
> >
> > 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).
> 

I guess my point was mainly that if you have overridden TreeTableNode's isEditable to return true and it still doesn't let you edit, this is because you also must set the column to be editable, or vice versa. Just to save some debugging time...most of the things are set only in one place, but mutability is defined in both.

> 
> > 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.


My experience in writing application software for businesses that is likely to be developed and maintained by lots of different people over a long time is to make as much of a one to one correspondence between user interface elements in the software and between the source code. This way if you want to modify any element of the application's interface you can do so without worrying about it changing any other part of the interface. Thus new developers who are not as familiar with the codebase are able to edit the application without knowing about side-effects, and even experienced developers do not need to. In my experience this is desirable for developing custom business software, others may disagree; but I have been doing this for more than a decade...


> > 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.
> 

I did want to do something on the Highlighters and Renderers but have been too busy with refactoring our application; will hopefully get to it and will let you know!

Thanks for the feedback and help in general.

Ciao,

--Alex
[Message sent by forum member 'alexkogon' (alexkogon)]

http://forums.java.net/jive/thread.jspa?messageID=276736

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

Other messages in this topic