Inspector improvement: logging console

[ebruchez]

Originally a comment on #5799.

Ideas:

• <xf:message> to write to inspector console and/or JavaScript console
  • would be nice to keep log levels?
• ability to trace actions
  • info about actions would then be shown in inspector (console)

How would we tell <xf:message> to target the inspector console? Options:

• level="xxf:inspector"
  • doesn't allow specifying log levels
• level=""xxf:inspector-debug
  • too long configuration
  • duplicates xxf:log-debug, etc.
• level="xxf:log-info" xxf:log-target="inspector"
  • with xxf:log-target="inspector" inheritable

I think it would be good to separate:

• logging messages
• from the logging target/outout

We could have:

• level="xxf:debug":
  • shorter than xxf:log-debug
• xxf:log-target="logger|inspector|javascript-console"

Alternatively, we could introduce:

<xxf:log level="debug" value="..."/>

Does it make sense to split message/log? Maybe! Also, xxf:log would be shorter.

[ebruchez]

+1 today for traceing actions! This is essential. Could be done as part of the inspector, which this issue covers, or a separate console (#2169).

[ebruchez]

We still, as of Orbeon Forms 2022.1, have two formats of actions:

• the "old" format, following some XForms patterns
• the 2018.2 format, AKA the "action syntax"

3855 covers migrating from the older format.

In either case, if we log "actions", we should log the higher-level actions, not their translation into lower-level XForms actions (even though that would already be useful compared to having nothing).

I think that this means that every action implementation in actions-20282.xsl (and actions.xsl if don't do #3855 first) should also (possibly optionally) generate an explicit log entry.

[ebruchez]

A log action should also have a name/category so that the logging console can filter on that:

<xxf:log name="orbeon.actions" level="debug" value="..."/>

[ebruchez]

Implementation possibilities:

• XForm-level xxf:log
  • how to hook this up to the inspector? translates to dispatching an event? could be costly by default
  • could call up a native logger, if we had a way to redirect the output of a logger to the inspector
• XSLT implementation, which could directly dispatch events to the inspector

You could imagine a lower-level approach where the entire logging system (we use slf4j/log4s) can be configured to redirect to the inspector. However, this doesn't seem easy to do and is probably too low-level.

So instead, if we'd like the output to go to a log file but optionally to the inspector, we should go through our own higher-level system.

[ebruchez]

• [x] basic xxf:log action
• [ ] xxf:log: consider nested <xf:property>
  • already added some instances using <xf:property> in actions
• [ ] fr:xforms-inspector console is currently a single text value; should make this more efficient
  • maybe use a repeat and limit number of iterations? could also be costly…
  • or maybe just do this strictly on the client-side?
    • possibly we could still use CodeMirror but only keep its value on the client-side
  • or maybe just use the JavaScript console?
• [ ] 2018.2.x actions to produce <xxf:log> output
• [ ] legacy actions to produce <xxf:log> output

[ebruchez]

One issue with xxf:log is that, if we use an XBL component for the console, and that component listens to events, events that are dispatched before the UI is ready, including logging happening in actions running before the controls are ready, will not show.

Solutions:

1. buffer log events that happen before the UI is ready (but up to how many?) and dispatch them when the UI is ready
2. have a more built-in "console server", or UI-less XBL components; but what this would do would be to buffer events anyway, if those have to be sent to a separate console anyway

So solution 1 is probably the way to go. The event buffer could have a certain limit, and be cleared as soon as the UI is ready or they are consumed, whichever comes first.