I take that back. Putting the flash player inline javascript in a method
will not help since when it is called, the flash player external javascript
will still not have been processed. So now I'm forced to statically or
conditionally include the flash player javascript in my layout at the top.
This defeats the goal of allowing components to contribute javascript to a
page.
I think a mechanism to override the inclusion of javascript at the bottom of
the page is needed. There are far too many javascript utilities that have
been written that will fail to work in the mode. And I suspect almost all
inline-rendering techniques that depend on an included javascript file will
fail.
One more addition: When including the flash player in a page, the
recommended technique is to put inline javascript that renders the flash
player where the javascript appears in the page. The javascript relies on
an external javascript file being included. If I do an asset injection of
the Flash javascript, it ends up at the bottom of the page and the flash
player inline javascript fails. So it seems like one would need to
override this behavior. Otherwise I'd have to package up the inline
javascript as a method, inject that and then call it in place. But I'm
concerned with putting all the javascript for the flash in a Java file.
That is not a natural fit.
I have some questions regarding the decision to render Javascript at the
end of the document:
1) What was the rationale/dirver for this?
2a) The upgrade notes say to use RenderSupport. Can anyone provide a
short description of how to use RenderSupport to inject a simple
javascript function?
2b) This implies that a lot of inline javascript will have to be moved
from .tml to .java classes. It seems this will reduce the "naturalness"
of being able to use javascript normally.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
