| [CompositeTable] Header and row control construction [message #29101] |
Sun, 18 February 2007 21:09  |
Eclipse User |
|
|
|
Originally posted by: h2.miegel.org
Thanks for a great control. We have been struggling with the Table control
and the CompositeTable control looks like it has the flexibility and
in-place editing support that we need in our open source accounting program.
The CompositeTable implementation uses reflection to create copies of the
header and row controls. This code causes problems for us. 1) We cannot
use inner classes as header and row implementations because CompositeTable
then does not find the constructor due to the implicit parameter to the
outer class instance. 2) We cannot create additional constructors to the
header and row objects that take additional parameters (well, we can create
the constructors but they wouldn't be used by CompositeTable). The net
result is that we have no way of getting data into our header object short
of a hack. The set of columns depends on options set in the account being
listed and we allow the user to further configure the columns (the selected
columns being persisted in the workbench view state memento), so we cannot
have a header implementation class for each possible set of columns (there
are millions of possible sets of columns).
CompositeTable provides a listener that fires an event after each time a new
header or row is constructed. Apart from the fact that this is a rather
bizzare way of constructing an object, it did not work for us. Constructing
the columns in this listener did not work (Unfortunately I did not
investigate why not).
Constructing the row objects using a factory pattern would solve this
problem. David says that this would break Visual Editor support. I don't
understand why. Visual Editor would still be able to add the template
instances of the header and row object as is currently done. All that would
change is the way the visible copies would be created and those copies are
created by CompositeTable, not Visual Editor.
I have attached a patch that does this. I do not see any problem with
taking things further and requiring all header and row objects be derived
from an abstract base class thus removing the need for reflection, or moving
to responsibility for row control creation to the content provider.
However, the attached patch puts control construction into a method in the
template control, thus minimizing problems that may arise because of issues
of which I am not aware.
There is a pull here between the requirement to support the creation of
static columns and layouts at coding time using Visual Editor and our
requirement to be able to dynamically select columns and row control layout
at runtime. I am sure that with a few minor changes the two will prove
easily reconcilable.
- Nigel Westbury
Attachment: patch.txt
(Size: 8.08KB, Downloaded 253 times)
|
|
|