Re: Processor after XSP - impossible since 1.8.1?

[Robin Green <gr...@hotmail.com>]

Ulrich Mayring <ul...@denic.de> wrote:
>I tried this with 1.8.1 and 1.8.2, but I still can't get cocoon to run
>with some of my XSP pages. They look like this:
>
>...
>
><?cocoon-process type="xsp"?>
><?cocoon-process type="someprocessor"?>
>
>...
>
><xsp:logic>
>	response.sendRedirect("somewhere.xml");
></xsp:logic>
>
></xsp:page>
>
>
>It appears that - since XSP is executed first - the redirect is carried
>out immediately, before the processor has a chance to run.

Yes.

>This is
>unfortunate in situations where the processor needs input generated by
>XSP. In version 1.8 and before this worked.

It's an optimisation - I didn't think there was any point in processing the 
output any further if redirecting, seeing as it wasn't going to be 
outputted. But I suppose I should leave it to the cocoon-user to add/remove 
processing instructions to optimise it.

Is it acceptable to drop the formatter stage at least - or do you even use 
that for something?



_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: Processor after XSP - impossible since 1.8.1?

[Ulrich Mayring <ul...@denic.de>]

Donald Ball wrote:
> 
> On Tue, 30 Jan 2001, Uli Mayring wrote:
> 
> > So your suggestion to port all of that is simply not an option. And
> > porting just the pages with redirects is not an option either, because my
> > code may be old, but it is consistent. I know, this is neither your fault,
> > nor your problem, just an explanation of why I'm reluctant to break
> > backwards compatibility in cocoon1.
> 
> maybe we could make it a configuration option in cocoon.properties -
> 
> handle.redirects.early = true
> 
> or something like that? i wouldn't have thought that there would be _that_
> many pages out there that relied on the reactor _not_ exiting early after
> a redirect, but if that really is the case, i'd hate to make life hard on
> you.

I've spent about 70% of my time all last week trying to upgrade from 1.8
to 1.8.2. The problem is not installing cocoon, that's a thing of 5
minutes. But testing all my old apps with the new version is a pain,
frankly. Especially since these are productive systems working with
databases, sending out faxes to customers, generating letters to be
printed at an external print shop, providing a web interface for
customers to send their orders and so on. There's really no easy way to
test all that without disrupting production, so I can only do so much
and the rest is faith in cocoon's backwards compatibility :-)

> out of curiousity - can you give me an example of when you're relying on
> the reactor _not_ exiting early after a redirect?

For example the user is presented with two buttons "ok" and "cancel". If
he clicks "cancel" I redirect him back to the page he came from, no
problem. But if he clicks "ok", I'll have to run the processor and then
redirect him back to where he came from. So, first I'll have to do XSP
to determine if he clicked "ok" or "cancel" and then run the processor.
The way cocoon worked before was, that it did the redirect and then the
processor executed in the "background".

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: Processor after XSP - impossible since 1.8.1?

[Sébastien Koechlin <sk...@ivision.fr>]

Donald Ball wrote:
> 
> On Tue, 30 Jan 2001, Uli Mayring wrote:
> 
> > So your suggestion to port all of that is simply not an option. And
> > porting just the pages with redirects is not an option either, because my
> > code may be old, but it is consistent. I know, this is neither your fault,
> > nor your problem, just an explanation of why I'm reluctant to break
> > backwards compatibility in cocoon1.
> 
> maybe we could make it a configuration option in cocoon.properties -
> 
> handle.redirects.early = true

Is redirects always called from XSP, with or without taglib?

What about something like :

        response.sendRedirect("somewhere.xml");
	this.stopProcessing();

And this can be add into various taglib :

	<response:send-redirect
		still-processing="true" 
		location="somewhere.xml"/>

-- 
Sébastien Koechlin - IVision - skoechlin@ivision.fr

Re: Processor after XSP - impossible since 1.8.1?

[Donald Ball <ba...@webslingerZ.com>]

On Tue, 30 Jan 2001, Uli Mayring wrote:

> So your suggestion to port all of that is simply not an option. And
> porting just the pages with redirects is not an option either, because my
> code may be old, but it is consistent. I know, this is neither your fault,
> nor your problem, just an explanation of why I'm reluctant to break
> backwards compatibility in cocoon1.

maybe we could make it a configuration option in cocoon.properties -

handle.redirects.early = true

or something like that? i wouldn't have thought that there would be _that_
many pages out there that relied on the reactor _not_ exiting early after
a redirect, but if that really is the case, i'd hate to make life hard on
you.

out of curiousity - can you give me an example of when you're relying on
the reactor _not_ exiting early after a redirect?

- donald

Re: Processor after XSP - impossible since 1.8.1?

[Uli Mayring <ul...@denic.de>]

On Mon, 29 Jan 2001, Donald Ball wrote:

