You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cocoon.apache.org by bu...@apache.org on 2004/03/31 20:06:00 UTC

DO NOT REPLY [Bug 28102] New: - [PATCH] Client-side: window.onload handler clobbered by

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28102>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28102

[PATCH] Client-side: window.onload handler clobbered by <body onload="...">

           Summary: [PATCH] Client-side: window.onload handler clobbered by
                    <body onload="...">
           Product: Cocoon 2
           Version: Current CVS 2.1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: CocoonForms
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: ml@wrinkledog.com


See: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107952785825215&w=2

Granted, the transformation on the <body> element does preserve whatever JS statements may have 
been contained in the transformed <body>, but those in themselves are not the window.onload 
handler.  Rather, the effect of @onload is to set (i.e., overwrite) window.onload.  So if I want my onload 
logic not to be clobbered here, I have to specify it via @onload — but this is not convenient for me, as 
my HTML <body> element is generated by a common page stylesheet several transformations down 
the pipeline from the source document that cares about the onload handler.  I shouldn't have to add 
more coupling (tags and XSL) to drive this styling template and micromanage the <body> element it 
writes; much nicer to say "window.onload = initialize;" or whatever, in an external javascript resource (I 
already have transformations in place that let me drive a child of <head> into the HTML... e.g., <script 
type="text/javascript" src="...">).  At any rate, if forms-lib.js would accomodate (i.e., preserve) 
window.onload, that would just be one less surprise (and one less thing to spend time debugging) for 
the user.