cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28102] New: - [PATCH] Client-side: window.onload handler clobbered by <body onload="...">
Date Wed, 31 Mar 2004 18:06:00 GMT
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.

Mime
View raw message