Re: Passing data into the PHP Bric Burner

[email protected] (George Schlossnagle) Tue, 24 May 2005 10:05:38 -0400
Newsgroups perl.php.sandwich.dev
Message-ID <[email protected]>
On May 24, 2005, at 12:56 AM, David Wheeler wrote:

> On May 23, 2005, at 20:39 , George Schlossnagle wrote:
>
>
>> I guess my question is, does anyone have any other ideas, or not  
>> buy idea 2?
>>
>
> I'm assuming that this is not exclusive to using Perl modules and  
> their data directly from PHP, correct?
>
> I should note, however, that I'd like to be able to pass data  
> structures to PHP, not just strings.

You can do that now - see the test cases for examples of passing  
complex types between PHP and Perl.

The question, in a bit more detail, is this:  what is to be the  
standard way that PHP will be first called from Perl in burn_one().   
To me, this feels right:


$perl->include($file, $arghash);

And that under the hood this is equivalent to doing this in PHP:

<?php
include($file);
?>

In PHP, include doesn't support the passing of parameters.  The way  
that PHP scripts get data passed from the outside world is that  
request data (query params, post data, cookies, etc.) are populated  
in so-called autoglobals ($_GET, $_POST, and $_COOKIE, etc.).  Due to  
scoping semantics, these are tied to the active interpreter request  
and not to the current include being processed.

What I think should happen is this:  the PHP::Interpreter method  
should work like one of these two ways:


$php = PHP::Interpreter->new({ GET => { ... }, POST => { ... },  
COOKIE => { ... }, BRIC => { ... });
$php->include($file);

This lets you set the usual autoglobals that are available inside  
PHP, plus adds a new one $_BRIC, which acknowledges that the data  
passed in for this template is 'special'.

The other option is to do this:


$php = PHP::Interpreter->new({ GET => { ... }, POST => { ... },  
COOKIE => { ... });
$php->include($file, BRIC => { ... });

In this case, there are two things that can happen:

1) BRIC replaces the old BRIC
2) BRIC is merged into the old BRIC
3) We do some sort of artificial scope limiting, which would be  
really un-PHPish and bad, so I only bring it up to note that it was  
considered and turned down.

George