[Laszlo-dev] For Review: Change 20081212-dda-V Summary: lzsourceannotations=true now uses backtrace lfc.
Donald Anderson
dda at ddanderson.com
Sat Dec 13 08:23:18 PST 2008
Made myself a P1 for the clean up:
http://www.openlaszlo.org/jira/browse/LPP-7474
I think introducing lzoptions (LPP-3479 ) with standardized names
would be a good first step.
On Dec 13, 2008, at 10:53 AM, P T Withington wrote:
> 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 dda at lester.local 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: dda at ddanderson.com
>> www: http://www.ddanderson.com
>>
>>
>>
>>
>
--
Don Anderson
Java/C/C++, Berkeley DB, systems consultant
voice: 617-306-2057
email: dda at ddanderson.com
www: http://www.ddanderson.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20081213/4d2f37e2/attachment-0001.html
More information about the Laszlo-dev
mailing list