Ok. Basic problem is what to do if I need to return content to the user (such as a generated image) as a result of my action.
At the moment the target valve always attempts to set the content type and then render the response. If I have already opened the response writer in my action, the target valve will throw an exception when it tries to set the content type (this is part of the J2EE spec I believe). One work around is the echo template described by James. This is a bit of a nasty hack IMHO. Second idea is to disable to the target completely, so no rendering would take place. This could be achieved by setting the target to null and then having the valve check handle this gracefully. As Jason has said this doesn't really fit the design, but does give lots of flexibility about how the response is generated. Third idea is to generate the data in the action. Store it somewhere in the rundata, (perhaps responseBody object) and then retrieve the data at the point of rendering within the target valve. This is going to be a common problem as far as I can see. In our case we want to return a PDF (actually an FDF with an internal PDF hyperlink) as the result of a form fill. So I need to use the action to parse the form data and generate the FDF. When I actually write it onto the output stream is obviously the point here. So any input would be much appreciated! > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED]] > Sent: 01 February 2002 13:31 > To: Turbine Developers List > Subject: Re: Possible patch to allow files to be streamed back from > action > > > On 2/1/02 8:17 AM, "James Taylor" <[EMAIL PROTECTED]> wrote: > > > Ugh, buffering. > > > > So your goal is to have an Action or Module be able to write the output? > > How about this: > > IMO, this is a very bad idea. Actions should be considered operations on > your application/domain/object model and Modules be consider a > conduit from > that model to your view. > > I've been in NYC and I missed the beginning of the conversation, what is > your use case? > > I believe the output of content to the browser should be limited to > templates and renderers. Having that behaviour creep into actions and > modules will eventually lead to problems if you ask me. > > > > > The action or module goes ahead and writes the output however it wishes > > using data.getOut(), and then sets the target to null, indicating that > > no further modules or targets are to be executed. This should be safe > > since the target is always set to a known good value by > > DetermineTargetValve, either the normalized target or the homepage. > > > > RunModulesValve, DefaultTargetValve, and DirectTargetValve get trivial > > modifications to become noops if no target is set. > > > > Same result, more pipeline friendly behavior, and no buffering. Does > > that meet your needs? > > > > Another option which requires no modification to turbine is for you to > > write your output on your module/action to a context variable, and then > > set the target to be something like "Echo.vm" which has no modules and > > whose body is: > > > > $echoContent > > > > Or something. But I expect you want more control over the content type > > and such. > > > > One possible idea I don't like is to have a special pipeline for those > > requests that require this behavior, and leave the target valve out of > > it. I don't like that idea since you probably don't know until you > > process the action whether you want to use a target or not. > > > > Peace, jt > > > > On Fri, 2002-02-01 at 05:09, Gareth Coltman wrote: > >> The best patch I can think of is as follows: > >> > >> 1. Change RunData to include a responseBody object. This would > probably be a > >> byte array so it could handle both text and binary data. > >> > >> 2. Add a call in the execute method of the DefaultTargetValue > to check if > >> the responseBody has already been set. If not the normal > rendering process > >> should take place. If it does contain data, it should be > buffered back to > >> the output stream, and any other targets ignored. > >> > >> ie: > >> > >> protected void execute(RunData data) > >> throws Exception > >> { > >> data.getResponse().setLocale(data.getLocale()); > >> data.getResponse().setContentType(data.getContentType()); > >> > >> if(data.getResponseBody() != null) > >> { > >> > >> runner.run(targetModuleType, data); > >> > >> String target = data.getTarget(); > >> > >> Renderer r = new DirectRenderer(data.getOut()); > >> TemplateContext context = Module.getTemplateContext(data); > >> context.put("renderer", r); > >> context.put("template", target); > >> context.put("runner", runner); > >> > >> // now we can use the renderer here > >> // use the renderer to start the whole shabang > >> String layoutTemplate = Turbine.getResolver() > >> .getTemplate("layouts", target); > >> String out = r.render(data, layoutTemplate); > >> if (out != null && out.length() > 0) > >> { > >> // Write the response directly to the output stream. > >> data.getOut().print(out); > >> } > >> } > >> else > >> // BUFFER THE getReponseBody byte[] ONTO THE OUTPUT STREAM > >> } > >> } > >> > >> ??? > >> > >> Any ideas? > >> > >> > >> -- > >> To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > >> For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > >> > >> > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > > jvz. > > Jason van Zyl > > http://tambora.zenplex.org > http://jakarta.apache.org/turbine > http://jakarta.apache.org/velocity > http://jakarta.apache.org/alexandria > http://jakarta.apache.org/commons > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
