-----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-----
