Hi Leonardo,
Am 16.01.2013 um 21:47 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
> Hi Frank
>
> 2013/1/16 Frank Caputo <frank_at_frankcaputo.de>:
>> Hi Leonardo,
>>
>> Am 15.01.2013 um 20:37 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
>>
>>> Thinking about this, I think a good idea could be add a method to
>>> Resource interface to get the last modified time.
>>>
>>> public Long getLastModified()
>>>
>>> return null if no lastModified time can be returned.
>>
>> This method would be really helpful, but I wouldn't allow null to be returned, so I'd use the primitive long as return value.
>>
>
> Ok. good to know that. The idea of the null is to know when there is
> no lastModified time, but maybe a -1 is better.
>
>> There will be an issue with decorating existing resources and overwriting only getLastModified. userAgentNeedsUpdate and getResponseHeaders won't call the decorated version of getLastModified. So on decorated resources all 3 methods must be implemented, which is not very comfortable.
>>
>
> The same hypotethical issue exists between userAgentNeedsUpdate and
> getResponseHeaders too, but the important consideration is how often
> is required to modify the last modified time? For "static" resources
> it will be always the same value, so the wrapper will not modify them.
> For resources that needs to be generated once (css + inner EL
> expressions), the same consideration applies (will not be modified).
> Resource instances like the one required by a captcha component (an
> image that is generated in a unique way per session), will have
> different implementations in those methods (usually getResponseHeaders
> return null userAgentNeedsUpdate return true and getLastModified
> return 0 or -1).
>
> In conclusion, in my opinion we shouldn't worry about that detail,
> because once these methods are defined, by the "nature" of the
> underlying Resource those implementations does not change.
+1
>
>> Ciao Frank
>>
>>> 2013/1/15 Frank Caputo <frank_at_frankcaputo.de>:
>>>> Hi Leonardo,
>>>>
>>>> I recently provided a patch for Mojarra to solve this problem, which Manfred merged into the trunk ( http://java.net/projects/mojarra/sources/svn/diff/trunk/jsf-ri/src/main/java/com/sun/faces/facelets/impl/DefaultFacelet.java?rev1=11384&rev2=11385 ).
>>
>> Does this answer obsolete your older comments on resource library contracts?
>>
>
> No. I think use the alias for the calculation is not the right way to
> do it, because the alias has another different meaning. For example,
> in MyFaces the alias is prefixed according if is a facelet, view
> metadata facelet or a composite component facelet. If I remember well,
> the alias was used in the id generation, but I changed that part in
> MyFaces with a better concept ( faceletId ). So, in MyFaces at the end
> the "alias" is used only as debug information.
So it seems, that this is an implementation detail and not a spec problem.
>
> In this case, DefaultFacelet must be modified to store the contextual
> library / resource and use that information to derive a relative
> resource. Suppose a composite component located in
> META-INF/resources/my.composite.component/simplecc.xhtml . It there is
> a reference to
>
> <ui:include src="dir1/resource.xhtml"/>
>
> The resource should be located in:
>
> libraryName: my.composite.component
> resourceName: dir1/resource.xhtml
>
> Going back to the base example, if there is a file under
> /templates/b.xhtml with a reference to:
>
> <ui:decorate template="dir2/mytemplate2.xhml">
>
> The resource should be located in:
>
> libraryName: N/A
> resourceName: /templates/dir2/mytemplate2.xhtml
>
> Note if there is a resource in
> META-INF/resources/templates/dir2/mytemplate2.xhtml, the resource
> should not be taken into account (or maybe yes), because what we want
> is resolve the resource in a relative way.
I think it should be taken into account. Since we are using the resource handler to load facelets, they are resources.
> The resolution process
> inside a composite component is different than the resolution from a
> template, but if the call is located inside a template called from a
> composite component, it is relative to the composite component
> library.
Should we enforce absolute references for that corner case?
>
> Really this part is still open to interpretation, and it is clear we
> need to get to an agreement about how this should work.
Absolutely.
Ciao Frank
>
> regards,
>
> Leonardo Uribe
>
>> Ciao Frank
>>
>>>>
>>>> I'll answer more detailed tomorrow.
>>>>
>>>> Ciao Frank
>>>>
>>>> Am 15.01.2013 um 00:32 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
>>>>
>>>>> Right now, facelets derive the path using a call to:
>>>>>
>>>>> new URL(from, path)
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>