Ken Paulsen wrote:
>
> Ryan,
>
> Is there any reason that you put this in the renderView() method of
> the viewHandler as opposed to the createView() method? I believe all
> requests for images will end up going through createView(), not
> restoreView()... this gets called earlier, and will not get called for
> "post-back" type requests (so you won't have to waste time checking
> the mimetype for those requests).
I'll need to revisit - there was a reason that I did it that way, but I
can't recall at the moment.
>
> Also, while this helps serve images... it doesn't do anything for
> .pdfs or any other "resources" that might be referenced from a jsf
> page. It will also interfere with anyone that chooses a page name in
> an extension that maps to an image mime type. While this isn't
> extremely likely it is more restrictive... perhaps you want to
> explicitly specify which image types are supported by this (vs.
> letting the container decide).
You're right it doesn't support all binary formats. My main concern was
lessening the
impact of relative URIs with graphicImage.
>
> I agree this is an improvement... but it's an improvement on an error
> condition. The user specified the relative URL incorrectly.
I wouldn't say it's a user error. This worked fine in 1.1 due to how
the view handling worked in 1.1.
Since we buffer and post process in 1.2, it was an unexpected change in
behavior (reported by two
internal groups within sun). There is nothing in the spec that says you
shouldn't use relative URIs.
> There are api's in JSF to obtain the correct URL. Components should
> make use of these to do this automatically. Users should use
> components to do this. Or... use extension mapping which doesn't have
> this problem.
Right, but it may be difficult to move to extension mapping (in the
tools case where all projects are generated
using prefix mapping).
>
>
> Ken
>
>
> Jason Lee wrote:
>> r=jdlee
>>
>> -----
>> Jason Lee, SCJP
>> Programmer/Analyst
>> http://www.iec-okc.com
>>
>>
>>
>>> -----Original Message-----
>>> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
>>> Sent: Monday, October 16, 2006 3:27 PM
>>> To: dev_at_javaserverfaces.dev.java.net
>>> Subject: [REVIEW - PART 2] Avoid full lifecycle processing
>>> for images when using prefix mapping
>>>
>>> I've attached a follow up change bundle to this issue.
>>> It turns out that the PhaseListener approach isn't going to
>>> work (causes issues with Shale). I've instead moved the PL
>>> logic into ViewHandlerImpl.renderView().
>>>
>>>
>>>
>>> Ryan Lubke wrote:
>>>
>>>> Avoid full lifecycle processing with the FacesServlet is
>>>>
>>> prefix mapped
>>>
>>>> and images are defined using relative URIs.
>>>>
>>>>
>>>> SECTION: Modified Files
>>>> ----------------------------
>>>> M src/com/sun/faces/jsf-ri-config.xml
>>>>
>>>> A src/com/sun/faces/lifecycle/ImagePhaseListener.jav
>>>>
>>>>
>>>> SECTION: Diffs
>>>> ----------------------------
>>>> Index: src/com/sun/faces/jsf-ri-config.xml
>>>> ===================================================================
>>>> RCS file:
>>>>
>>>>
>>> /cvs/javaserverfaces-sources/jsf-ri/src/com/sun/faces/jsf-ri-config.xm
>>>
>>>> l,v
>>>> retrieving revision 1.69
>>>> diff -u -r1.69 jsf-ri-config.xml
>>>> --- src/com/sun/faces/jsf-ri-config.xml 11 May 2006 18:48:03
>>>> -0000 1.69
>>>> +++ src/com/sun/faces/jsf-ri-config.xml 11 Oct 2006
>>>>
>>> 00:55:38 -0000
>>>
>>>> @@ -167,9 +167,10 @@
>>>>
>>>>
>>> <converter-class>javax.faces.convert.EnumConverter</converter-class>
>>>
>>>> </converter>
>>>> - <!-- Add our InitializingPhaseListener -->
>>>> + <!-- Add our implementation specific PhaseListeners -->
>>>> <lifecycle>
>>>>
>>>>
>>>>
>>> <phase-listener>com.sun.faces.lifecycle.ELResolverInitPhaseListener</p
>>>
>>>> hase-listener>
>>>>
>>>> +
>>>>
>>>>
>>> <phase-listener>com.sun.faces.lifecycle.ImagePhaseListener</phase-list
>>>
>>>> ener>
>>>>
>>>> </lifecycle>
>>>>
>>>> <!-- Configure Standard Validators -->
>>>>
>>>>
>>>> SECTION: New Files
>>>> ----------------------------
>>>> SEE ATTACHMENTS
>>>>
>>>>
>>> ----------------------------------------------------------------------
>>>
>>>> --
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>>> For additional commands, e-mail:
>>>>
>>> dev-help_at_javaserverfaces.dev.java.net
>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>