Hi Scott, Yeah, if you want to start porting to the model stuff as described, go right ahead. I think we'll get both performance and maintainability out of it.
For MDC & Properties I think columns would be a good idea, although it'll be interesting to see how it looks with potentially large numbers of columns (The column selector frame will look interesting too, might need to go to a 2 combo box selector style). For NDC, however, I'm not sure it makes as much sense as columns. NDC, all the values are related to one another, where's as Properties and MDC are distinct entries. Anyone have any further comments here? I'm personally not using a lot of MDC/NDC/Properties stuff in a real situation yet, so I'm not sure my comments are probably worth much. Anyone using them heavily wish to jump in and discuss? Re: Eclipse Plugin - superb idea, and something I would use a hell of a lot myself personally. Might require a goodly amount of refactoring, but worth it in the log run, since Eclipse is so popular. I'll defer the Detail pane formatting stuff until the TableModel stuff has been converted, as it'll be a lot easier once that's done. I've still got a bit of work to do in the Receiver side anyway, plus I'm really wanting to get stuck into the documentation too. cheers, Paul Smith -----Original Message----- From: Scott Deboy To: Log4J Developers List Sent: 8/9/03 2:49 AM Subject: RE: [Chainsaw] Change TableModel to store original LoggingEvent? I agree Paul.. [A little background: When I started developing this version of Chainsaw, LoggingEvent didn't have the constructors I needed, so I started out using Vectors.] I can start on the conversion to using LoggingEvent. A point related to MDC/NDC/Properties: I see benefit in displaying the individual entries as cells in the table. Column names could use a prefix with the name (MDC-[name] or PROP-[name]). NDC could work the same way, naming the columns NDC-1, NDC-2, etc. This would provide the ability to filter and hide/display these individual values just as we do everything else, but it doesn't mesh well with your idea of a popup that lists the name/value pairs for example (mdc/ndc/props each taking up one column in the table). Opinions? Following the conversion and added support in filters, etc., here's what I'm planning: I really want LogPanel to be independent. It'd be great to be able to take LogPanel and turn it into an eclipse plugin, which would also facilitate people's interest in embedding LogPanel in standalone apps, etc. After that, I'm going to add support for a tab routing rule: If the user wanted to route unique levels to individual tabs (across applications, for example), they could set [Level] as the tab routing rule. If they wanted to route as we've defined it now (machinename/app), they could define '[PROP-log4jmachinename].[PROP-log4japp]' as the tab routing rule. The QuickFilter is great but isn't as powerful as I'd like. I'm thinking about adding a popup that allows multiple rules to be defined and ordered. The Display/Color Filtering window needs to be intuitive and I've got a layout in mind that should work well. (we can discuss this later). That's what I'm thinking...anyone have opinions or concerns? Scott -----Original Message----- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Thu 8/7/2003 3:28 PM To: [EMAIL PROTECTED] Cc: Subject: [Chainsaw] Change TableModel to store original LoggingEvent? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <<ATT66052.txt>> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