> > but not for every processor a taglib implementation exists.
> 
> and that deficiency should be corrected. it's much easier to write
> logicsheets that processors anyway, and logicsheets can play together
> faster and more easily than processors.

That's true. But it's easier using working processors than writing new
taglibs from scratch. Ok, so now you say the processors don't really work,
otherwise I wouldn't have my problem in the first place and that may be
true. But when I started out with cocoon, processors were the thing to
use.

FYI, I have several hundred XSP pages using the SQL processor running in
production. I still have legacy apps using XSP by way of the clean-page
model, which are being used by our customers. It took me about a year to
write all this stuff and I probably forgot half of it even exists.

So your suggestion to port all of that is simply not an option. And
porting just the pages with redirects is not an option either, because my
code may be old, but it is consistent. I know, this is neither your fault,
nor your problem, just an explanation of why I'm reluctant to break
backwards compatibility in cocoon1.

Sure, one day I'll take the time to port everything to cocoon2, but I'm
not too keen on doing all that work just to get from 1.8 to 1.8.2 - and
then have you guys pull the chair out from under my ass again in 1.8.3 :)

Anyway, thanks for your suggestions, I promise to take a serious look if I
can patch my legacy stuff in any reasonable way. If not I'll just sit on
1.8 and put my workflow taglib on hold till cocoon2.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung

Re: Processor after XSP - impossible since 1.8.1?

[Donald Ball <ba...@webslingerZ.com>]

On Mon, 29 Jan 2001, Uli Mayring wrote:

> > i almost _always_ have a processor running after XSP - namely, the XSLT
> > processor. that's the most common processor usage pattern out there, and
> > i'd rather not burn cpu cycles doing a superfluous XSLT transformation.
>
> Well then leave it out :)  All power to the user :)

but then i have to manually insert the cocoon-process directives if and
only if i don't send a redirect. that's a real bitch to keep track of.

> > > I have no first processor, just XSP and then another one. I would have to
> > > implement response.sendRedirect behavior in every processor I wish to use
> > > after XSP - isn't that a bit kludgy?
> >
> > how often do you want your other processors doing stuff after xsp has sent
> > a redirect? that seems very kludgy, imho.
>
> It's not a matter of how often do I want to do this, the question is can I
> do it at all?

of course you can. just have your xsp process send a signal to your second
processor to issue the redirect once it's done its work. something like
this:

<my-second-processor:send-redirect href="/place/"/>

or

<?my-redirect href="/place/"?>

your second processor could look for that and then send a redirect if it
sees it - after it's done whatever work you needed to have it do. or you
could write a special tiny processor that sits at the end of your
processor chain and sends redirects if it sees these signals.

there are any of a number of solutions that can accomodate your need to
have the rest of the processors in the reactor still activate even if the
first processor wants to send a redirect. but the default behavior of the
system should be early exit on redirect, i am firmly convinced.

> But the way cocoon is implemented, any processor that "does stuff" may
> have to run after XSP. Think of your own SQL processor - how would you do
> updates to a database row you calculate in XSP? I know, you'd use ESQL,
> but not for every processor a taglib implementation exists.

and that deficiency should be corrected. it's much easier to write
logicsheets that processors anyway, and logicsheets can play together
faster and more easily than processors.

> You may think I could just change my app, too, but that is not so. Perhaps
> you think I could just run the processor on the page I redirect to and
> send the processor's input along as HTTP request parameters. That's all
> fine and well, but how do I get HTTP request parameters? Yeah, XSP again
> and then the processor and then a redirect to the page I really wanted to
> go to in the first place. Same problem.

that would be painful. i don't recommend that at all.

- donald

Re: Processor after XSP - impossible since 1.8.1?

[Uli Mayring <ul...@denic.de>]

On Mon, 29 Jan 2001, Donald Ball wrote:

> i almost _always_ have a processor running after XSP - namely, the XSLT
> processor. that's the most common processor usage pattern out there, and
> i'd rather not burn cpu cycles doing a superfluous XSLT transformation.

Well then leave it out :)  All power to the user :)

> > I have no first processor, just XSP and then another one. I would have to
> > implement response.sendRedirect behavior in every processor I wish to use
> > after XSP - isn't that a bit kludgy?
> 
> how often do you want your other processors doing stuff after xsp has sent
> a redirect? that seems very kludgy, imho.

It's not a matter of how often do I want to do this, the question is can I
do it at all?

Sure, I'd prefer to send the redirect *after* my processor finishes, but I
need XSP to dynamically generate its input. If I could have two XSP
passes and a processor in between, I'd be the happiest guy in the world.

But the way cocoon is implemented, any processor that "does stuff" may
have to run after XSP. Think of your own SQL processor - how would you do
updates to a database row you calculate in XSP? I know, you'd use ESQL,
but not for every processor a taglib implementation exists.

