Hey, all —
I feel, quite strongly, that this mechanism needs to be treated as a part
of the parse and render process rather than a log, and should follow the
idioms of the refresh mechanism. I say this because I'm proposing this as
a tool for users more than for developers.
What I'd like to see is a unit which is installed in the widget tree and
can create a report of the following errors and warnings, which are
otherwise silently ignored and can be hard to debug:
- Parsing issues (unclosed markup and suspicious elements)
- Attempts to transclude non-existent tiddlers
- Attempts to expand non-existent macros
- Unrecognized arguments in macros
- Illegal HTML elements and attributes which have been blocked by the
wiki
- Specific errors raised by widgets and/or JavaScript macros (eg, my
formula plugin's compile errors)
Ideally each warning should include a tiddler and line number, along with a
"backtrace" of macro expansions and transclusions. But again, those are
bells and whistles and a warning mechanism would still be immensely useful
with a fraction of this functionality.
The difficult part about implementing this is that the data needs to be
maintained in a manner similar to the DOM itself, and errors may appear or
disappear with each refresh. This is complicated by the fact that certain
errors only occur at parse, construction or execution time. To remedy this
I suggest accumulating warnings in a namespaced structure for each widget.
{constructErrors: ..., renderErrors: ..., refreshErrors: ...}
Another tricky problem is that it might be necessary to report errors in
the page template, rather than individual tiddlers, in case of any problems
rendering the main view or sidebar. This could be accomplished by
revealing another "warnings" badge with the page buttons or near the
"expand" button...
On Friday, 19 January 2018 04:59:19 UTC-6, PMario wrote:
>
> Hi,
>
> TW has a logging mechanism, that reports to console.log. ... It needs to
> work in the browser and as a stand alone component in node js.
>
> Have a closer look at the source. Search for $tw.utils.log or at utils.js
> export.log().
>
> For my stalled beaker-adaptor, I did extend the mechanism a little bit, to
> make it more configurable, and write the log output to different tiddlers.
> ... I'll need to dig out the code, but I think, I pretty much have what the
> OP describes.
>
> The biggest problem is: performance. ... If we implement a generic logging
> mechanism into low level functions, that are called very often, it will
> slow down the whole thing. ...
>
> will post here, if I found the stuff.
>
> have fun!
> mario
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/a148754c-3a84-49a6-b64a-b36efbd98903%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
