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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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.
