Clarification: Superglobals and Output Buffers

[Guest]

I have a few little questions I've been looking for clarification on...

1. Superglobals: Are they readily available inside class definitions? Or do I need to declare the superglobal as a global? (simpler said: can I access the $_SESSION superglobal from within an object?)

(are either necessary?)
[code]
class myClass{
    global $_SESSION;
}
[/code]
or
[code]
class myClass{
    protected $_SESSION;

    function __construct()
    {
          global $_SESSION;
          $this->_SESSION = $_SESSION;
    }
}
[/code]


2. Will changes made to superglobals work?

[code]
foreach( $_POST as $key=>$value )
{
      $_POST[$key] = htmlentities($_POST[$key], ENT_QUOTES, 'UTF-8');
}
[/code]


3. Is there a way to clear the contents of a webpage in case something goes wrong somewhere down the road in say, an AJAX request? (like ob_end_clean(), except without relying on the ob to have been initialized.) If not, am I right to assume that the output buffer must have been started before ob_end_clean() will work?

4. Once stored in an output buffer, is there anyway I can run something like a post-filter on the contents? Say if I wanted to change all instances of the word 'foo' with 'bar'...

Well, that's all on my mind, thanks in advance.

[wildteen88]

For question1 supergalobals are already global, as by thier name superglobals, you dont need to define them as global withina  function/class.

For questioin 2. Yes that should be fine. However you'll want to escape the value

I'm unsure abolut 3 and 4 thought

[ToonMariner]

On question 3....

If I have got this right.... You want to change the content of an element on a page with AJAX, and if ajax fails then you simpley use this

if (urRequest.readyState == 4) {
         // only if "OK"
         if (urRequest.status == 200) {
            document.getElementById('somediv').innerHTML = 'your stuff';
         } else {
            document.getElementById('somediv').innerHTML = '';
         }
      }


Question 4.

You have already done it!!!

$output = ob_end_clean(); // or $output = ob_get_constants() - have a read on teh differences

$output = str_replace($foo, $bar, $output);

or you can perform some regex to it....

[Jenk]

using ob_start() and related functions in unecessary in just about every scenario - so have a rethink of your design :)

ob_get_contents() is the function ToonMariner refers to, not ob_get_constants() :)

[ToonMariner]

ooops!!

Well spotted that mam! Another reason why you shoudl always check the manual or at least doa function lokkup - NEVER trust you own memory! ;)

PS ob_start (I feel is useful in creating large modular back-ends - I wouldn't use it on the front end though!!!!)

[448191]

[quote author=Jenk link=topic=108058.msg434764#msg434764 date=1158316387]
using ob_start() and related functions in unecessary in just about every scenario - so have a rethink of your design :)

ob_get_contents() is the function ToonMariner refers to, not ob_get_constants() :)
[/quote]

Output buffering can be VERY usefull:

1) Preventing of sending output (and thus headers) when you are still processing and headers can be added.
2) Manipulating the full output. For example gzip encoding

Before using DOMDocument I also used the output buffering functions, now I still use output buffering, only the buffer is the DOMDocument object.

BTW, ob_end_clean(); ends the output buffering and cleans the buffer, it doesn't ouput ANYTHING (ok, it returns a bool  :P)

Use ob_get_contents() BEFORE ob_end_clean() if you want to fetch the output for manipulation, otherwise simply use ob_end_flush() to 'flush' the ouput into the sewer called internet...

Gzip example:
[code]<?php
ob_start();
echo 'hjjcgjvjgcg';
header('Content-Encoding: gzip');
$ob = ob_get_contents();
ob_end_clean();
echo gzencode($ob,1);
?>[/code]

Be sure to check ACCEPT_ENCODING before sending gzip content to browsers though...

[Jenk]

use ob_end_flush() instead of two functions.

It's poor design to rely on output buffering, it uses much more resources than just outputting.

Those "useful" aspects you mention are just poor programming. If you need to send headers, you send them before any other output. Doing anything before you have completed the headers, you are very likely wasting processing time and system resources.

[448191]

I'm not going to start on this topic too... :P

[Jenk]

I'm not 'starting' I am merely stating fact.

the only vaguely valid method for using the OB is when using the output from an included file:

Page1.php:
[code]<?php

echo "Hello World!\n";

?>[/code]

Page2.php:[code]<?php

ob_start();

include 'Page1.php';

$var = ob_get_contents();

$var = strtoupper($var);

ob_end_flush();

?>[/code]

[448191]

Fine. Just remember you started it.  :P

Can I gzencode() using ob_end_flush()? I think not!

