Somewhere the dev console app needs to know if backtracing is enabled,
so it can know whether to put a checkmark in that little checkbox at
the bottom to tell you that backtracing is enabled.
It uses the some XML info string from someplace provided by the LPS
server/compiler, and looks at this
xml data for a <param name="lzbacktrace"> element
var app_backtrace =
appdata.getPointer().xpathQuery("/request/par...@name =
'lzbacktrace']/@value");
On Fri, Dec 12, 2008 at 9:46 AM, P T Withington <[email protected]> wrote:
>
> On 2008-12-12, at 06:47EST, Donald Anderson wrote:
>
>> cm/CompilationManager.java has in getInfoXML() a set of lines:
>>
>> boolean isDebug = "true".equals(props.getProperty("debug"));
>> boolean isProfile = "true".equals(props.getProperty("profile"));
>> boolean isBacktrace = "true".equals(props.getProperty("backtrace"));
>>
>> String lfc = LPS.getLFCname( runtime, isDebug, isProfile,
>> isBacktrace);
>>
>> While CompilationEnvironment agrees with the names for "debug" and
>> "profile",
>> it lists BACKTRACE_PROPERTY as "debugBacktrace". Furthermore,
>> servlets/responders/ResponderCompile.java is looking for "lzbacktrace".
>>
>> I take this to mean that that "debugBacktrace" is used as the internal
>> name in CompilationEnvironment,
>> and is also the property to set with lzc if you want this. Whereas
>> "lzbacktrace" is used in URL arguments.
>> But the props in getInfoXML() come from ResponderAPP_CONSOLE and
>> ResponderINFO_XML,
>> so I would think this would also need to be "lzbacktrace" and not merely
>> "backtrace"?
>> Is there another option namespace out there?
>
> Your guess is as good as mine here. That there are too many ways and too
> many paths to discover the compile options is a long-standing issue. We
> have slowly reduced the number of paths as the number of options has grown,
> but not always successfully.
>
> Historically, the URL options started out as simple names like `debug` and
> `profile`, but we realized that polluted the query-args namespace, so more
> recent additions are prefixed with `lz` (and there is
> http://jira.openlaszlo.org/jira/browse/LPP-3479). These query args are
> translated into internal properties, which are defined in
> CompilationEnvironment.java, but also note the TODO on line 448 of
> sc/Compiler.java, where many of these names a duplicated only because the
> guy writing this code did not know how to share the constants table (using
> some whacky define the shared constants on an interface and then declare an
> implementation to get at them trick that he later discovered). The
> command-line interface used normal command flags which it translates into
> the internal environment names, but also has the escape hatch of you being
> able to use -D and the internal name (if you can figure out what the
> internal name is -- obviously this is not meant to be a public interface).
>
> As to the getInfoXML mystery, that just plain looks broken. Why it is
> querying props with strings rather than the constant prop names seems bogus.
> Luckily nothing really uses the output of that... or so it would appear.
> The app_console responder is presumably providing the xml so that xslt can
> customize the wrapper based on what options were called for, but I bet it
> doesn't do anything special with backtracing. The info_xlm responder is
> only for human consumption, so it could be wrong and no one notice; but, it
> sure would be a lot better if it were correct; in particular, if it told you
> the LFC flavor that was being used accurately. (I had to look at the
> Firebug net pane to figure out which LFC was actually being loaded.)
>
--
Henry Minsky
Software Architect
[email protected]
