struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Burns (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHALE-183) Shale Remoting doesn't support linking Javascript of popular javascript libraries.
Date Mon, 12 Jun 2006 21:02:16 GMT
    [ 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


Mime
View raw message