FLUID-5475: Improve diagnostics when framework is used within node.js

Description

The diagnostics when the framework is used within node.js are frequently unhelpful, especially those from the IoC testing framework.

Many of these issues stem from the formatting strategy used by the default console.log implementation in node.js, which is based on their utility "util.inspect" -

http://nodejs.org/api/util.html#util_util_inspect_object_options
http://stackoverflow.com/questions/21524415/node-console-log-util-inspect-for-nested-object-array

Many test fixtures take the form of applying a jqUnit.assertDeepEq between compound objects - when these fail, the user is unhelpfully faced with a diagnostic of the form -
expected: [object Object] found: [object Object]

which is of no help in understanding the issue.

As well as this we should improve some cases when using the IoC testing framework where IoC resolution fails to locate a listener - this will produce diagnostics of the form "undefined has no member called apply" which similarly provides no help in understanding the cause of the failure.

We will make improvements to fluid.prettyPrintJSON, a long-standing utility in FluidDebugging.json, including robustifying it for dealing with the case of circularly linked structures, and provide a capped complex object trace controlled by a new framework option fluid.logObjectRenderChars , by default to supply complex object traces capped at 1024 characters.

Comments

• Antranig Basman commented 2014-11-20T15:34:18.368-0500

  Note that the node built-in utility utils.inspect is capable of safely rendering any kind of material if it is used manually, with the options util.inspect(...., {depth: null}) - this has to be imported explicitly and invoked manually to convert the material to a string -

  http://nodejs.org/api/util.html#util_util_inspect_object_options

• Antranig Basman commented 2014-11-20T17:37:20.186-0500

  Minor pull still open at https://github.com/fluid-project/infusion/pull/556