struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHALE-183) Shale Remoting doesn't support linking Javascript of popular javascript libraries.
Date Wed, 07 Jun 2006 04:31:18 GMT
    [ 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


Mime
View raw message