Hi Jakob
2011/5/17 Jakob Korherr <[email protected]>:
> Hi Leo,
>
> Thanks!
>
> Some comments to your ideas:
>
>> - Resource caching (just like myfaces core does!).
> This is already implemented and it actually goes one step further,
> because it uses GZIP compression too!
>
I was thinking on do something like in myfaces core ResourceHandler,
because calls to getResource() are expensive. Really I think we should
move the code on org.apache.myfaces.shared.resource to
myfaces-commons-utils or myfaces-commons-resourcehandler.
This package contains some very useful stuff that we can reuse here.
See org.apache.myfaces.shared.resource.ResourceHandlerCache for
details.
>> - Find a better name for advanced-resources.xml. It is ok, but I'll
>> prefer a more intuitive name, like myfaces-resources-config.xml or
>> something like that, so people can understand easily which one is the
>> intention of this config file. Maybe some renaming of the classes
>> could be helpful (if we find a better name).
> That would be very good, yes. Unfortunately I am not good with names..
> However, I was thinking of using <faces-config-extension> rather then
> a separate xml file for it. WDYT?
I was thinking on the same, but after review it more carefully, it seems
better use another file by two reasons:
1. A separate xml file(s) is easier to understand for users. The file could
have an intuitive name, so people can easily say " ... ok, so this file is
for declare how to handle the resources ...". Inclusive, we can provide
an schema for that file and put it into myfaces site, so xml tools can
fetch them automatically. This can't be done with the other alternative.
2. Programming this option is easier to do. The conditions to locate
faces-config.xml files are very complex. In this case, use these two locations:
META-INF/myfaces-resources-config.xml (for jar files)
WEB-INF/myfaces-resources-config.xml (for war files)
And a web config param is enough.
>
>> - Make it work with suffix mapping.
> This was never the plan of this resource-handler, because it breaks
> the ability of having relative-resources (CSS files referencing image
> without using #{resource['']}). Thus this should not be implemented
> --> specific libraries require specific configurations and as it
> happens this resource-handler needs prefix mapping to be configured.
> However, you can still use suffix mapping for your xhtml views (prefix
> mapping will only be used for the resources in this case).
>
I think the right thing to do is just parse the file, and replace the required
urls if suffix mapping is used. We can parse the .css and save the result
on a temporal parsed file on the server to render it later. Trinidad
generate different css files per agent for its own skins, so a safe bet is
check that code and just take what we need here. Find a parser for CSS
is not difficult (apache batik?).
> The other stuff...
>
>> - Relocate resources and replace library names. For example, if my
>> custom component uses prototype library and I have to use other jsf
>> component library that loads prototype.js with its custom library
>> name, allow the custom one uses the file from the jsf library, or
>> viceversa.
>> - Use content delivery network (CDN) to load known javascript or other
>> resource files like jQuery or prototype.
>> - Add a SPI interface to delegate .xml resource scanning.
>
> ...looks very promising!
Great!
regards,
Leonardo
>
> Regards,
> Jakob
>
> 2011/5/17 Leonardo Uribe <[email protected]>:
>> Hi
>>
>> This stuff looks very promising. I think we can additionally implement
>> the following ideas:
>>
>> - Relocate resources and replace library names. For example, if my
>> custom component uses prototype library and I have to use other jsf
>> component library that loads prototype.js with its custom library
>> name, allow the custom one uses the file from the jsf library, or
>> viceversa.
>> - Use content delivery network (CDN) to load known javascript or other
>> resource files like jQuery or prototype.
>> - Add a SPI interface to delegate .xml resource scanning.
>> - Resource caching (just like myfaces core does!).
>> - Find a better name for advanced-resources.xml. It is ok, but I'll
>> prefer a more intuitive name, like myfaces-resources-config.xml or
>> something like that, so people can understand easily which one is the
>> intention of this config file. Maybe some renaming of the classes
>> could be helpful (if we find a better name).
>> - Make it work with suffix mapping.
>>
>> That is not very hard to do, but it is a valuable contribution to do.
>> Suggestions are welcome.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/3/8 Jakob Korherr <[email protected]>:
>>> Hi,
>>>
>>> I just committed the code, see r1079447.
>>>
>>> In addition, I created the following issue for reference in the jira:
>>> MFCOMMONS-29.
>>>
>>> Feel free to look at it, use it, change it,... - input is always welcome :)
>>>
>>> Regards,
>>> Jakob
>>>
>>> 2011/2/23 Jakob Korherr <[email protected]>:
>>>> Hi guys,
>>>>
>>>> I developed a custom JSF 2 ResourceHandler for one of my current
>>>> projects and I want to "donate" it to MyFaces commons (JSF 2 branch).
>>>>
>>>> The features of this ResourceHandler include the following:
>>>> - 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).
>>>>
>>>> In addition, it does NOT support ValueExpressions in resource files
>>>> for performance reasons.
>>>>
>>>> The most important feature, in my opinion, is how the resource URL is
>>>> built, e.g.
>>>> /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css
>>>>
>>>> ... because it permits resources referencing other resources without
>>>> #{resource['...']} (e.g. css files referencing images or other css
>>>> files). With the standard ResourceHandler this is 1) annoying if you
>>>> have to change the files you get from your designer and 2) a
>>>> performance bottleneck, because resources with ValueExpressions are
>>>> not cached and also regenerated for each request.
>>>>
>>>> Furthermore, the resource URL contains the locale and thus you have no
>>>> problems with cached resources if a users changes the locale, because
>>>> he/she will get a new URL and thus a new resource (the right one).
>>>>
>>>> I'd like to commit the code as a new module on the JSF 2 branch of
>>>> MyFaces commons. Are there any objections?
>>>>
>>>> Regards,
>>>> Jakob
>>>>
>>>> --
>>>> Jakob Korherr
>>>>
>>>> blog: http://www.jakobk.com
>>>> twitter: http://twitter.com/jakobkorherr
>>>> work: http://www.irian.at
>>>>
>>>
>>>
>>>
>>> --
>>> Jakob Korherr
>>>
>>> blog: http://www.jakobk.com
>>> twitter: http://twitter.com/jakobkorherr
>>> work: http://www.irian.at
>>>
>>
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>
