Hi,
Thanks for your reply.
I'm OK with all you told me about, ie that once you send some content to the
client, headers are already sent. So, this is too late to put any location
and different response code in the headers.
However, I would have imagined a way like that:
Send Headers
Send Some Content
Error on the server => Ask the client to load another page
But this doesn't seem to be possible.
What I could possibly do, according to what I read in an previous reply
(from Jeremy Blain), is perhaps ask the browser to parse, through some
Javascript code, the content of the received page, and if it can find an
error flag, request an error page from the server. But this doesn't appear
very clean to me (and very efficient).
When you ask:
How important is it that the content be sent out to the client
immediately?
In fact, there are very complex algorithms run against quite a huge DB on
the server, and sometimes, it can take several seconds for the server to
compute the results. So, I think it's better for the user to see something
on screen, instead of waiting and believing nothing is happening because of
a blank page on screen.
Thanks,
Lionel MARTIN.
----- Original Message -----
From: "RJ Herrick" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, April 13, 2006 8:48 AM
Subject: Re: [Mason] Forcing redirection after some content has been flushed
to the client...?
"with the already sent content disappearing from screen?"
My understanding is that this cannot be done.
You would do a redirect by setting it in an HTTP header. HTTP headers need
to be sent before any content. As soon as you start to send ANY content,
the headers are sent to the client automagically by Mason (unless you've
already explicitly done it yourself.) You can turn off autoflushing, dump
the buffer on an error and send a redirect header (or perhaps even better,
do a subexec) or just flush once you've finished with no errors. But once
you start sending content you're committed to follow through.
However...
That's not to say that you can't decide to send DIFFERENT content
midstream. Say you send the HTTP headers, some page content (site header,
etc), then in processing your requested page's component you hit an error.
With autoflushing off you could clear the buffer and subexec the
appropriate component- you just need to make sure you're prepared to skip
any content equivalent to what you've already sent (HTTP headers, site
header, etc) on the subexec`ed component so that you don't end up with
oddly nested content. $m->is_subrequest might be a good check to use for
skipping or generating content, or you could pass your own flag with the
subexec.
How important is it that the content be sent out to the client
immediately? It would be easiest to buffer it all, so you can start fresh
if you need to dump and subexec.
HTH,
RJ Herrick
"Sometimes we're not having the same conversation."
Lionel MARTIN wrote:
Hi,
So, there's no way for my server to handle this kind of situation.
You're talking about CSS/JS to redirect or toss up the old content?
Do you have an example that could allow me to do that? And how this
CSS/JS
code could detect that it has to redirect?
Is what I'm asking commonplace or not?
Thanks,
Lionel MARTIN.
----- Original Message ----- From: "Jeremy Blain" <[EMAIL PROTECTED]>
To: "Lionel MARTIN" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Wednesday, April 12, 2006 4:45 PM
Subject: Re: [Mason] Forcing redirection after some content has been
flushed to the client...?
I can't think of any way to do this server side.
It could be handled on the client end for most cases with a little
css/javascript to either redirect,
or toss out the old content, and replace it with the new content.
Lionel MARTIN wrote:
But I'm wondering if there's a way for me to circumvent that, ie to
make my component generate and flush content as needed, but, if an
error happens, to force the browser to go to my error page, with the
already sent content disapearing from screen?
I hope I made myself clear.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
--
"A foolish consistency is the hobgoblin of little minds" -Ralph Waldo
Emerson
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
