Hi Greg, thanks for you comments / suggestions ...

>> - make ListView / TableView / TreeView extend a common base class
>> (maybe abstract), because they share some operations, and many times I
>> have to make changes in all them …
>
> There are two main challenges here:
>
> - The selection state of a ListView or TableView is represented as a 
> collection of integers, whereas in TreeView it is a collection of lists of 
> integers. So you could probably share selection management code pretty easily 
> between ListView and TableView, but maybe not TreeView.
Yes I know that Tree has a different way to handle data inside, so yes
a different/more complex approach has to be chosen, or maybe verify if
there is a simple way to define a common behaviour between all them
here ... and verify if add in TreeView a getSelectedIndex (currently
missing, and related methods) to return an integerthat maps the
absolute row number and have something that translated between this
and Paths ? Ok not-so-simple, but just as idea ...


> - All three components fire events with their own type as the source. So 
> you'll need to change the definition of the event listeners to use a common 
> base class as the source, which will break backwards compatibility. Not 
> necessarily a show-stopper, just something to be aware of.
It's one of reasons to put it in 2.1, thanks for the hint ... so I
don't know if it worth the case to do it.
Unless we could stay with current type of event source, and use the
base class only for some methods related to group of elements ...


>> - add an extended JSONSerializer (or add something to the existing
>> one, it's a detail for now) to be able to trigger custom code
>> (application-specific) when some data has to be converted to/from json
>
> FYI, you can already do something like this by passing a Bean type to the 
> JSONSerializer constructor. When given such a type, JSONSerializer will read 
> and write data from and to the Bean's properties rather than from and to 
> untyped objects like Map and List.
But even for not directly supported data types in JSON (like Date,
Calendar, BigInteger, BigDecimal, etc) ?
For sure I have to look better at it ...

Thank you for now.

Bye,
Sandro

Reply via email to