[Chainsaw] Change TableModel to store original LoggingEvent?

[Paul Smith <pa...@lawlex.com.au>]

Hey All,

Scott and anyone else, I've doing some thinking about the Detail pane
formatter stuff, and I am wondering whether we should store the original
LoggingEvent object rather the decode it into a Vector of elements for
the columns. 

Given that the Columns are initialized in a particular order, and
regardless of how the user visually orders the columns, TableModel
should request a specific logical Column number and maps it to the
visual index on screen.  At least that's the way I read it in the API
and in the Swing book I have.

We could then use a switch statement for the column/row index in
TableModel.getValueAt(int, int), and map it to the particular data
element within the LoggingEvent object for that row.

This gives us a couple of advantages:

(1) Reuse the Log4j Layout infrastructure

We could then configure a number of these and allow the user to switch
(one of the implementations could even be an XSLT-based version using a
directory of XSLT files to be used as "skins" for the detail).

Otherwise this interface would have to pass in a Collection, and that's
a little confusing to potential coders of the impl, be nice if it was
just LoggingEvent, a well known entity.

(2) MDC/NDC/Properties 

Right now it's a list of the details of these properties in a single
column. Having the original LoggingEvent would allow us to have the
original data structure, and display the details in a popup window on
double click, say.  E.g. for Properties/MDC, a small table with
Key/Value columns, for NDC, a simple ordered List table. 

* It would save on CPU for the decoding.  The underlying Vector data
structure is synchronized, and with large volumes of LoggingEvents, the
decoding and manipulation of Vectors could contributing to some
performance loss.

Thoughts or comments (anyone)?

cheers,

Paul Smith


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

Re: [Chainsaw] Change TableModel to store original LoggingEvent?

[Max Rydahl Andersen <ma...@eos.dk>]

This is normally how I get high performant tables - but in runtime
and development.

+1 for this one (actually already thought this was the case for the code ;)

/max

Paul Smith wrote:

> Hey All,
> 
> Scott and anyone else, I've doing some thinking about the Detail pane
> formatter stuff, and I am wondering whether we should store the original
> LoggingEvent object rather the decode it into a Vector of elements for
> the columns. 
> 
> Given that the Columns are initialized in a particular order, and
> regardless of how the user visually orders the columns, TableModel
> should request a specific logical Column number and maps it to the
> visual index on screen.  At least that's the way I read it in the API
> and in the Swing book I have.
> 
> We could then use a switch statement for the column/row index in
> TableModel.getValueAt(int, int), and map it to the particular data
> element within the LoggingEvent object for that row.
> 
> This gives us a couple of advantages:
> 
> (1) Reuse the Log4j Layout infrastructure
> 
> We could then configure a number of these and allow the user to switch
> (one of the implementations could even be an XSLT-based version using a
> directory of XSLT files to be used as "skins" for the detail).
> 
> Otherwise this interface would have to pass in a Collection, and that's
> a little confusing to potential coders of the impl, be nice if it was
> just LoggingEvent, a well known entity.
> 
> (2) MDC/NDC/Properties 
> 
> Right now it's a list of the details of these properties in a single
> column. Having the original LoggingEvent would allow us to have the
> original data structure, and display the details in a popup window on
> double click, say.  E.g. for Properties/MDC, a small table with
> Key/Value columns, for NDC, a simple ordered List table. 
> 
> * It would save on CPU for the decoding.  The underlying Vector data
> structure is synchronized, and with large volumes of LoggingEvents, the
> decoding and manipulation of Vectors could contributing to some
> performance loss.
> 
> Thoughts or comments (anyone)?
> 
> cheers,
> 
> Paul Smith
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org