You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Gareth Coltman <ga...@majorband.co.uk> on 2002/02/01 11:09:23 UTC
Possible patch to allow files to be streamed back from action
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/11/02 1:30 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@zenplex.com> writes:
>
>> It's good that you actually discussed the idea with James, but the reason I
>> prodded was more of a policy issue. Are we all to practice the philosophy of
>> preventing documentation being issued on methodologies we don't agree with?
>>
>> What one person views as a best practice is often not entirely congruent
>> with what another views as a best practice.
>>
>> I'm an ardent believer that actions, and flow in general, should not be
>> accessible from templates but it's a practice that exists and a methodology
>> that certainly is documented. You tried to provide a alternative to James'
>> first proposal whereas I haven't provided an alternative to the control flow
>> in templates but when I have do you think it would be a fair position for me
>> to try and prevent $link.setAction(x) from showing up in the documentation?
>>
>> I certainly think that would be a bit heavy handed.
>>
>> If someone wants to put immense quantities of logic in their templates, or
>> someone wants put logical indicators in their pipeline descriptors then so
>> be it. If they want to document it and people use it to get a job done how
>> can documentation hurt? And how would preventing documentation on a
>> particular methodology, even if highly disliked by certain parties, help
>> anyone?
>
> You make good points. I wouldn't be adverse to documentation and
> publish of controversial material so large as it wasn't positioned by
> the rest of the documentation as the One True Way -- because as you
> point out, the way is different for everyone.
That's exactly my point. Precluding methodologies based on personal opinion
seems rather arbitrary and, really, in Turbine there has never been any One
True Way to do anything. Not yet anyway.
>
> Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> It's good that you actually discussed the idea with James, but the reason I
> prodded was more of a policy issue. Are we all to practice the philosophy of
> preventing documentation being issued on methodologies we don't agree with?
>
> What one person views as a best practice is often not entirely congruent
> with what another views as a best practice.
>
> I'm an ardent believer that actions, and flow in general, should not be
> accessible from templates but it's a practice that exists and a methodology
> that certainly is documented. You tried to provide a alternative to James'
> first proposal whereas I haven't provided an alternative to the control flow
> in templates but when I have do you think it would be a fair position for me
> to try and prevent $link.setAction(x) from showing up in the documentation?
>
> I certainly think that would be a bit heavy handed.
>
> If someone wants to put immense quantities of logic in their templates, or
> someone wants put logical indicators in their pipeline descriptors then so
> be it. If they want to document it and people use it to get a job done how
> can documentation hurt? And how would preventing documentation on a
> particular methodology, even if highly disliked by certain parties, help
> anyone?
You make good points. I wouldn't be adverse to documentation and
publish of controversial material so large as it wasn't positioned by
the rest of the documentation as the One True Way -- because as you
point out, the way is different for everyone.
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/11/02 4:57 AM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@zenplex.com> writes:
>
>> On 2/9/02 1:49 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>>
>>> First off, let me say that I am not against the idea of a "selector"
>>> for multiple pipelines. It's just the suggested implementation that I
>>> have issues with.
>>>
>>> Even though I don't think that even optional pipeline capabilities
>>> should be programmable from XML, I will not -1 its inclusion (on an
>>> optional basis). However, I will not support promotion of such
>>> facilities in the Turbine documentation
>>
>> What does that mean exactly? You won't write documentation yourself
>> promoting this method, or that you will prevent someone else from doing it.
>>> From the tone it sounds like the latter.
>
> The latter. But after talking with James on IRC, it looks like our
> ideas are actually much closer than I had first thought, so much so
> that I was able to take his base Valve and easily subclass it from my
> branch point suggestion.
It's good that you actually discussed the idea with James, but the reason I
prodded was more of a policy issue. Are we all to practice the philosophy of
preventing documentation being issued on methodologies we don't agree with?
What one person views as a best practice is often not entirely congruent
with what another views as a best practice.
I'm an ardent believer that actions, and flow in general, should not be
accessible from templates but it's a practice that exists and a methodology
that certainly is documented. You tried to provide a alternative to James'
first proposal whereas I haven't provided an alternative to the control flow
in templates but when I have do you think it would be a fair position for me
to try and prevent $link.setAction(x) from showing up in the documentation?
I certainly think that would be a bit heavy handed.
If someone wants to put immense quantities of logic in their templates, or
someone wants put logical indicators in their pipeline descriptors then so
be it. If they want to document it and people use it to get a job done how
can documentation hurt? And how would preventing documentation on a
particular methodology, even if highly disliked by certain parties, help
anyone?
> Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> On 2/9/02 1:49 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
>> First off, let me say that I am not against the idea of a "selector"
>> for multiple pipelines. It's just the suggested implementation that I
>> have issues with.
>>
>> Even though I don't think that even optional pipeline capabilities
>> should be programmable from XML, I will not -1 its inclusion (on an
>> optional basis). However, I will not support promotion of such
>> facilities in the Turbine documentation
>
> What does that mean exactly? You won't write documentation yourself
> promoting this method, or that you will prevent someone else from doing it.
> >From the tone it sounds like the latter.
The latter. But after talking with James on IRC, it looks like our
ideas are actually much closer than I had first thought, so much so
that I was able to take his base Valve and easily subclass it from my
branch point suggestion.
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/9/02 1:49 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> First off, let me say that I am not against the idea of a "selector"
> for multiple pipelines. It's just the suggested implementation that I
> have issues with.
>
> Even though I don't think that even optional pipeline capabilities
> should be programmable from XML, I will not -1 its inclusion (on an
> optional basis). However, I will not support promotion of such
> facilities in the Turbine documentation
What does that mean exactly? You won't write documentation yourself
promoting this method, or that you will prevent someone else from doing it.
>From the tone it sounds like the latter.
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> On 2/7/02 9:53 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
>> James Taylor <jt...@4lane.com> writes:
>>
>>> Consider:
>>>
>>> <pipeline>
>>> <name>TurbineClassicPipeline</name>
>>> <valves>
>>> <valve className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
>>> <valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
>>> <select
>>> className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
>>> <when test="vm">
>>> <valve
>>> className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
>>> </when>
>>> <when test="jsp">
>>> <valve className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
>>> </when>
>>> <when test="swt">
>>> <valve className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
>>> </when>
>>> </select>
>>> </valves>
>>> </pipeline>
>>
>> I need to read this more thoroughly, but after a first pass, I am
>> strongly -1 on this change. No programming in XML. Period.
>
> I was chatting with James about this and I don't feel this would be the
> standard pipeline that we ship but what's above is completely optional and
> provides one form of a selector mechanism. What's there is just another
> valve.
>
> Again, I'm not that keen on this being the default but we will need a
> selector mechanism and this is just one option. All the logic is contained
> in a valve and doesn't hurt anything else.
First off, let me say that I am not against the idea of a "selector"
for multiple pipelines. It's just the suggested implementation that I
have issues with.
XML is a data markup language (see point of of the W3C's XML FAQ at
http://www.w3.org/XML/1999/XML-in-10-points), not a programming
language -- trying to do any sort of programming in XML is a Bad Idea
(I would use Ant as an example of how bad an idea this is, but I have
a feeling that some of you would actually use Ant as a templar
supporting this insanity ;-P ).
Even though I don't think that even optional pipeline capabilities
should be programmable from XML, I will not -1 its inclusion (on an
optional basis). However, I will not support promotion of such
facilities in the Turbine documentation, as it is most definitely not
a best practice.
Java is for programming, and Valves are for Pipeline control. The
Right Way of handling pipeline selection is to implement a Valve which
encapsulates your selection rules, and configure any inputs to this
selector mechanism via your XML descriptor. This keeps flow control
out of the XML (where it doesn't belong), and in the Java code (which
is best suited to dealing with such things). I've attached just such
a selector mechanism, the BranchPoint class (a Valve implementation),
which I propose is used to solve this problem. Just attach a
BranchPoint subclass (which implements the chooseBranch() method) near
the beginning of your pipeline, and you'll have support for multiple
pipelines.
It all comes down to using the right tool for the job.
Comments and criticisms welcome.
Thanks, Dan
package org.apache.turbine.pipeline;
/* ====================================================================
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The end-user documentation included with the redistribution,
* if any, must include the following acknowledgment:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowledgment may appear in the software itself,
* if and wherever such third-party acknowledgments normally appear.
*
* 4. The names "Apache" and "Apache Software Foundation" and
* "Apache Turbine" must not be used to endorse or promote products
* derived from this software without prior written permission. For
* written permission, please contact apache@apache.org.
*
* 5. Products derived from this software may not be called "Apache",
* "Apache Turbine", nor may "Apache" appear in their name, without
* prior written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* ====================================================================
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*/
import java.io.IOException;
import org.apache.turbine.RunData;
import org.apache.turbine.TurbineException;
import org.apache.turbine.Valve;
import org.apache.turbine.ValveContext;
/**
* A {@link org.apache.turbine.Valve} description of a pipeline's
* branch point. May itself be the start of zero or more {@link
* org.apache.turbine.Pipeline} paths.
*
* @author <a href="mailto:dlr@finemaltcoding.com">Daniel Rall</a>
* @version $Id: DefaultActionValve.java,v 1.7 2002/01/24 03:55:26 jvanzyl Exp $
*/
public abstract class BranchPoint
extends AbstractValve
{
/**
* Calls <code>chooseBranch()</code> to pick a pipeline path.
*
* @see #chooseBranch(RunData, ValveContext)
* @see org.apache.turbine.Valve#invoke(RunData, ValveContext)
*/
public void invoke(RunData data, ValveContext context)
throws IOException, TurbineException
{
try
{
chooseBranch(data, context);
}
catch (Exception e)
{
throw new TurbineException(e);
}
}
/**
* <p>Selects which pipeline path to branch down. This may just
* consist of calling <code>context.invokeNext(data)</code> to
* continue down the current pipeline's path. The desired branch
* path is generally determined using data pulled from the
* supplied<code>RunData</code>.</p>
*
* <p>Here's an illustration of inserting a
* <code>BranchPoint</code> into the <code>TurbinePipeline</code>
* processing sequence:
*
* <blockquote><pre>
* ___ (start of FooPipeline)
* /
* ---[Valve]--[Valve]--[BranchPoint]---- (continue w/ TurbinePipeline)
* \
* --- (start of BarPipeline)
* </pre></blockquote>
*
* The <code>BranchPoint</code> could just as easily stop all
* processing by neither invoking a new pipeline nor calling
* <code>invokeNext()</code>.
* </p>
*
* @param data The run-time data.
* @exception Exception Problem choosing pipline to branch down.
*/
protected abstract void chooseBranch(RunData data, ValveContext context)
throws Exception;
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline (was Re: Possible patch to
allow files to be streamed back from action)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/7/02 9:53 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> James Taylor <jt...@4lane.com> writes:
>
>> Consider:
>>
>> <pipeline>
>> <name>TurbineClassicPipeline</name>
>> <valves>
>> <valve className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
>> <valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
>> <select
>> className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
>> <when test="vm">
>> <valve
>> className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
>> </when>
>> <when test="jsp">
>> <valve className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
>> </when>
>> <when test="swt">
>> <valve className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
>> </when>
>> </select>
>> </valves>
>> </pipeline>
>
> I need to read this more thoroughly, but after a first pass, I am
> strongly -1 on this change. No programming in XML. Period.
I was chatting with James about this and I don't feel this would be the
standard pipeline that we ship but what's above is completely optional and
provides one form of a selector mechanism. What's there is just another
valve.
Again, I'm not that keen on this being the default but we will need a
selector mechanism and this is just one option. All the logic is contained
in a valve and doesn't hurt anything else.
> Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline (was Re: Possible patch to allow files to be streamed back from action)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
James Taylor <jt...@4lane.com> writes:
> Consider:
>
> <pipeline>
> <name>TurbineClassicPipeline</name>
> <valves>
> <valve className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
> <valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
> <select className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
> <when test="vm">
> <valve className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
> </when>
> <when test="jsp">
> <valve className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
> </when>
> <when test="swt">
> <valve className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
> </when>
> </select>
> </valves>
> </pipeline>
I need to read this more thoroughly, but after a first pass, I am
strongly -1 on this change. No programming in XML. Period.
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: torque caching and JCS as a turbine service (credit
cardprocessing)
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2/4/02 5:39 PM, "Aaron Smuts" <aa...@verizon.net> wrote:
> I wonder if caching should be above or on top of Torque rather than
> within.
I'm not really sure that putting it on top of Torque will achieve the
desired effect of transparent caching. Something like that would need to
come from within.
That said, it should be easily disabled if needed. So, the caching methods
should always call: "isCacheEnabled()" or something like that at the top of
their execution.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: torque caching and JCS as a turbine service (credit cardprocessing)
Posted by Aaron Smuts <aa...@verizon.net>.
> -----Original Message-----
> From: Jon Scott Stevens [mailto:jon@latchkey.com]
> Sent: Monday, February 04, 2002 12:46 PM
> To: turbine-dev
> Subject: Re: torque caching and JCS as a turbine service (credit
> cardprocessing)
>
> on 2/3/02 7:51 PM, "Aaron Smuts" <aa...@verizon.net> wrote:
>
> > Back to the point. I could have the managers use Torque for data
access
> > and the managers could still handle the caching, but it might be
nice to
> > have torque handle some of this on its own. The complexity of
handling
> > group dependencies on items matching certain parameters might be a
mess,
> > but for item level stuff it would be nice. Sort of like Javlin
(sp?)
> > and an appserver all in one.
> >
> > Where might caching fit into torque?
> >
> > What about JCS as a turbine service?
> >
> > Aaron
>
> Just some thoughts...
>
> I need caching in Torque as well...I suspect that all of the
doSelect(),
> doUpdate(), doDelete() methods in the Peers would need to be made
> intelligent about caching. We would also want the field level methods
(the
> get/setters) and the save() method in the BO to help with invaliding
and
> updating the cache. You also would need to add some sort of dependency
> tracking into the objects which are related to each other through
joins in
> the database so that when one changes, the other changes as well. This
> part
> can turn into a logistical nightmare if you have several levels of
joins.
>
I wonder if caching should be above or on top of Torque rather than
within.
> Of course all of this would need to be able to be turned off at a
moments
> notice as well...however, if it is done right, it should be
unnoticeable
> when caching is turned on because the invalidation/updating will be so
> efficient and work so well, that you won't even know that an object
came
> from the database or from the cache...
>
> -jon
>
>
> --
> To unsubscribe, e-mail: <mailto:turbine-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: torque caching and JCS as a turbine service (credit card
processing)
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2/3/02 7:51 PM, "Aaron Smuts" <aa...@verizon.net> wrote:
> Back to the point. I could have the managers use Torque for data access
> and the managers could still handle the caching, but it might be nice to
> have torque handle some of this on its own. The complexity of handling
> group dependencies on items matching certain parameters might be a mess,
> but for item level stuff it would be nice. Sort of like Javlin (sp?)
> and an appserver all in one.
>
> Where might caching fit into torque?
>
> What about JCS as a turbine service?
>
> Aaron
Just some thoughts...
I need caching in Torque as well...I suspect that all of the doSelect(),
doUpdate(), doDelete() methods in the Peers would need to be made
intelligent about caching. We would also want the field level methods (the
get/setters) and the save() method in the BO to help with invaliding and
updating the cache. You also would need to add some sort of dependency
tracking into the objects which are related to each other through joins in
the database so that when one changes, the other changes as well. This part
can turn into a logistical nightmare if you have several levels of joins.
Of course all of this would need to be able to be turned off at a moments
notice as well...however, if it is done right, it should be unnoticeable
when caching is turned on because the invalidation/updating will be so
efficient and work so well, that you won't even know that an object came
from the database or from the cache...
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
torque caching and JCS as a turbine service (credit card processing)
Posted by Aaron Smuts <aa...@verizon.net>.
I'd like to get some ideas on how caching might be integrated into
Turbine and Torque.
At my job I've implemented a pattern where data access goes through
managers that return value objects, except on large result sets (they
are cached where efficient and sorted using a comparator sorter on
scaled down value objects or on ArrayLists of arrays).
The managers return simple lists for drop downs and the value objects
for detail pages. The caching is done at the manager level. Data comes
into our application via remote check processing centers and is parsed
by standalone parsers. Credit card and ACH transactions processed in
batch more also run in standalone mode. All the processes access the
data via the same managers and all communicate invalidations through the
cache. Conglomerate data is invalidated by adding the summary data
cache name to the list of caches to notify of the changes for items.
The local and mid-tier caching system keeps the 12 or so machines in
synch. It works nicely. Of course some data access is not cached since
it needs to be 100% accurate. . . .
(Off the subject but a Visa Gateway server certified by Vital would be a
fantastic jakarta project. If you ever needed to handle credit card
processing, you could turn to an open source solution! I'm sure I could
use it in future jobs. Right now you have to buy something less
complicated than JCS that costs at least 20k to send files to the credit
card processing network. I'm all for starting the project if anyone is
interested. You can build a standalone server that takes basic input,
formats a file and sends it to a configured provider. There are some
tricky error handling issues, but it would be an extremely useful
project, but it may put some people out of business.)
Back to the point. I could have the managers use Torque for data access
and the managers could still handle the caching, but it might be nice to
have torque handle some of this on its own. The complexity of handling
group dependencies on items matching certain parameters might be a mess,
but for item level stuff it would be nice. Sort of like Javlin (sp?)
and an appserver all in one.
Where might caching fit into torque?
What about JCS as a turbine service?
Aaron
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by James Taylor <jt...@4lane.com>.
> Definitely cool, but I would like to leave the conditional aspects as
> optional so that in the case where you have an application that is using a
> single view type is optimized.
I agree, and a solution like this gives total flexibility. If you want
to just have a straight pipeline you don't use any conditional valves.
If you want more complicated conditional selection you can use the
conditional valves (and selector valves once built) to accomplish almost
anything. They can be nested without theoretical limit.
> I think your valves would also be very
> valuable for people migrating apps from jsp to velocity (no one would ever
> go the other way!)
Or using both at the same time. Which I agree is unlikely, but there are
other things that fit into this model that people might want to be able
to use concurrently, like vm, image generation with batik, pdf with fop
(or the fdf sdk that several people seem to need, whatever it is), flash
content with JGen.
> Does the pipeline you whipped up make jsp work with the classic model? That
> would be very cool if it does!
Yup! Well, no layouts, but the standard action - module - template
chaining model should work. The archive I sent you privately has a
config in src/rttest/conf/turbine-testapp-pipeline.xml that should
support the classic model for vm, jsp, and set with selection based on
the extension, although I believe it leaves out RunModulesValve for jsp
since I was emulating the other jsp pipeline.
> John and I also briefly discussed a top-level selector, as I agreed with him
> when said he didn't like the idea of being able to select a pipeline with
> parameters. It would also be nice to be able to avoid the selector as well
> for say a pure velocity app so we can make things as optimal as possible.
Totally. I think doing the selectors with valves is the way to go since
you get full flexibility. You can have a selector at the top (top level
pipeline with one selector valve containing other pipelines that get
executed conditionally), Just a standard pipeline (no conditional or
selection valves at all), or any more complicated flow.
The mapper makes the easy because we can pass arbitrary implementation
specific parameters (in the form of bean properties) to the valves for
configuration. Thus people can subclass the BaseConditionalValve (and
BaseSelectorValve or whatever we end up with for that) and configure it
however they want in the pipeline xml file.
-- jt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/1/02 7:59 PM, "James Taylor" <jt...@4lane.com> wrote:
> I put together an implementation of some of the ideas I discussed
> earlier, in the form of and abstract BaseConditionValve and two concrete
> subclasses (request and extension based) that allow a set of valves to
> be included or excluded based on conditions (implementation defined).
> The mapper made this very easy!
>
>
> I'm really happy with the way this turned out. It seems pretty elegant
> considering no changes to existing pipeline classes were required.
> Thoughts?
Definitely cool, but I would like to leave the conditional aspects as
optional so that in the case where you have an application that is using a
single view type is optimized. I think your valves would also be very
valuable for people migrating apps from jsp to velocity (no one would ever
go the other way!)
Does the pipeline you whipped up make jsp work with the classic model? That
would be very cool if it does!
John and I also briefly discussed a top-level selector, as I agreed with him
when said he didn't like the idea of being able to select a pipeline with
parameters. It would also be nice to be able to avoid the selector as well
for say a pure velocity app so we can make things as optimal as possible.
> Thanks,
> James
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Thinking about 'multiple' pipeline
Posted by James Taylor <jt...@4lane.com>.
I put together an implementation of some of the ideas I discussed
earlier, in the form of and abstract BaseConditionValve and two concrete
subclasses (request and extension based) that allow a set of valves to
be included or excluded based on conditions (implementation defined).
The mapper made this very easy!
The condition valve essentially wraps a pipeline. When invoked it runs
the doTest method (which subclasses must implement) and if that returns
true in invokes the set of valves it contains, before invokeing its next
sibling.
An implementation that emulates a switch rather than an if should be
easy to put together along the same lines.
I changed the 'classic' pipeline to support vm and jsp, and added a test
to the TurbineSerlvetTest that tests the jsp page Index.jsp, everything
works great. The pipeline config now looks like this:
<pipeline>
<name>TurbineClassicPipeline</name>
<valves>
<valve className="org.apache.turbine.pipeline.DetermineActionValve"/>
<valve className="org.apache.turbine.pipeline.DetermineTargetValve"/>
<valve className="org.apache.turbine.pipeline.DefaultSessionTimeoutValve"/>
<valve className="org.apache.turbine.pipeline.DefaultLoginValve"/>
<valve className="org.apache.turbine.pipeline.DefaultSessionValidationValve"/>
<valve className="org.apache.turbine.pipeline.DefaultACLCreationValve"/>
<valve className="org.apache.turbine.pipeline.DefaultActionValve"/>
<valve className="org.apache.turbine.pipeline.RunModulesValve"/>
<valve className="org.apache.turbine.pipeline.TargetExtensionConditionalValve">
<extension>.vm</extension>
<valves>
<valve className="org.apache.turbine.pipeline.DefaultTargetValve"/>
</valves>
</valve>
<valve className="org.apache.turbine.pipeline.TargetExtensionConditionalValve">
<extension>.jsp</extension>
<valves>
<valve className="org.apache.turbine.pipeline.JspRendererValve"/>
</valves>
</valve>
</valves>
</pipeline>
I'm really happy with the way this turned out. It seems pretty elegant
considering no changes to existing pipeline classes were required.
Thoughts?
Thanks,
James
RE: Thinking about 'multiple' pipeline (was Re: Possible patch to
allowfiles to be streamed back from action)
Posted by James Taylor <jt...@4lane.com>.
> I think this is an excellent approach. Only problem I can see is what if
> there is no extension in the request. What if I want the result of a form
> submission to my FDF. I guess I could just put something like:
>
> action="$link.setAction(...).setPage(".FDF")"
>
> or something like that.
No, you would just use a different implementation of selector, or write
your own which parses some relevent parameter from somewhere and decides
what valve to use based on it. In cocoon the base selectors are browser,
header, host, request parameter, request attribute, session attribute.
We could implement similar selectors based on more turbine relevent
stuff.
Cocoon matchers:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/matching/
Cocoon selectors:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/selection/
>
> > This gives users a ton of flexibility. We could implement some standard
> > selectors, for example ones that look at request parameters or objects
> > stored in RunData (however that looks when Jason finishes with it). The
> > base classes for selectors could be more intelligent, to allow globbed
> > or regexp matches.
>
> yes. yes. yes.
>
> > In Gareth's case, this would allow him a few ways to accomplish his
> > goal. He could simply leave out any target valve for certain extensions,
>
> No I don't like this, I would prefer to do all rendering in a target valve.
> This makes more sense in the design. I guess I just need to make sure that
> the relevant data in the the session.
>
> > Or (the one I prefer) he could implement a valve for
> > rendering using the FDF sdk, and use a selector to ensure that that
> > valve is run for the relevent targets.
> >
>
> Yes I prefer this but its difficult to see how it would work:
>
> ACTION:
>
> 1.Parse Form data
> 2.Put it in session?
>
> VALVE:
>
> 1. Get data from session
> 2. Render appropriate FDF File
This is the one I like since it follows the current turbine pattern.
Actions and Modules build contexts, renderer render views. In this case
you don't have a template at all, but you still have an FDFRendererValve
or whatever.
> ????
>
> Not really sure about this approach. At the moment the result of the action
> is a byte[] (or String actually) which represents the FDF. I could store
> just this output in the session. Then print it to the output stream in the
> valve. Seems like a weird way to pass data around though.
>
> What to you think?
I think you have a special case where its going to be hard to make the
FDF sdk fit cleanly into the turbine model. However if we implement
something like what is described above, it would give you enough
flexibility to accomplish what you want in several ways, even if none of
them is ideal.
Thanks,
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline (was Re: Possible patch to allowfiles to be streamed back from action)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Gareth Coltman" <ga...@majorband.co.uk> writes:
> So I once again suggest that we modify the runData. This seems to be the
> only sensible way of sending data from valve to valve.
Using a RunData implementation is the Right Thing to do in this
situation. You can always subclass RunData, then check in your custom
Valve implementations to see if you have an specific type.
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Thinking about 'multiple' pipeline (was Re: Possible patch to allowfiles to be streamed back from action)
Posted by Gareth Coltman <ga...@majorband.co.uk>.
OK, I've thought more about the problem.
What we need is a way to send data from the action valve to the target
value.
The session (which was my first suggestion) is a terrible work around. We
should never rely on a session being there in the pipeline.
So I once again suggest that we modify the runData. This seems to be the
only sensible way of sending data from valve to valve.
The idea is :
In your action, you create some raw data (pdf, images). You then call
data.setRawData(data, contentType)
This will create a reference to the raw data in the runData and also call
data.setContentType().
Then you set up a new target (using James suggested extension based
configuration) which will do the follwing:
data.getResponse().setContentType(data.getContentType);
data.getResponse().getOutputStream().write(data.getRawData());
Something like that anyway!
OK - this adds another property to the runData but I think that it does
provide more flexibility.
Gareth
> -----Original Message-----
> From: Gareth Coltman [mailto:gareth_coltman@majorband.co.uk]
> Sent: 01 February 2002 16:35
> To: Turbine Developers List
> Subject: RE: Thinking about 'multiple' pipeline (was Re: Possible patch
> to allowfiles to be streamed back from action)
>
>
> James,
>
> >
> > <pipeline>
> > <name>TurbineClassicPipeline</name>
> > <valves>
> > <valve
> > className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
> > <valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
> > <select
> > className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
> > <when test="vm">
> > <valve
> > className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
> > </when>
> > <when test="jsp">
> > <valve
> > className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
> > </when>
> > <when test="swt">
> > <valve
> > className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
> > </when>
> > </select>
> > </valves>
> > </pipeline>
>
> I think this is an excellent approach. Only problem I can see is what if
> there is no extension in the request. What if I want the result of a form
> submission to my FDF. I guess I could just put something like:
>
> action="$link.setAction(...).setPage(".FDF")"
>
> or something like that.
>
> > This gives users a ton of flexibility. We could implement some standard
> > selectors, for example ones that look at request parameters or objects
> > stored in RunData (however that looks when Jason finishes with it). The
> > base classes for selectors could be more intelligent, to allow globbed
> > or regexp matches.
>
> yes. yes. yes.
>
> > In Gareth's case, this would allow him a few ways to accomplish his
> > goal. He could simply leave out any target valve for certain extensions,
>
> No I don't like this, I would prefer to do all rendering in a
> target valve.
> This makes more sense in the design. I guess I just need to make sure that
> the relevant data in the the session.
>
> > Or (the one I prefer) he could implement a valve for
> > rendering using the FDF sdk, and use a selector to ensure that that
> > valve is run for the relevent targets.
> >
>
> Yes I prefer this but its difficult to see how it would work:
>
> ACTION:
>
> 1.Parse Form data
> 2.Put it in session?
>
> VALVE:
>
> 1. Get data from session
> 2. Render appropriate FDF File
>
> ????
>
> Not really sure about this approach. At the moment the result of
> the action
> is a byte[] (or String actually) which represents the FDF. I could store
> just this output in the session. Then print it to the output stream in the
> valve. Seems like a weird way to pass data around though.
>
> What to you think?
>
> Gareth
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Thinking about 'multiple' pipeline (was Re: Possible patch to allowfiles to be streamed back from action)
Posted by Gareth Coltman <ga...@majorband.co.uk>.
James,
>
> <pipeline>
> <name>TurbineClassicPipeline</name>
> <valves>
> <valve
> className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
> <valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
> <select
> className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
> <when test="vm">
> <valve
> className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
> </when>
> <when test="jsp">
> <valve
> className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
> </when>
> <when test="swt">
> <valve
> className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
> </when>
> </select>
> </valves>
> </pipeline>
I think this is an excellent approach. Only problem I can see is what if
there is no extension in the request. What if I want the result of a form
submission to my FDF. I guess I could just put something like:
action="$link.setAction(...).setPage(".FDF")"
or something like that.
> This gives users a ton of flexibility. We could implement some standard
> selectors, for example ones that look at request parameters or objects
> stored in RunData (however that looks when Jason finishes with it). The
> base classes for selectors could be more intelligent, to allow globbed
> or regexp matches.
yes. yes. yes.
> In Gareth's case, this would allow him a few ways to accomplish his
> goal. He could simply leave out any target valve for certain extensions,
No I don't like this, I would prefer to do all rendering in a target valve.
This makes more sense in the design. I guess I just need to make sure that
the relevant data in the the session.
> Or (the one I prefer) he could implement a valve for
> rendering using the FDF sdk, and use a selector to ensure that that
> valve is run for the relevent targets.
>
Yes I prefer this but its difficult to see how it would work:
ACTION:
1.Parse Form data
2.Put it in session?
VALVE:
1. Get data from session
2. Render appropriate FDF File
????
Not really sure about this approach. At the moment the result of the action
is a byte[] (or String actually) which represents the FDF. I could store
just this output in the session. Then print it to the output stream in the
valve. Seems like a weird way to pass data around though.
What to you think?
Gareth
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Thinking about 'multiple' pipeline (was Re: Possible patch to allow
files to be streamed back from action)
Posted by James Taylor <jt...@4lane.com>.
Gareth's message got me thinking about handling multiple pipelines. I
know Jason is planning on adding some code to select one of a set of
pipelines based on a request parameter. I think we all agree that this
is only a temporary solution, more flexibility will be required.
So I decided to take a look at how things are implemented in cocoon and
stuts. I got scared away from struts pretty quickly, I didn't have the
patience to figure out the action mapping thing, but if anyone who uses
struts can share the advantages of that solution I'd be very interested.
Cocoon on the other hand was quite a bit easier to understand, and I
really like some aspects of their pipeline handling. Specifically
'selectors' and 'matchers' which allow user defined classes to make
decisions about the progress of the pipeline. Consider:
<pipeline>
<name>TurbineClassicPipeline</name>
<valves>
<valve className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
<valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
<select className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
<when test="vm">
<valve className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
</when>
<when test="jsp">
<valve className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
</when>
<when test="swt">
<valve className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
</when>
</select>
</valves>
</pipeline>
In this case we have a selector that parses the extension of the target
and selects the appropriate renderer. One important thing is that the
parsing of the target is done AFTER RunModulesValve, so if a module
changes the target, it will go to the correct renderer.
This gives users a ton of flexibility. We could implement some standard
selectors, for example ones that look at request parameters or objects
stored in RunData (however that looks when Jason finishes with it). The
base classes for selectors could be more intelligent, to allow globbed
or regexp matches.
In Gareth's case, this would allow him a few ways to accomplish his
goal. He could simply leave out any target valve for certain extensions,
or have a matcher that ignores that valve if the output stream is
already opened. Or (the one I prefer) he could implement a valve for
rendering using the FDF sdk, and use a selector to ensure that that
valve is run for the relevent targets.
Thoughts?
Thanks, jt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Possible patch to allow files to be streamed back from action
Posted by James Taylor <jt...@4lane.com>.
On Fri, 2002-02-01 at 08:45, Gareth Coltman wrote:
>
> 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.
Agreed. Also, for binary data it certainly will not work since
DefaultTargetValve buffers the template merge result in a string.
> 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.
Yup, and I agree with Jason that _doing_ this is a bad idea. Actions and
Modules should build contexts, and templates render them. However, I
believe having the valves gracefully handle a null target (treating it
as a noop) is a good thing since it lets us cope with this even though
in most cases it is a bad design choice at the application level.
> 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 I really dislike. RunData already has more crap in it than it
should.
> 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.
jt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Possible patch to allow files to be streamed back from action
Posted by Eric Dobbs <er...@dobbse.net>.
On Friday, February 1, 2002, at 06:45 AM, Gareth Coltman wrote:
> 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.
I would want to separate this into two components. The action
should capture the user input. And a subclass of RawScreen or
the T3 equivalent should be responsible for the PDF generation.
Perhaps the action captures input and puts it into a context
that gets used by the PDFScreen, or something like that.
In other words, treat the PDF generation as analogous to one of
the template mechanisms.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Possible patch to allow files to be streamed back from action
Posted by Gareth Coltman <ga...@majorband.co.uk>.
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:jvanzyl@zenplex.com]
> 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" <jt...@4lane.com> 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:
> <ma...@jakarta.apache.org>
> >> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >>
> >>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
>
> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Possible patch to allow files to be streamed back from action
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/1/02 8:17 AM, "James Taylor" <jt...@4lane.com> 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: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Possible patch to allow files to be streamed back from action
Posted by James Taylor <jt...@4lane.com>.
Ugh, buffering.
So your goal is to have an Action or Module be able to write the output?
How about this:
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Possible patch to allow files to be streamed back from action
Posted by Gareth Coltman <ga...@majorband.co.uk>.
Sorry the conditional in my code was back to front.
Should be
if(data.getResponseBody() == null)
> -----Original Message-----
> From: Gareth Coltman [mailto:gareth_coltman@majorband.co.uk]
> Sent: 01 February 2002 10:09
> To: Turbine Developers List
> Subject: Possible patch to allow files to be streamed back from action
>
>
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>