[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

  • From: Frank Caputo <frank@...>
  • To: jsr344-experts@...
  • Subject: [jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues
  • Date: Sun, 20 Jan 2013 16:37:41 +0100
  • List-id: <jsr344-experts.javaserverfaces-spec-public.java.net>

Hi Leonardo,

Am 16.01.2013 um 21:47 schrieb Leonardo Uribe <lu4242@...>:

> Hi Frank
> 
> 2013/1/16 Frank Caputo <frank@...>:
>> Hi Leonardo,
>
>> Am 15.01.2013 um 20:37 schrieb Leonardo Uribe <lu4242@...>:
>
>>> 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@...>:
>>>> 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@...>:
>>>> 
>>>>> Right now, facelets derive the path using a call to:
>>>>> 
>>>>> new URL(from, path)
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>
>
>
>
>
> 



[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

(continued)

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Leonardo Uribe 01/14/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Frank Caputo 01/15/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Leonardo Uribe 01/15/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Frank Caputo 01/16/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Leonardo Uribe 01/16/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Leonardo Uribe 01/17/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Frank Caputo 01/20/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Leonardo Uribe 01/20/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Frank Caputo 01/23/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Leonardo Uribe 01/24/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Frank Caputo 01/20/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Edward Burns 01/16/2013

[jsr344-experts mirror] [jsr344-experts] Re: PRD Review and pending issues

Edward Burns 01/31/2013

[jsr344-experts mirror] [jsr344-experts] Flow and Loading Facelets via ResourceHandler (Re: was: PRD Review and pending issues)

Edward Burns 01/31/2013
Terms of Use; Privacy Policy; Copyright ©2013-2015 (revision 20150226.965aeb8)
 
 
Close
loading
Please Confirm
Close