Hello Jsf-extenders,
When starting out in earnest on merging Jacob's JavaOne avatar
implementation into jsf-extensions, I came upon the following question:
Who has the right to load a javascript library, such as dojo or
prototype?
Right now, Jacob's code just puts it in the web-app, but an easier to
use solution would be to bundle it in the avatar.jar and use a resource
loading scheme such as shale remoting. The problem is that we want to
avoid loading multiple copies of the same javascript library, possibly
with different versions, into the browser during the same webapp. For
one thing, it wastes time, and for another, it may cause instability.
Consider this example.
Jacob's javax.faces.js avatar library depends on prototype. Using a
jMaki component that also wraps something in prototype would mean that
both parties need the prototype.js files, but neither jMaki no avatar
know about eachother, and therefore they load their own js files as
needed.
Greg, it looks like jMaki currently punts on the whole resource-loading
thing, requiring the user to put the js files manually in the right
place in their apps. Jacob, it looks like your demo does the same.
Here's a proposal:
Because jMaki's main value add is its JavaScript wrapper capability, and
because it already has a namespace of sorts for each main javascript
library, (witness the "type" attribute of the a:ajax component, where
valid values include "dojo", "scriptaculous", "yahoo", etc), I think
jMaki is the right place to host this functionality.
However, Shale Remoting already has something very close to what we need
in the form of the XhtmlHelper.linkJavascript() method [1]. We just
need some pre-defined resourceIds for each of the libraries. We
probably also want the scheme to be version aware.
On the other hand, Jacob mentioned that weblets already has
version-aware-ness. Can you offer insight on its appropriateness here?
Ed
[1]
http://struts.apache.org/struts-shale/shale-remoting/apidocs/org/apache/shale/remoting/XhtmlHelper.html#linkJavascript(javax.faces.context.FacesContext,%20javax.faces.component.UIComponent,%20javax.faces.context.ResponseWriter,%20org.apache.shale.remoting.Mechanism,%20java.lang.String)
--
| ed.burns_at_sun.com | {home: 407 869 9587, office: 408 884 9519 OR x31640}
| homepage: | http://purl.oclc.org/NET/edburns/
| aim: edburns0sunw | iim: ed.burns_at_sun.com