Approved.
Please file an improvement request to clean this up at some future date?
On 2008-12-12, at 17:05EST, Donald Anderson wrote:
Change 20081212-dda-V by [email protected] on 2008-12-12 05:44:02 EST
in /Users/dda/laszlo/src/svn/openlaszlo/trunk-d
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: lzsourceannotations=true now uses backtrace lfc.
New Features:
Bugs Fixed: LPP-7435 (LPS.getLFCname needs to be remodularized),
https://nexb.laszlosystems.com/trac/main/ticket/741 (LZX:
Regression in proxied launch)
Technical Reviewer: ptw (pending)
QA Reviewer: (pending)
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details:
This change only fixes the reported problem, and does not refactor.
The technique ended up being: wherever 'backtrace' and 'profile'
have special argument handling, add the same sort of handling for
sourceannotations; add another argument to getLFCname to enforce
that the caller has knowledge about sourceannotations, and put
the smarts about what to do in getLFCname.
getLFCname should be remodularized to reduce the proliferation of
arguments, but there are some challenges to doing this, recorded
here
in case someone wants to take up the gauntlet again.
First, not all the callers to getLFCname have ready access to a
CompilationEnvironment. In particular, Canvas calls
getLFCname - combining information from an original
CompilationEnvironment
with canvas attributes (so that debugging can be set on the
canvas).
And, while this can be solved (giving Canvas a copy of
CompilationEnvironment,
or even just the properties), there are at least two additional
mysteries that
need better assessing.
1) CompilationManager.getInfoXML() calls getLFCname using values
from the request properties that don't completely line up with
the properties used either in CompilationEnvironment or
ResponderCompile.initCMgrProperties ('lzbacktrace' is used in
initCMgrProperties(),
'backtrace' is used in getInfoXML()).
2) ResponderLFC.respondImpl() calls getLFCname using standard
values
in CompilationEnvironment (yay!) except that it also consults
an extra
request parameter "_canvas_debug" (boo!)
It didn't seem safe to do refactoring and change these two call
sites (possibly
breaking some functionality), and not having these sites changed
makes
the refactoring rather less effective. If I knew how to completely
test the various namespaces that seem to be in use (whether
intentional or not),
I'd be more bold in making a change of this sort.
Tests:
Regression: {smokecheck,weather,lzpix} x {swf8,swf9,dhtml}
Functionality: simple app observing libraries loaded via args
ARGS: LFC version:
(noargs) LFCdhtml
lzbacktrace=true LFCdhtml-backtrace
backtrace=true LFCdhtml
lzsourceannotations=true LFCdhtml-backtrace
Files:
M WEB-INF/lps/server/src/org/openlaszlo/cm/
CompilationManager.java
M WEB-INF/lps/server/src/org/openlaszlo/server/LPS.java
M WEB-INF/lps/server/src/org/openlaszlo/servlets/responders/
ResponderCompile.java
M WEB-INF/lps/server/src/org/openlaszlo/servlets/responders/
ResponderLFC.java
M WEB-INF/lps/server/src/org/openlaszlo/compiler/
CanvasCompiler.java
M WEB-INF/lps/server/src/org/openlaszlo/compiler/
ToplevelCompiler.java
M WEB-INF/lps/server/src/org/openlaszlo/compiler/Compiler.java
M WEB-INF/lps/server/src/org/openlaszlo/compiler/Canvas.java
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20081212-dda-V.tar
--
Don Anderson
Java/C/C++, Berkeley DB, systems consultant
voice: 617-306-2057
email: [email protected]
www: http://www.ddanderson.com