So, your problem can be solved by editing XML files, but mine only by
reverting cocoon back to its original state.

You may think I could just change my app, too, but that is not so. Perhaps
you think I could just run the processor on the page I redirect to and 
send the processor's input along as HTTP request parameters. That's all
fine and well, but how do I get HTTP request parameters? Yeah, XSP again
and then the processor and then a redirect to the page I really wanted to
go to in the first place. Same problem.

So how about forgetting about the second redirect and just put the stuff
from the page I really wanted to go to into the page that also runs the
processor? Well, it happens that page is identical to the one I started
from - so I do things twice, when I want to do them once, and once, when I
don't want to do them at all.

Hell, I may be blind, it wouldn't be the first time. If you have an idea
how I could solve my problem, I'd be most grateful and shut up :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung

Re: Processor after XSP - impossible since 1.8.1?

[Donald Ball <ba...@webslingerZ.com>]

On Mon, 29 Jan 2001, Uli Mayring wrote:

> On Mon, 29 Jan 2001, Donald Ball wrote:
>
> > no! i vote -1, i say keep it like it is! i _like_ having the reactor kick
> > the processing chain out of the system if something results in a redirect.
> > i think this is a _far_ more common desire than what you want.
>
> Assuming I understood Robin correctly: if you have no processor running
> after XSP, then you're fine as it is. So why should cocoon fix a user
> error (superflous processing instruction) at the expense of another user's
> valid code?

i almost _always_ have a processor running after XSP - namely, the XSLT
processor. that's the most common processor usage pattern out there, and
i'd rather not burn cpu cycles doing a superfluous XSLT transformation.

> > in your case, why don't you have the first processor send a signal to the
> > second processor using a specially named element in the DOM - the signal
> > being, send a redirect here when you're done.
>
> I have no first processor, just XSP and then another one. I would have to
> implement response.sendRedirect behavior in every processor I wish to use
> after XSP - isn't that a bit kludgy?

how often do you want your other processors doing stuff after xsp has sent
a redirect? that seems very kludgy, imho.

- donald

Re: Processor after XSP - impossible since 1.8.1?

[Uli Mayring <ul...@denic.de>]

On Mon, 29 Jan 2001, Donald Ball wrote:

> no! i vote -1, i say keep it like it is! i _like_ having the reactor kick
> the processing chain out of the system if something results in a redirect.
> i think this is a _far_ more common desire than what you want.

Assuming I understood Robin correctly: if you have no processor running 
after XSP, then you're fine as it is. So why should cocoon fix a user
error (superflous processing instruction) at the expense of another user's
valid code?

> in your case, why don't you have the first processor send a signal to the
> second processor using a specially named element in the DOM - the signal
> being, send a redirect here when you're done.

I have no first processor, just XSP and then another one. I would have to
implement response.sendRedirect behavior in every processor I wish to use
after XSP - isn't that a bit kludgy?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung

Re: Processor after XSP - impossible since 1.8.1?

[Donald Ball <ba...@webslingerZ.com>]

On Mon, 29 Jan 2001, Ulrich Mayring wrote:

> Robin Green wrote:
> >
> > It's an optimisation - I didn't think there was any point in processing the
> > output any further if redirecting, seeing as it wasn't going to be
> > outputted.
>
> Yes, but processors sometimes do more things than just produce XML.
>
> > But I suppose I should leave it to the cocoon-user to add/remove
> > processing instructions to optimise it.
>
> Yes, please! :)

no! i vote -1, i say keep it like it is! i _like_ having the reactor kick
the processing chain out of the system if something results in a redirect.
i think this is a _far_ more common desire than what you want.

in your case, why don't you have the first processor send a signal to the
second processor using a specially named element in the DOM - the signal
being, send a redirect here when you're done.

- donald

Re: Processor after XSP - impossible since 1.8.1?

[Ulrich Mayring <ul...@denic.de>]

Robin Green wrote:
> 
> It's an optimisation - I didn't think there was any point in processing the
> output any further if redirecting, seeing as it wasn't going to be
> outputted.

Yes, but processors sometimes do more things than just produce XML.

> But I suppose I should leave it to the cocoon-user to add/remove
> processing instructions to optimise it.

Yes, please! :)

> Is it acceptable to drop the formatter stage at least - or do you even use
> that for something?

I don't think I use it with redirects. But perhaps I could construct a
case:

I am using the <?cocoon-format?> instruction for writing to logfiles.
For example, an XML page is called from an application and the returned
string is written into the app's logfile. In order to minimise overhead
in the logfile, I've written a stylesheet that strips out all XML tags
and returns text/plain. If that XML page now were to use a redirect,
perhaps to a logfile-writer, then we might have a problem. Now, this is
very theoretical, so I may be wrong :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung