laurgarn
commented
2 years ago The currently defined interface already allows to interleave instances of what has been worded LogEvent (leaf) and LogContext (non leaf). But, as you point with this user story, the implementation does not keep this interleaving, as each kind is kept in its own sequence. So I'd say we have two options. 1) break nowaday interface and have Three kind of nodes : leaf, leaf container, non-leaf container. Hard to use and breaks existing calls. 2) have leaf and non-leaf insertable in a same sequence. In modern java, it means having both implement a common interface (LogItem in Convergence).
I think we should go the second option, but we'd be left with same problem I faced in Convergence. Because we use a tree (to navigate more easily through the hierarchy of contexts) and a table (to show all leaves under a tree node/context), but the tree helps less for leaves with non-leaf siblings. Especially, if a leaf sums up its closer context after "earlier" sibling that transitively contain a lot of leaves, user could : 1) see a red context with only green sub-contexts, wondering how 2) have to select the parent context and then scroll down to the end of the table to see the (red) sum up at the bottom.
In Convergence, I came up with a functionaly satisfying but aesthetic-al questionable soluton. In the front end, I create an "artificial context" for any (may be run of) leaf that has at least a non-leaf sibling, so it can be selected in the tree. The aesthetic-al annoyance is that the only "text" I could come up with for such artificial contexts was numbering them in their parent context. To be noticed that Youssef Akel asked last year to extend this solution to some other place I don't remember, though.
Not sure, how long it will take you to understand my writing. I will have to illustrate this with some screenshots, I guess
flo-dup
Do you want to request a feature or report a bug? Feature/Bug
What is the current behavior? From a given reporter, when we create child reporters or reports, in ReporterModel implementation we lost order. We just keep order of reports and order of child reporters but all reports and child reporters are store in a separate container. Reports are first then child reporters. The consequence is that to keep full order we need to create dummy child reporter et never store reports in a reporter directly if some child reporter need to be created.
What is the expected behavior? We should keep the full order with inter mixed reports and child reporters and it should be specified in the API that all implementations must follow this design.
What is the motivation / use case for changing the behavior?
Please tell us about your environment:
Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)
(if a question doesn't apply, you can delete it)