You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Thomas Klausner <do...@zsi.at> on 2005/08/06 14:20:13 UTC
mod_perl2 and PHP
Hi!
Is it possible and advisable to write the complex part of an application
(the Controller, if you like) in mod_perl2 and use PHP as a frontend (or
View) ?
While I personally prefere Template::Toolkit as a presentation language, the
project I'm currently getting involved in has quite a lot of PHP-people and
not that many (read: me) Perl people.
So what I thought is: use Perl to implement the rather complex business
logic, and PHP for rendering (and getting form input to the 'backend').
But: can I create a datastructure in Perl (in an ResponseHandler) and pass
it on to PHP running also as an ResponseHandler, but afterwards. Would I
need to stuff data in ENV? Can I pass complex data structures around? Do I
have to serialise (to yaml/xml) between Perl and PHP?
Or is this a bad idea altogether and I should use a different approach (Like
forcing everyone to read the Badger)?
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Re: mod_perl2 and PHP
Posted by Fred Moyer <fr...@redhotpenguin.com>.
Thomas Klausner wrote:
> Is it possible and advisable to write the complex part of an application
> (the Controller, if you like) in mod_perl2 and use PHP as a frontend (or
> View) ?
Here's an excellent thread on how to do just that if you are using
mod_perl 2:
http://marc.theaimsgroup.com/?l=apache-modperl&m=111073516415824&w=2
> But: can I create a datastructure in Perl (in an ResponseHandler) and pass
> it on to PHP running also as an ResponseHandler, but afterwards. Would I
> need to stuff data in ENV? Can I pass complex data structures around? Do I
> have to serialise (to yaml/xml) between Perl and PHP?
PHP supports BerkeleyDB, SQLite, and Storable
(http://cvs.jodrell.net/index.php/php-Storable/manual.html?r=HEAD&view=true,
but I don't know offhand if you can serialize with Perl and thaw with
PHP). Using Storable (if it works with both) and serializing the data
to environment variables is a less i/o intensive operation, but doesn't
give the added advantage of persistent data.
> Or is this a bad idea altogether and I should use a different approach (Like
> forcing everyone to read the Badger)?
If your coworkers already know PHP, this is a good idea. Create a php
include for them to deserialize the shared data and make it available to
their templates. And don't forget to write tests for the PHP filters :)
http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2004/testing-php-with-perl.pdf
HTH,
Fred
Re: mod_perl2 and PHP
Posted by Foo Ji-Haw <jh...@nexlabs.com>.
I agree with Eric. I love SOAP for the same reasons. You can argue until
the cow comes home and there will still be PHP lovers and Perl lovers
(and some .NETters as well). Diversity is important. But creating a
happy unity is key.
Eric wrote:
> At 10:07 AM 8/6/2005, Tony Clayton wrote:
>
>> Quoting Thomas Klausner <do...@zsi.at>:
>>
>> > Hi!
>> >
>> > Is it possible and advisable to write the complex part of an
>> > application
>> > (the Controller, if you like) in mod_perl2 and use PHP as a frontend
>> > (or
>> > View) ?
>>
>> It should be possible, perhaps by calling php from apache subrequests
>> in
>> the mod_perl code, but it won't be efficient, and doesn't sound very
>> pratical.
>> As an alternative, you might be able to use SOAP/RPC requests in the
>> PHP
>> code to offload the backend work to a mod_perl SOAP/RPC server. Again,
>> not very efficient or practical.
>
>
> I don't agree. Ok, sure there is some loss in performance(I choose
> XML-RPC because it is lightweight next to SOAP IMHO), but I did
> something very much like this for "social" reasons. Our bosses and
> many of our lower end people only know PHP. I had also to adopt to
> some affiliate system code that was and would likely forever be
> written in PHP. The solution was to use XML-RPC with PHP being the
> client and mod_perl/apache being the server. It is not that efficient
> in comparison to a pure mod_perl setup or even a pure PHP system for
> that matter. But it does end up being very scaleable because many PHP
> servers can be handled by one mod_perl backend. And it allows all of
> the presentation to be handled in PHP/Smarty by the people who know
> how to do that. While at the same time all of the code is in hopefully
> fairly clean oop Perl. :) It has turned out to be a great compromise
> for us.
>
> The best technical answer is not always the best answer.
>
> Thanks,
>
> Eric
>
>
>
>
>
>
>
> Lead Programmer
> D.M. Contact Management
> 250.383.8267 ext 229
Re: mod_perl2 and PHP
Posted by Eric <ef...@kwinternet.com>.
At 10:07 AM 8/6/2005, Tony Clayton wrote:
>Quoting Thomas Klausner <do...@zsi.at>:
>
> > Hi!
> >
> > Is it possible and advisable to write the complex part of an
> > application
> > (the Controller, if you like) in mod_perl2 and use PHP as a frontend
> > (or
> > View) ?
>
>It should be possible, perhaps by calling php from apache subrequests
>in
>the mod_perl code, but it won't be efficient, and doesn't sound very
>pratical.
>As an alternative, you might be able to use SOAP/RPC requests in the
>PHP
>code to offload the backend work to a mod_perl SOAP/RPC server. Again,
>not very efficient or practical.
I don't agree. Ok, sure there is some loss in performance(I choose XML-RPC
because it is lightweight next to SOAP IMHO), but I did something very much
like this for "social" reasons. Our bosses and many of our lower end people
only know PHP. I had also to adopt to some affiliate system code that was
and would likely forever be written in PHP. The solution was to use XML-RPC
with PHP being the client and mod_perl/apache being the server. It is not
that efficient in comparison to a pure mod_perl setup or even a pure PHP
system for that matter. But it does end up being very scaleable because
many PHP servers can be handled by one mod_perl backend. And it allows all
of the presentation to be handled in PHP/Smarty by the people who know how
to do that. While at the same time all of the code is in hopefully fairly
clean oop Perl. :) It has turned out to be a great compromise for us.
The best technical answer is not always the best answer.
Thanks,
Eric
Lead Programmer
D.M. Contact Management
250.383.8267 ext 229
Re: mod_perl2 and PHP
Posted by jonathan vanasco <jv...@mastersofbranding.com>.
i'm not a fan of php and mod_perl running in the same apache instance
my setup right now uses lighttpd as a frontend proxy + static file
server on port 80.
anything mp related is proxypassed to a mp2 bound to localhost on
port 8000
anything php related is proxypassed to a lighttpd server bound to
localhost on port 8100 that calls processes php as a cgi though fcgi
--even though its a phpcgi, the speed is comparable to apache and
mod_python because lighttpd has way less overhead
the only caveat on this setup, is that you can't run mod_security to
filter the php stuff on lighttpd (unless you run apache as the
frontend -- but its not as good at proxying or serving static files
as lighttpd).
i've been trying to tweak this setup for speed and security - apache
is built to handle things right, lighttpd is built to handle things
fast.
Re: mod_perl2 and PHP
Posted by Tony Clayton <to...@clayton.ca>.
Quoting Thomas Klausner <do...@zsi.at>:
> Hi!
>
> Is it possible and advisable to write the complex part of an
> application
> (the Controller, if you like) in mod_perl2 and use PHP as a frontend
> (or
> View) ?
It should be possible, perhaps by calling php from apache subrequests
in
the mod_perl code, but it won't be efficient, and doesn't sound very
pratical.
As an alternative, you might be able to use SOAP/RPC requests in the
PHP
code to offload the backend work to a mod_perl SOAP/RPC server. Again,
not very efficient or practical.
> While I personally prefere Template::Toolkit as a presentation
> language, the
> project I'm currently getting involved in has quite a lot of
> PHP-people and
> not that many (read: me) Perl people.
> So what I thought is: use Perl to implement the rather complex
> business
> logic, and PHP for rendering (and getting form input to the
> 'backend').
If they are keen to learn new stuff (perl) provided the learning curve
isn't too steep, then using HTML::Mason or embperl instead of TT might
be an easier sell as the concept and syntax is similar to php. I've
never used TT (and I'm certainly not knocking it), but from what I've
seen it's a whole 'nother language (albeit small) to learn. You'll
want to do some research on these before recommending them for a
project, of course.
> But: can I create a datastructure in Perl (in an ResponseHandler) and
> pass
> it on to PHP running also as an ResponseHandler, but afterwards.
> Would I
> need to stuff data in ENV? Can I pass complex data structures around?
> Do I
> have to serialise (to yaml/xml) between Perl and PHP?
In a previous project that involved both perl and php components, I was
successful in sharing nested data structures between the languages,
essentially by telling perl how to import structures from php include
files. In my case, we had legacy php pages that we were replacing with
HTML::Mason components, but needed to share data structures (menu items
and such) in the meantime.
Here's a quick synopsis. Create a file 'data.dat' like:
<code>
<?php
$data = array(
"Node 1" => array(
array("Node 1.1" => "foo"),
array("Node 1.2" => "bar"),
),
"Node 2" => array(
array("Node 2.1" => "baz"),
),
);
?>
</code>
Now, from a php script, do:
<code>
include("data.dat")
</code>
And from a perl script, do:
<code>
sub array {return [@_] }
my $data;
open FILE, "<data.dat";
my $script;
{local $/; $script = <FILE>; }
close FILE;
$script =~ s/^(?:<\?php|\?>)//msg;
eval $script;
</code>
You should be able to do nested data structures without a problem. You
can't marshall objects or references using this method. If simple,
nested structures will suit your needs, it should be easy enough to
create a data marshalling class in perl to create PHP structures from
perl structures.
EDIT: As an afterthought, I checked CPAN to see if there were modules
that did something similar, and found PHP::Include and
PHP::Serialization.
> Or is this a bad idea altogether and I should use a different
> approach (Like
> forcing everyone to read the Badger)?
If you are in a position of influence with a potential opportunity to
introduce mod_perl to PHP developers, then do the world a favour and
take that challenge. :)
Tony
Re: mod_perl2 and PHP
Posted by "JupiterHost.Net" <ml...@jupiterhost.net>.
Thomas Klausner wrote:
> Hi!
Hello,
> Is it possible and advisable to write the complex part of an application
> (the Controller, if you like) in mod_perl2 and use PHP as a frontend (or
> View) ?
>
> While I personally prefere Template::Toolkit as a presentation language, the
> project I'm currently getting involved in has quite a lot of PHP-people and
> not that many (read: me) Perl people.
That is a bummer ;)
> So what I thought is: use Perl to implement the rather complex business
> logic, and PHP for rendering (and getting form input to the 'backend').
So Perl does all the real work while eveyone else see's PHP and thinks
"wow look at how great PHP is"? boo for that!! :)
> But: can I create a datastructure in Perl (in an ResponseHandler) and pass
> it on to PHP running also as an ResponseHandler, but afterwards. Would I
> need to stuff data in ENV? Can I pass complex data structures around? Do I
> have to serialise (to yaml/xml) between Perl and PHP?
I think Storable may be able to be shared between Languages, maybe??
or
foo=bar
type file or xml but then you add another layer of complexity and
overhead but if you have to you have to :)
> Or is this a bad idea altogether and I should use a different approach (Like
> forcing everyone to read the Badger)?
I'd do that personally :) They'll be better off in the end to have
learned about Perl in addition to theri PHP skills.
PHP is cute and all but if it s all they do they'll remain stupid.
Re: mod_perl2 and PHP
Posted by Dominique Quatravaux <do...@idealx.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Geoffrey Young wrote:
>
> Dominique Quatravaux wrote:
>
>> $r->subprocess_env() (undocumented but present in mod_perl 1.3
>>
>> $r->internal_redirect() (again undocumented but present in
>> mod_perl 1.3
>
>
> unless you mean strictly in terms of what you're doing with php,
> this is certainly FUD
Sorry, my mistake.
- --
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC+GD4MJAKAU3mjcsRAvk0AJ0dZ3yI8BrXpgV6bO4P72zg30yFvQCfaAMR
xb6HSwtl4YNQNx1+H+OtRrc=
=REY9
-----END PGP SIGNATURE-----
Re: mod_perl2 and PHP
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Dominique Quatravaux wrote:
> $r->subprocess_env() (undocumented but present in mod_perl
> 1.3
>
> $r->internal_redirect() (again undocumented but present in mod_perl
> 1.3
unless you mean strictly in terms of what you're doing with php, this is
certainly FUD - perldoc Apache lists both of these methods, as do at least
two mod_perl books. you can also find them both documented on the mod_perl
website:
http://perl.apache.org/docs/1.0/api/Apache.html
fwiw, between the perldoc, online docs, and books I'd be willing to bet that
mod_perl 1.0 has practically no undocumented official APIs. 2.0 might be
less complete as a standalone API, but ought to be very close if taken with
the 1.0 docs. what's missing in 2.0-land are some of the more intricate
features that we're still discovering (like needing to remove the C-L header
when writing an output filter which, IIRC, _is_ in there :)
--Geoff
Re: mod_perl2 and PHP
Posted by Dominique Quatravaux <do...@idealx.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas Klausner wrote:
> Hi!
>
> Is it possible and advisable to write the complex part of an
> application (the Controller, if you like) in mod_perl2 and use PHP
> as a frontend (or View) ?
It definitely is, we did just that in my shop: there is some code at
http://idx-pki.idealx.org/download/index.en.html (have a look at
idxpki-v1.9.0/src/perllib/IDX/PKI/Registry.pm inside the tarball).
>
> While I personally prefere Template::Toolkit as a presentation
> language, the project I'm currently getting involved in has quite a
> lot of PHP-people and not that many (read: me) Perl people.
Pretty much the same rationale over here. It turned out to be a winner
for hitting a release quickly, but it does have drawbacks e.g. over
time I've been forced to write some view code and I *hate* PHP :-].
Also don't expect PHP to give you a hand for standards compliance
(e.g. making sure that all your Web pages are valid XHTML).
>
> But: can I create a datastructure in Perl (in an ResponseHandler)
> and pass it on to PHP running also as an ResponseHandler, but
> afterwards.
Yes. You can pass small amounts of data by messing with the GET
parameters (not POST, see below) using $r->, and large amounts of data
through $r->subprocess_env() (undocumented but present in mod_perl
1.3, and see Apache2::SubProcess for 2.0).
Then, in order to transfer control to PHP, you have to trick it into
thinking it's serving a PHP subrequest (for what it has built-in
support). You have force the method of the request to GET (lest PHP
tries to fetch the POST body again, and fail), and then invoke
$r->internal_redirect() (again undocumented but present in mod_perl
1.3, and see Apache2::SubRequest for 2.0).
There is some jockeying around with the variable names to correctly
get data across the PHP boundary: if you do $r->subprocess_env("FOO",
$value) from Perl, then you can retrieve $value from PHP by requesting
$_SERVER["REDIRECT_FOO"] (the REDIRECT_ part is added by the internal
redirection mechanism).
Sample code for all of this lies in
idxpki-v1.9.0/src/perllib/IDX/PKI/Registry.pm, around lines 1648
(internal redirect) and 976 (subprocess_env).
> Would I need to stuff data in ENV?
This is a third channel available (in addition to GET parameters and
the subprocess_env), but I would *not* recommend using it. The UNIX
environment has all sorts of bad properties for passing data around
inside a single process (see my rant at
http://marc.theaimsgroup.com/?l=apache-modperl&m=112005579327997&w=2).
In my case, we had issues of %ENV not being properly reset between
requests, which caused request data to "leak" from one page to another
in a nondeterministic fashion (due to there being multiple Apache
processes). Long story short - it caused a superb train wreck in
production. We could probably have dealt with the mess using a cleanup
handler, but relying exclusively on data structures that are
guaranteed to be destroyed at the end of the request is a much cleaner
solution IMHO.
> Can I pass complex data structures around? Do I have to serialise
> (to yaml/xml) between Perl and PHP?
YAML is a good move, I would probably go for it if I had to redo my
stuff. We used a recursive phpencode() function (look for it in
Registry.pm), which is a close cousin do Data::Dumper::Dumper(), but
returns a string that can be eval'd in PHP. This is quite easily done,
and works fine provided you make *really really sure* that eval'able
code only comes to PHP through a trusted channel, that is,
$_SERVER["REDIRECT_FOO"] for well-known values of FOO *ONLY*. Don't
eval stuff from the GET cmdline!
- --
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC9x4tMJAKAU3mjcsRAkdtAJ9MPGnM37M3+nydKCwvEHnLCy7wlwCfZnvq
GNiq9Ru6ZMfOryVqZBKnaew=
=S+4T
-----END PGP SIGNATURE-----