One constraint in a portlet environment is to play nice with other portlets. So for example, when you hook up to a global event such as body.onload or window.onload, you need to make sure that the event previously set by other portlets gets called as well.
Of course it's even better not to use these global events at all but some javascript components do use them (For example, I use HTMLArea although I'm sure other similar components exist that do not have this requirement). Also, you can't assume that the page has finished loading at the end of the portlet rendering cycle because there may be other portlets on the page that will be rendered afterwards. This is what was causing a failure with DatePicker (TAPESTRY-788). Dynamically modifying the page using DOM before the page has finished loading will make IE crash badly. Other than that, I don't see specific requirements to use window.onload and I understand that this should be avoided. Raphael Jean EntropySoft ________________________________ From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: vendredi 21 avril 2006 16:55 To: Tapestry development; Raphaël Jean Subject: portlet javascript cycle Just to be sure I'm not ignoring the needs, and to clear up any confusion on my part. What exactly are the environment constraints with javascript and portlets ? Specifically I'd like to address the injectable @Script template setup. Are there scenerios where you would want to bind to the window.onload event in an <initialization></initialization> block and others where you would want execute the script just when the rest of the content is completed ? -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
