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]>
