sample implementation and test case

And as a addition to that, it would be really useful, if the xhtmlrenderer from The Flying Saucer Project (https://xhtmlrenderer.dev.java.net/) could be used. As icefaces builds up a DOM already, you could use this renderer to render this DOM to a pdf and output the pdf!

org.w3c.dom.Document xhtmlContent = ...;
ITextRenderer renderer = new ITextRenderer();
Renderer.setDocument(xhtmlContent,"");
renderer.layout();
response.setContentType("application/pdf");
OutputStream browserStream = response.getOutputStream();
renderer.createPDF(browserStream);
return;

So one could offer a link which return the current page as a PDF document.

An additional attribute 'filename' that sets the Content-Disposition HTTP header would also be nice.

Recommend that we include this component in 1.7.2.

The Resource interface should be extended as follows:

String getFilename()
Date getExpires()

ResourceDispatcher would be modified so that

if getFilename() does not return null, set Content-Disposition header to "attachment; filename=" getFilename();
if getExpires() returns null, use monitor.expiresBy() else use getExpires() value

Optional:

If mimetype is specified in the component attribute, provide this in the rendered link.

Extend Resource via:
String getMimetype()

ResourceDispatcher would be modified so that

if getMimetype() does not return null, set Content-Type header to getMimetype() otherwise use the mime-type passed at registration. Pass null for mimetype during registration for resources whose mimetype is not defined at that time.

Mircea, please review the suggested changes for the Resource and ResourceDispatcher.

outputResource should also take an image value and, if present, render an anchor tag around the specified image:

<ice:outputResource image="#

" >

Optional:

outputResource should also take a type value:

<ice:outputResource type="button" > or
<ice:outputResource type="link" > or

Ted,
In order to provide all these features in ResourceRegistry API I feel that I need to change it bit so that it can adapt elegantly to all of resource downloading requirements. I really don't want to have a mangled API that all users will be forced to learn and then later, when we want to clean it up, unlearn. I can create a patch with the changes before checking it in.

Another nice thing would be "parametrized resources" meaning that you have the possibility to add a parameter to the resource URI and that parameter would be given to the Resource. The resource could then return different data depending on the provided parameter.

A possible use could be graphical text images. If you have to display graphics with different texts you don't want to draw all possible images in a graphics program, but rather draw them dynamically using java 2D. The text to be displayed would be the resource parameter.

Since there's been a few iterations of requirements please attacha mockup of what the final component TLD would look like for review (attached to this JIRA) prior to commencing development.

It would be very important, that it is possible to show the file in a new window (e.g. by target="_blank"), because in many cases the application window shall still be visible, even when the file (e.g. a pdf-file or xls-File) is shown.

Added patch with enhanced ResourceRegistry API.

Add patched version of the sample app.

Philip,

Please have a look at the modified sample application to see if the implemented features in the patch are fulfilling your/client's requirements.

The things I have added for the "parametrized resource":

public class ResourceDispatcher implements Server {

private static final String PARAMETER_NAME = "param";

private static final String PARAMETER_ENCODING = "UTF-8";

public URI getParametrizedResourceURI(URI resourceURI, String parameter) {
try

catch (UnsupportedEncodingException e)

}

private class ResourceServer implements Server, ResponseHandler {
private ResponseHandler notModified = new ResponseHandler() {

private String parameter;

public void service(Request request) throws Exception {
parameter = request.getParameter("param", null);
if (parameter != null)

...
}

public void respond(Response response) throws Exception

}

public interface Resource

public interface ResourceRegistry

public class BridgeFacesContext extends FacesContext implements ResourceRegistry {
public URI getParametrizedResourceURI(URI resourceURI, String parameter)

}

Updated OuputResource component to use ICE-2348.patch. Resources now load as attachments with the browser 'save as...run as ..' support. Works well in IE, but in Firefox the bridge is disposed once the link is clicked.

Mircea, is it possible for the ResourceDispatcher to still support registering named resources that are not FileResources? I can see people wanting control over naming even if they're not using FileResources, say, serving a ByteArray for dynamically generated streams that should appear to the user as a normal named file.

above mentioned issue with the bridge being disposed in Firefox when content-disposition and attachment are set have also been reported on the forum when using a custom servlet (http://www.icefaces.org/JForum/posts/list/8909.page#37232).

Mircea, please see last 3 comments

1) The renderer needs to render a target="blank" attribute on the anchor so that the browser doesn't navigate to the download URL. Check out modified renderer I sent.

2) Yes, you can set a file name any resources. The FileResource is just one of the possible implementations. You can extend ByteArrayResource and setFileName on the Resource.Options callback.

3) Same as in 1).

