[nebula-dev] Re: nebula-dev] [compositetable] different suggestions

[André Dietisheim <dietisheim@xxxxxxxxx>]

Sorry, 

my spam-filter tagged your response as spam and I assume I could have
been filtered by the clients because of that tag...

--------------------------------

Hi Dave

On Sun, 2007-01-28 at 15:02 -0600, David J. Orme wrote:
> I'm leaning toward some kind of strategy pattern object for defining
> key bindings.  CompositeTable itself would expose API for each
> command:
> 
> public void executeInsert();
> public void executeDelete();
> ...
> 

if I understand you right, you have 2 strategies in mind. 
On a first level, you want to expose table 'commands' (commands not
meant in the strict sense of command-pattern) in an API that might be
used by any component. An editor could trigger row insertion by calling
executeInsert(). A cell-control could do the same by using this API. So
traversal and activation would be exposed in the same manner, would it?
On another level you want to give any external component the chance to
hook its key bindings and execute 'commands'. 
sounds pretty convincing!
What about undo- and redo-support? handle it completely on the
model-layer? Wouldn't it be nice to expose commands (new InsertCommand()
and execute() and undo() methods in the table, that delegate to a
command stack?

> Right; if you need a cell editor API, you would build that into your
> row objects that CompositeTable uses.

of course! with that clean key binding strategy this separation is no
problem!
But if I understand you right, you follow a strategy where you do not
need any celleditor-API and that might be your advice, isn't it?

> This makes sense too, but I believe it belongs in the row object layer
> on top of CompositeTable.  

that's exactly where I wanted to put it in. My idea is to have some
delegation to a column class in the row class (isVisible(), compareTo(),
etc.). Is there any preferred way to supply my patches, if they're
welcome? standard bugzilla entries with [CompositeTable] subject?

> There is new work to provide a default Header object that uses the
> native Table to get a native header.  
> 
> 
sounds pretty exciting! I didn't like the current clabel-header (it
lacks sufficient click-feedback) and tried to fast hack this plus
resizing. I failed on resizing I overrode mouseOver, mouseEnter. They
were not triggered. Anyhow, I just had a quick try to look at the
design, code & possibilities. I used the 0.9 supplied on
eclipse.org/nebula. Can you point me to the cvs? I did not find any
repository for it so far. I'd appreciate it a lot to get my hands on
that stuff :-)

Once more, thanks a lot for your exhaustive feedback!

Greetings
André