[
https://issues.apache.org/jira/browse/MFCOMMONS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054120#comment-13054120
]
Leonardo Uribe commented on MFCOMMONS-33:
-----------------------------------------
Added new scanning and parsing of myfaces-resources-config.xml files. It was
added this param:
/**
* This param allow to override the default strategy to locate
myfaces-resources-config.xml files, that will be parsed later. In this way
* it is possible to include new source locations or handle cases like OSGi
specific setup.
*/
@JSFWebConfigParam
public static final String
INIT_PARAM_EXTENDED_RESOURCE_HANDLER_CONFIG_URL_PROVIDER =
"org.apache.myfaces.commons.EXTENDED_RESOURCE_HANDLER_CONFIG_URL_PROVIDER";
I think just a param that instantiate a class implementing
MyFacesResourceHandlerUrlProvider is enough. The default algorithm loook on
classpath for META-INF/myfaces-resources-config.xml and on servlet context for
WEB-INF/myfaces-resources-config.xml files.
myfaces-resources-config.xml files can be used with these options:
<?xml version="1.0" encoding="UTF-8"?>
<myfaces-resources-config>
<!-- Mark this library to be handled by Extended Resource Handler -->
<library>
<library-name>libraryA</library-name>
</library>
<!-- Indicate this library has another name, so if libraryC is used,
resources should be redirected to libraryC1 -->
<library>
<library-name>libraryC</library-name>
<redirect-name>libraryC1</redirect-name>
</library>
<!-- Allow to customize the request path generated, to do things like
take library resources from a Content Delivery Network (CDN) or just
take it directly from an specified location. Note it is responsibility
of the developer to configure it properly, and the resources should
exists locally under the library name selected. -->
<library>
<library-name>libraryB</library-name>
<request-path>http://someaddress.com/alternatePath/#{resourceName}</request-path>
<!-- This example shows the variables that can be called inside the
expression to construct the request map
<request-path>#{extensionMapping ? '' :
mapping}/javax.faces.resource/$/#{localePrefix}/#{libraryName}/#{resourceName}#{extensionMapping
? mapping : ''}</request-path>
-->
</library>
</myfaces-resources-config>
All libraries referenced here will be handled by the extended ResourceHandler.
Additionally, there is an option to redirect a library name into another, to
deal with possible conflicts between resources loaded, specially javascript
libraries. And finally there is an option to override the request-path with an
EL expression, so if you have a library with some static resources it is easy
to construct an url to load them from a Content Delivery Network (CDN) or just
from some specified path. The only thing you should note is the library should
exists locally under the library name, to detect when a resource can be
resolved or not.
> Extended ResourceHandler implementation
> ---------------------------------------
>
> Key: MFCOMMONS-33
> URL: https://issues.apache.org/jira/browse/MFCOMMONS-33
> Project: MyFaces Commons
> Issue Type: Task
> Components: myfaces-commons-resourcehandler
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
>
> myfaces-commons-resourcehandler module includes an "AdvancedResourceHandler"
> with these objectives:
> - relative paths between resources (css files referencing images without
> using #resource['..'])
> - caching resources in the client (disabled if ProjectStage == Development)
> - GZIP compression and local cache in tmp dir (disabled if ProjectStage ==
> Development)
> - i18n (supporting country code and language).
> This requires more discussion and work to create a full solution. In order to
> create a enhanced implementation, I have a proposal on this issue:
> - Replace AdvancedResourceHandler with ExtendedResourceHandler, which is a
> more descriptive name,
> - Use the same pattern from myfaces shared, because it is well tested.
> - Use a SAXParser to load files, since the proposed solution is java 1.6
> specific, and compatibility with jdk 1.5 is required.
> I'll commit the proposal, but keep the previous code so we can discuss over
> there.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
