Comments for Michael Caplan

Comment on Leveraging Omnis within a Heterogeneous Environment through Remote Studio by Paul Mulroney

Paul Mulroney — Thu, 22 Jul 2010 03:33:50 +0000

Well written article. Well done rewriting rStudio!

Comment on Mayday, Mayday, Mayday - PHP Going Down by andi zaugg

andi zaugg — Tue, 11 May 2010 12:44:24 +0000

cool!
thank you very much!

Comment on Mayday, Mayday, Mayday - PHP Going Down by Christian S.

Christian S. — Tue, 15 Dec 2009 11:34:27 +0000

Hey, I am happy about this blog entry. I searched for a solution to catch fatal errors and with Your help I could solve my problem
Thank You very much!

Comment on Mayday, Mayday, Mayday - PHP Going Down by Claude

Claude — Thu, 22 Oct 2009 18:55:58 +0000

Please change the title of your article to something more search engine friendly. Something like this would be much better:

PhP Fatal Error Handling

Comment on Mayday, Mayday, Mayday - PHP Going Down by rob

rob — Sun, 10 May 2009 15:51:30 +0000

I would not have thought that register_shutdown_function could catch E_PARSE, when even set_error_handler cannot. This is great, thanks!

Comment on Don’t Forget to Flush by Michael Caplan’s Blog: Don’t Forget to Flush : Dragonfly Networks

Michael Caplan’s Blog: Don’t Forget to Flush : Dragonfly Networks — Fri, 09 Jan 2009 10:58:27 +0000

[...] this recent post to his blog Michael Caplan looks at a feature of PHP that’s sometimes forgotten when pushing [...]

Comment on Don’t Forget to Flush by Mikael

Mikael — Wed, 07 Jan 2009 11:54:06 +0000

Whoops, missed the last paragraph… sorry !

Comment on Don’t Forget to Flush by Mikael

Mikael — Wed, 07 Jan 2009 11:52:24 +0000

I love the idea, but that is probably not gonna work in most MVC frameworks that implement the ‘two-step’ view way of rendering views.

As an example with ZF, as Loïc mentionned: if you use Zend_Dojo or Zendx_jQuery in conjunction with Zend_Layout, you don’t build the HEAD content in one single spot in your code. It is done in several places, and this makes it hard to use a flush.

Example:
- Take a random, database-heavy page that is included in a default layout (= template). This is where most of the computing time is spent. That page then decides it needs some obscure plugin js file. That page is rendered. So far you can’t send anything to the client.
- Then the layout decides that it needs a general use JS library. The layout is rendered and it then includes (wraps) the previously rendered page.
All work is done, the full response (head + body) are computed and can be sent back to the client. Nowhere in this scenario could you do a flush.

I’d love to hear a solution to this (or maybe I’m plain wrong ?), because this sounds like it could really speed up JS heavy webpages.

Comment on Don’t Forget to Flush by Loïc Hoguin

Loïc Hoguin — Mon, 05 Jan 2009 10:15:24 +0000

About nested templates, I’m not sure about ZF but you could probably have a header template that you would create and render as soon as you receive the request, and then have a body template that would contain the rest. The HTML header usually doesn’t have too much specific code so it should work out pretty well for most projects.

Comment on Don’t Forget to Flush by ellisgl

ellisgl — Mon, 05 Jan 2009 02:50:27 +0000

Beware of using flush by itself. Some times you have to make sure that you have enough data output before the browser response. Here’s something I’ve been using with my COMET stuff.

function RealFlush($Out = “”, $Padding = 4096)
{
echo str_pad($Out, $Padding);
@ob_flush();
@flush();
}