You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2003/02/26 03:18:22 UTC
Subrequesting the sitemap with the flow...
I have a small addition to the flow, if you might... It's called
"subRequest"...
Basically, my "problem" is that, sometimes, using the flow, I want to save
the output of a given Cocoon URL to an OutputStream. This might happen
because I have a MimeSerializer which outputs the result of a pipeline in
MIME format (suitable to be transmitted with SMTP), or because I have
something that I want to save to disk, but at the same time, have something
else to deliver to the Client (ok, it's 2 AM and I'm having troubles
explaining what I _need_ to be doing, Stefano, as we talked about it, care
to explain with your extreme conciseness and better english?)
So, roughly, the target of it, is to be able to save the output of a Cocoon
pipeline, to a given outputstream, while, at the same time, serving the flow
to the client... (Ok, this seems clearer)...
I worked on a patch allowing to do this, and before I actually put it in
CVS, I would like to have you folks to review it, as it's a quite big step
in the direction of having multiple outputs for a pipeline, although it's
just few lines of patch...
It is attached, and it's in its very rough format, it just _WORKS_, it isn't
anyhow supposed to be doing much...
Attached, also, there's my little test sub-sitemap, just put it in your
webapp dir under "/test/" and try it out: when you request
"http://localhost:8080/test/" with your browser, it will display a nice
"Hello world" in your browser, but at the same time, it will save it in
/tmp/test.out...
Let me know... Right now I'm way too confused to make any sense to myself as
well! :-) :-) :-) Tomorrow is another day!
Pier
Re: Subrequesting the sitemap with the flow...
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 26/2/03 2:23, "Jason Foster" <re...@fastmail.fm> wrote:
> <snip/>
>
> Wouldn't this be a great way to pre-generate alternative output formats
> when a user requests a page. In other words:
>
> - user requests the HTML version of a resource
> - cocoon returns the HTML resource and generates the PDF version
> - user requests the PDF version
> - cocoon returns the PDF version immediately!
>
> A periodic thread to kill any unused pre-generated content (or an
> age-based cache) and voila!
>
> Just a thought.
In theory (a lot of theory) it should trigger the caching as well, so
probably the PDF could be cached as it's generated, and then served off the
cache straight away... But I still didn't gather enough knowledge on that
part to tell you if it really happens or not.
Pier
Re: Subrequesting the sitemap with the flow...
Posted by Jason Foster <re...@fastmail.fm>.
<snip/>
Wouldn't this be a great way to pre-generate alternative output formats
when a user requests a page. In other words:
- user requests the HTML version of a resource
- cocoon returns the HTML resource and generates the PDF version
- user requests the PDF version
- cocoon returns the PDF version immediately!
A periodic thread to kill any unused pre-generated content (or an
age-based cache) and voila!
Just a thought.
Jason Foster
Re: Subrequesting the sitemap with the flow...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
> Pier Fumagalli wrote:
>
>> I'll start putting it in CVS as "process", we can always change it, deal?
>
> Deal.
>
> I see one thing missing: how do I pass parameters to the pipeline I want
> to call? I mean, following the concept of sendPage() and friends, I
> would like to be able to create a map of stuff and pass it on for the
> <jxpath> taglib to pick up later in the pipeline.
That's what I'm working on... It'll be in CVS at commit time (hopefully)...
Pier
Re: Subrequesting the sitemap with the flow...
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> I'll start putting it in CVS as "process", we can always change it, deal?
Deal.
I see one thing missing: how do I pass parameters to the pipeline I want
to call? I mean, following the concept of sendPage() and friends, I
would like to be able to create a map of stuff and pass it on for the
<jxpath> taglib to pick up later in the pipeline.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: Subrequesting the sitemap with the flow...
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
> Ovidiu Predescu wrote:
>> This is great!
>>
>> We've been talking about doing this for a while now, so your patch is
>> more than welcome!
>>
>> I haven't had a chance to test it yet (and most likely I won't have one
>> this week), but it's looking great. It would be great if you could add a
>> small Anteater test to test the functionality.
>>
>> One small observation (even though I hate naming discussions ;) I'd
>> rename 'subrequest' to 'process' since is actually a verb and conveys
>> the meaning of the method. You may also want to add it to the
>> Interpreter interface, in case other flow interpreters come up (Scheme
>> etc.)
>
> What about 'callPipeline'?
callPipeline is something that (in my mind) calls a pipeline instance, but
you should already have that pipeline... In this case, you're calling a URI
in the Cocoon sitemap, so IMVHO, "process" makes more sense, but I'm
positive on anything ("callSitemap" would make sense as well)...
I'll start putting it in CVS as "process", we can always change it, deal?
Pier (who has the tendency to loose stuff not checked in)
Re: Subrequesting the sitemap with the flow...
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu Predescu wrote:
> This is great!
>
> We've been talking about doing this for a while now, so your patch is
> more than welcome!
>
> I haven't had a chance to test it yet (and most likely I won't have one
> this week), but it's looking great. It would be great if you could add a
> small Anteater test to test the functionality.
>
> One small observation (even though I hate naming discussions ;) I'd
> rename 'subrequest' to 'process' since is actually a verb and conveys
> the meaning of the method. You may also want to add it to the
> Interpreter interface, in case other flow interpreters come up (Scheme
> etc.)
What about 'callPipeline'?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: Subrequesting the sitemap with the flow...
Posted by Ovidiu Predescu <ov...@apache.org>.
On Wednesday, Feb 26, 2003, at 02:49 US/Pacific, Pier Fumagalli wrote:
> On 26/2/03 5:23, "Ovidiu Predescu" <ov...@apache.org> wrote:
>
>> One small observation (even though I hate naming discussions ;) I'd
>> rename 'subrequest' to 'process' since is actually a verb and conveys
>> the meaning of the method. You may also want to add it to the
>> Interpreter interface, in case other flow interpreters come up (Scheme
>> etc.)
>
> It was called process until 15 minutes before sending out the patch!
> :-)
:) Great! I guess you should take some more sleep ;)
Cheers,
Ovidiu
Re: Subrequesting the sitemap with the flow...
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 26/2/03 5:23, "Ovidiu Predescu" <ov...@apache.org> wrote:
> One small observation (even though I hate naming discussions ;) I'd
> rename 'subrequest' to 'process' since is actually a verb and conveys
> the meaning of the method. You may also want to add it to the
> Interpreter interface, in case other flow interpreters come up (Scheme
> etc.)
It was called process until 15 minutes before sending out the patch! :-)
Pier
Re: Subrequesting the sitemap with the flow...
Posted by Ovidiu Predescu <ov...@apache.org>.
This is great!
We've been talking about doing this for a while now, so your patch is
more than welcome!
I haven't had a chance to test it yet (and most likely I won't have one
this week), but it's looking great. It would be great if you could add
a small Anteater test to test the functionality.
One small observation (even though I hate naming discussions ;) I'd
rename 'subrequest' to 'process' since is actually a verb and conveys
the meaning of the method. You may also want to add it to the
Interpreter interface, in case other flow interpreters come up (Scheme
etc.)
Other than that is fine with me.
Thanks for the contribution!
Cheers,
Ovidiu
--
Ovidiu Predescu <ov...@apache.org>
http://www.google.com/search?btnI=&q=ovidiu (I'm feeling lucky)
On Tuesday, Feb 25, 2003, at 18:18 US/Pacific, Pier Fumagalli wrote:
> I have a small addition to the flow, if you might... It's called
> "subRequest"...
>
> Basically, my "problem" is that, sometimes, using the flow, I want to
> save
> the output of a given Cocoon URL to an OutputStream. This might happen
> because I have a MimeSerializer which outputs the result of a pipeline
> in
> MIME format (suitable to be transmitted with SMTP), or because I have
> something that I want to save to disk, but at the same time, have
> something
> else to deliver to the Client (ok, it's 2 AM and I'm having troubles
> explaining what I _need_ to be doing, Stefano, as we talked about it,
> care
> to explain with your extreme conciseness and better english?)
>
> So, roughly, the target of it, is to be able to save the output of a
> Cocoon
> pipeline, to a given outputstream, while, at the same time, serving
> the flow
> to the client... (Ok, this seems clearer)...
>
> I worked on a patch allowing to do this, and before I actually put it
> in
> CVS, I would like to have you folks to review it, as it's a quite big
> step
> in the direction of having multiple outputs for a pipeline, although
> it's
> just few lines of patch...
>
> It is attached, and it's in its very rough format, it just _WORKS_, it
> isn't
> anyhow supposed to be doing much...
>
> Attached, also, there's my little test sub-sitemap, just put it in your
> webapp dir under "/test/" and try it out: when you request
> "http://localhost:8080/test/" with your browser, it will display a nice
> "Hello world" in your browser, but at the same time, it will save it in
> /tmp/test.out...
>
> Let me know... Right now I'm way too confused to make any sense to
> myself as
> well! :-) :-) :-) Tomorrow is another day!
>
> Pier
>
> <patch.txt><test.tar.gz>