added target blank for the link, and Ted's suggestions for image and type button support

only parameterized resources haven't been implemented yet. Should create a new jira for that. IE 6 does not seem to respect the filename specified in content-disposition header and will attempt to save the file with its encoded name

Parameterized resources can be easily created with the current API. Just implement the Resource interface and pass any needed parameters in the constructor of the implementing class.

You are right Mircea, parametrized resources are feasible with the current API.
One thing that could be a problem is performance when there are lots of registered resources.
The dispatch from a URL to a resource is done through an iterator of all registered resources. That could take relatively long.

The dispatching and iteration is infinitesimal compared to the time required for the HTTP connections and the corresponding transfers.
What you are asking is pretty much what a Servlet does, generate dynamic content based on some input values read from the HTTP request. Is there a reason why you cannot use a Servlet for what you need?!

Sure I could write a servlet, but it's easier to use a higher level API.
I think this component is ok for our purposes.

Applied ResourceRegistry API changes to fulfill the requirements needed by OutputResource component.

Restored old methods for backwards compatibility. Adapted their implementation to use current API. Marked them as deprecated.

It's better if this component can support CSS. For example, applying the default ICEfaces style classes for button and link types.

I looked at OutputResourceRender.java and I noticed that in link case the target "blank" is used.
Is target "blank" necessary for ICEFaces working properly after file download?
I suppose that target blank was added because without it, after file downloading ICEFaces page does not work any more, is it right?

Mircea Toma noted that 'The renderer needs to render a target="blank" attribute..." I'm new to ICEfaces, but this seems strikingly similar to the reserved [link] target attribute value of "_blank", which has the following special meaning: "The user agent should load the designated document in a new, unnamed window." (http://www.w3.org/TR/html401/types.html#type-frame-target). Should this have been made "_blank" instead of "blank"?

hello!

i think there is still a bug in the OutputResourceComponent when using EL for the fileName attribute. i basically downloaded the .war file attached to this case, and added a few lines so it should be easily reproducible:

in OutputResourceBean.java:

public String getDynamicFileName()

and in outputResource.jspx:

<cust:outputResource id="otherPdf"
resource="#

"
mimeType="application/pdf"
value="Click to load pdf with dynamic filename"
fileName="#

"
/>

after clicking on "Click to load pdf with dynamic filename" the app dies with the following stack trace:

StandardWrapperValve[Blocking Servlet]: PWC1406: Servlet.service() for servlet Blocking Servlet threw exception
java.lang.NullPointerException: FacesContext -> null
at javax.faces.component.ValueBindingValueExpressionAdapter.getValue(ValueBindingValueExpressionAdapter.java:98)
at com.icesoft.faces.component.outputResource.OutputResource.getFileName(OutputResource.java:84)
at com.icesoft.faces.component.outputResource.OutputResource$1.withOptions(OutputResource.java:46)
at com.icesoft.faces.webapp.http.core.ResourceDispatcher$ResourceServer.respond(ResourceDispatcher.java:120)
at com.icesoft.faces.webapp.http.common.standard.CompressingServer$CompressingRequest$1.respond(CompressingServer.java:49)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.respondWith(ServletRequestResponse.java:161)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.respondWith(ThreadBlockingAdaptingServlet.java:36)
at com.icesoft.faces.webapp.http.common.standard.CompressingServer$CompressingRequest.respondWith(CompressingServer.java:45)
at com.icesoft.faces.webapp.http.core.ResourceDispatcher$ResourceServer.service(ResourceDispatcher.java:115)
at com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer$Matcher.serviceOnMatch(PathDispatcherServer.java:50)
at com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer.service(PathDispatcherServer.java:19)
at com.icesoft.faces.webapp.http.common.standard.CompressingServer.service(CompressingServer.java:29)
at com.icesoft.faces.webapp.http.core.ResourceDispatcher.service(ResourceDispatcher.java:39)
at com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer$Matcher.serviceOnMatch(PathDispatcherServer.java:50)
at com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer.service(PathDispatcherServer.java:19)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet.service(ThreadBlockingAdaptingServlet.java:19)
at com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java:63)
at com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:151)
at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:54)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service(BlockingServlet.java:46)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)

i will attached my .war file after this message.
my environment is netbeans 6.5, icefaces from svn (29.09.2008), glassfish2 that was bundled with netbeans.

best regards, armin walland

slightly modified version of the OutputResourceComponent-demoapp to illustrate exception when using EL in "fileName" attribute.

Re-opened. Looks like we forgot to commit some files for this that are required, and QA didn't get the tests so it didn't fail... (oops).

Let's make this right for 1.7.2 final.

checked into 1.7 branch and head