Sure I can use ini_set('zlib.output_compression') and ini_set('zlib.output_compression_level); but that also buffers output.

If I wan't to use gzip, output buffering MUST be used. Gzip can make a HUGE difference in traffic and latency.

Another reason: also performance related, server side caching.

Server side caching can circumvent A LOT of logic and thus dramaticly reduce time needed to display a page.

You need SOME type of output buffering for that. Wheter it be storing output in a variable or using the ob_* functions, you can't do it without buffering.

Your turn.  ;)

[Jenk]

[quote author=448191 link=topic=108058.msg434899#msg434899 date=1158329929]
Fine. Just remember you started it.  :P

Can I gzencode() using ob_end_flush()? I think not!
[/quote]First, read ob_gzhandler ;)

Second, you don't need to use the output buffer for anything, if you programme your application correctly. Zlib or no Zlib ;)

[code]<?php // poorly implemented.
ob_start("ob_gzhandler");

echo 'Hello World!

ob_end_flush();
?>

<?php
// better implementation

$output = 'Hello world!';

echo gzencode($output);

?>[/code]

The latter doesn't make use of the OB. It is still buffering, but it is much more efficient than use [i]php's[/i] Output Buffer.
[quote]
Sure I can use ini_set('zlib.output_compression') and ini_set('zlib.output_compression_level); but that also buffers output.

If I wan't to use gzip, output buffering MUST be used. Gzip can make a HUGE difference in traffic and latency.

Another reason: also performance related, server side caching.

Server side caching can circumvent A LOT of logic and thus dramaticly reduce time needed to display a page.

You need SOME type of output buffering for that. Wheter it be storing output in a variable or using the ob_* functions, you can't do it without buffering.
[/quote]Almost right - everything except the use of ob_* functions, these are not necessary.
[quote]Your turn.  ;)[/quote][url=http://dictionary.reference.com/search?q=sarcasm]Funny.[/url]

[448191]

[quote author=Jenk link=topic=108058.msg434923#msg434923 date=1158332143]
First, read ob_gzhandler ;)[/quote]

Geez, I really have to list everything when talking to you eh? ob_gzhandler SUCKS. You can't even set the compression level. I've never used it because of that. Not worth mentioning.

[quote]Second, you don't need to use the output buffer for anything, if you programme your application correctly. Zlib or no Zlib ;)
Almost right - everything except the use of ob_* functions, these are not necessary.[/quote]

Of course you don't NEED to use them to employ output buffering, I already said so much.

[quote]The latter doesn't make use of the OB. It is still buffering, but it is much more efficient than use [i]php's[/i] Output Buffer.[/quote]

I challenge that statement. Proof please.  8)

[quote=http://linuxformat.co.uk/wiki/index.php/PHP_-_Output_buffering]If you're not using content compression, [b]output buffering is very unlikely to affect the speed of your web server by any great amount - if anything, it should help it serve pages /faster/ because of the optimised data sending.[/b] Content compression does take up a little CPU time on both the server and on clients visiting your site, but it's pretty small. On the up-side, content compression should decrease the amount of bandwidth you use by 40-60%, which means your server will spend less time sending data across the network. The compression level you achieve depends entirely on the kind of content you serve up - if you have lots of pictures, which content compression won't affect, your compression level will be lower; if you're sending lots of XML, which is a naturally repeating format that is very easy to compress, your compression level will be much higher. It's important to remember that only the output of your PHP script will be compressed - images, CSS files, etc, are all served as normal.[/quote]

Hmmm.. faster eh? Ok, it's not exactly an exact measure, and it doesn't compare to buffer using variables, but it is something.

[quote=http://www.whenpenguinsattack.com/2006/07/14/10-php-speed-improvement-tips-for-apache/]Use output buffering (See ob_start). This will speed up your PHP code by 5-15% if you frequently print or echo in your code. [/quote]

Ok, now were talking. We have numbers.


[quote=http://www.undefinedfire.com/entries/strings-vs-output-buffering][b]It can easily be seen that output buffering is around twice as efficient over concatenation to a single string in the PHP world.[/b][/quote]

Wait... What happend? Concatenation (with .=) is about twice as slow as output buffering? Imagine that. He even has a diagram. Then it must be true! LOL... :P



Your turn.  ;D

[Jenk]

Ok, I stand corrected about performance implications. It's still improper programming to rely on it for the likes of late header calls. Now you prove to me otherwise.

[448191]

[quote author=Jenk link=topic=108058.msg434979#msg434979 date=1158336986]
Ok, I stand corrected about performance implications. It's still improper programming to rely on it for the likes of late header calls. Now you prove to me otherwise.
[/quote]

I won't because I 100% agree with that. I don't do it myself, but lazyness can sometimes make you do 'improper' things, like not full normalizing a database. If someone wants to do it, I can't think of any non 'structural design' reasons not to.