You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Ed Burns (JIRA)" <ji...@apache.org> on 2006/06/02 22:50:16 UTC
[jira] Created: (SHALE-183) Shale Remoting doesn't support linking
Javascript of popular javascript libraries.
Shale Remoting doesn't support linking Javascript of popular javascript libraries.
----------------------------------------------------------------------------------
Key: SHALE-183
URL: http://issues.apache.org/struts/browse/SHALE-183
Project: Shale
Type: Improvement
Components: Remoting
Reporter: Ed Burns
I would like to have an enhancement to XhtmlHelper.linkJavascript() that supported many different popular JavaScript libraries. For example, I'd like to do something like:
getXhtmlHelper().linkJavascript(context, component, writer,
Mechanism.CLASS_RESOURCE, "dojo", "0.3.0");
getXhtmlHelper().linkJavascript(context, component, writer,
Mechanism.CLASS_RESOURCE, "prototype", "1.4.0");
getXhtmlHelper().linkJavascript(context, component, writer,
Mechanism.CLASS_RESOURCE, "scriptaculous", "1.6.1");
And rest assured in the knowledge that the proper script elemnets will be rendered out iff no-one else on this request has asked for these scripts to be rendered.
If we make jMaki and jsf-extensions use this, then we can save a lot of code and bandwidth.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-183) Shale Remoting doesn't support
linking Javascript of popular javascript libraries.
Posted by "Ed Burns (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-183?page=comments#action_37435 ]
Ed Burns commented on SHALE-183:
--------------------------------
Ultimately, I'd like shale-remoting.jar to contain the js files for all the javascript libraries it supports. That way I can get out of the business of bundling them into my app.
Ed
> Shale Remoting doesn't support linking Javascript of popular javascript libraries.
> ----------------------------------------------------------------------------------
>
> Key: SHALE-183
> URL: http://issues.apache.org/struts/browse/SHALE-183
> Project: Shale
> Type: Improvement
> Components: Remoting
> Reporter: Ed Burns
>
> I would like to have an enhancement to XhtmlHelper.linkJavascript() that supported many different popular JavaScript libraries. For example, I'd like to do something like:
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "dojo", "0.3.0");
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "prototype", "1.4.0");
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "scriptaculous", "1.6.1");
> And rest assured in the knowledge that the proper script elemnets will be rendered out iff no-one else on this request has asked for these scripts to be rendered.
> If we make jMaki and jsf-extensions use this, then we can save a lot of code and bandwidth.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-183) Shale Remoting doesn't support
linking Javascript of popular javascript libraries.
Posted by "Ed Burns (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-183?page=comments#action_37492 ]
Ed Burns commented on SHALE-183:
--------------------------------
CM> This eems like an interesting idea. Thinking through some of the changes
CM> that would be required, I've come up with the list below ... but one
CM> note in particular about your proposed calling sequences for
CM> XhtmlHelper.linkJavaScript() ... there is already a method signature
CM> that takes two strings after the Mechanism argument (the strings are for
CM> the resource identifier and the content type), so we'd need to come up
CM> with some different parameter ordering (or use a different method
CM> signature) to avoid ambiguous calling sequences.
Ahh for being able to use Enums.
CM> XhtmlHelper:
CM> * Add a new linkJavaScript method which takes a resource id and
CM> version number instead of just a version id
Ok.
CM> * Recast the existing method into a call to the new method, passing
CM> null for the version id (i.e. "take the default version")
Ok.
CM> * Add a new public mapResourceId() that takes an additional
CM> parameter, the version number, and recast the existing method into a
CM> call to the new method, passing null for the version id (i.e. "take
CM> the default version")
Ok.
CM> * The implementation of this method would call a new mapResourceId()
CM> method on Mapping that takes the version number as well (see below)
CM> Mapping:
CM> * Add a new method signature String mapResourceId(FacesContext
CM> context, String resourceId, String versionId)
Ok.
CM> MappingImpl:
CM> * Add an implementation of the new mapResourceId() method signature. There would need to be some
CM> TBD mechanism to configure how a resourceId + versionId gets mapped into a complete URL. This would
CM> need to support at least options like the following:
CM>
CM> * Prefix directory path ("/foo/bar.js" + "1.23" ==> "/1.23/foo/bar.js")
CM>
CM> * Insert before extension ("/foo/bar.js" + "1.23" ==> "/foo/bar-1.23.js")
I don't think it's wise to version individual JS files. Rather, what
should be versioned is the "library". Shale doesn't know about loading
a library, but I think it should have some sort of notion of it.
CM> There's an additional element of what you're asking for that is a
CM> semantics/interpretation difference, not necessarily an API
CM> change. You're asking to treat "dojo", "prototype", and "scriptaculous"
CM> as *logical* resource identifiers that would themselves be mapped to
CM> some "/foo/bar" type resource identifier, as an additional level of
CM> indirection. We'd want to think through configuring this, especially in
CM> light of how it overlaps with configuring the version id mapping
CM> described above.
Right, this is the core of what I'm asking for.
CM> Finally, with regards to prepackaging all the "popular" JavaScript
CM> libraries it supports, that would bloat the shale-remoting.jar file for
CM> people who don't happen to choose to use *any* of the libraries that
CM> happened to be included. Instead, it would be a better approach to leave
CM> shale-remoting.jar lean and mean, and then provide a repository of
CM> prebuilt jars containing, say, DOJO 0.2.2, prepackaged with some
CM> META-INF/xxx configuration file that automatically registers it with
CM> Shale Remoting by virtue of the JAR being present in the WEB-INF/lib
CM> directory. That approach scales a heck of a lot better than lumping
CM> every possible version of every popular library into a single JAR.
I like this idea, but let's just put the information in the jar
manifest. We can have an indicator file (zero length if you like) that
will make it easy to tell "this jar is a shale-remoting JS library jar". So, the shale remoting runtime will look for the presence of, say
META-INF/shale-remoting-library
If found, look at the MANIFEST.MF of that jar and inspect the name/value
pairs to discover the version, and resourceId to "top level JS file"
mapping.
> Shale Remoting doesn't support linking Javascript of popular javascript libraries.
> ----------------------------------------------------------------------------------
>
> Key: SHALE-183
> URL: http://issues.apache.org/struts/browse/SHALE-183
> Project: Shale
> Type: Improvement
> Components: Remoting
> Reporter: Ed Burns
>
> I would like to have an enhancement to XhtmlHelper.linkJavascript() that supported many different popular JavaScript libraries. For example, I'd like to do something like:
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "dojo", "0.3.0");
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "prototype", "1.4.0");
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "scriptaculous", "1.6.1");
> And rest assured in the knowledge that the proper script elemnets will be rendered out iff no-one else on this request has asked for these scripts to be rendered.
> If we make jMaki and jsf-extensions use this, then we can save a lot of code and bandwidth.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-183) Shale Remoting doesn't support
linking Javascript of popular javascript libraries.
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-183?page=comments#action_37446 ]
Craig McClanahan commented on SHALE-183:
----------------------------------------
Sorry for the lack of comment on this ... have been heads down on refactoring our build process to use Maven2 instead of Ant. We've got the basic libraries working and passing their unit tests, now just need to do the apps.
This eems like an interesting idea. Thinking through some of the changes that would be required, I've come up with the list below ... but one note in particular about your proposed calling sequences for XhtmlHelper.linkJavaScript() ... there is already a method signature that takes two strings after the Mechanism argument (the strings are for the resource identifier and the content type), so we'd need to come up with some different parameter ordering (or use a different method signature) to avoid ambiguous calling sequences.
XhtmlHelper:
* Add a new linkJavaScript method which takes a resource id and version number instead of just a version id
* Recast the existing method into a call to the new method, passing null for the version id (i.e. "take the default version")
* Add a new public mapResourceId() that takes an additional parameter, the version number, and
recast the existing method into a call to the new method, passing null for the version id (i.e. "take the default version")
* The implementation of this method would call a new mapResourceId() method on Mapping that takes
the version number as well (see below)
Mapping:
* Add a new method signature String mapResourceId(FacesContext context, String resourceId, String versionId)
MappingImpl:
* Add an implementation of the new mapResourceId() method signature. There would need to be some
TBD mechanism to configure how a resourceId + versionId gets mapped into a complete URL. This would
need to support at least options like the following:
* Prefix directory path ("/foo/bar.js" + "1.23" ==> "/1.23/foo/bar.js")
* Insert before extension ("/foo/bar.js" + "1.23" ==> "/foo/bar-1.23.js")
* Other simlar sorts of transformations, probably configured via a strategy pattern
There's an additional element of what you're asking for that is a semantics/interpretation difference, not necessarily an API change. You're asking to treat "dojo", "prototype", and "scriptaculous" as *logical* resource identifiers that would themselves be mapped to some "/foo/bar" type resource identifier, as an additional level of indirection. We'd want to think through configuring this, especially in light of how it overlaps with configuring the version id mapping described above.
Finally, with regards to prepackaging all the "popular" JavaScript libraries it supports, that would bloat the shale-remoting.jar file for people who don't happen to choose to use *any* of the libraries that happened to be included. Instead, it would be a better approach to leave shale-remoting.jar lean and mean, and then provide a repository of prebuilt jars containing, say, DOJO 0.2.2, prepackaged with some META-INF/xxx configuration file that automatically registers it with Shale Remoting by virtue of the JAR being present in the WEB-INF/lib directory. That approach scales a heck of a lot better than lumping every possible version of every popular library into a single JAR.
What do you think?
> Shale Remoting doesn't support linking Javascript of popular javascript libraries.
> ----------------------------------------------------------------------------------
>
> Key: SHALE-183
> URL: http://issues.apache.org/struts/browse/SHALE-183
> Project: Shale
> Type: Improvement
> Components: Remoting
> Reporter: Ed Burns
>
> I would like to have an enhancement to XhtmlHelper.linkJavascript() that supported many different popular JavaScript libraries. For example, I'd like to do something like:
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "dojo", "0.3.0");
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "prototype", "1.4.0");
> getXhtmlHelper().linkJavascript(context, component, writer,
> Mechanism.CLASS_RESOURCE, "scriptaculous", "1.6.1");
> And rest assured in the knowledge that the proper script elemnets will be rendered out iff no-one else on this request has asked for these scripts to be rendered.
> If we make jMaki and jsf-extensions use this, then we can save a lot of code and bandwidth.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira