Run PHP code inline on a Coldfusion page

For those of you who don't know, Coldfusion is built upon Java. Someone has taken it upon themselves to write a Java library, called Quertus, which parses PHP code. Someone else then built upon THAT and wrote a Coldfusion library which references the Quertus library and allows you to combine PHP and Coldfusion code on the same page, pass variables back and forth to each other and more. http://corfield.org/blog/index.cfm/do/blog.entry/entry/ColdFusion_8_running_ PHP I don't know what the speed is (probably not as fast as the native zend interpreter, but still...PHP code mixed in with CF code is pretty kick ass. I read that someone else has done the same thing for Ruby. ____________________________________ Andy Matthews Senior Coldfusion Developer Office:  877.707.5467 x747 Direct:  615.627.9747 Fax:  615.467.6249 amatthews@dealerskins.com www.dealerskins.com <http://www.dealerskins.com/>;

>PHP code mixed in with CF code is pretty kick ass. >I read that someone else has done the same thing for Ruby. I recently did almost the exact same thing with JSP (obviously a much simpler task considering CF is java based). I didn't bother posting the code anywhere because I thought it was simple enough and I couldnt really think of a reason outside of the specific project we were working on (migrating legacy JSP code to CF) to bother with JSP code snippets, but if you people want to see the code, I'm happy to share it. Does anyone even care about this stuff?

Great. The next time I get a project brief to uglify my CF code in an obscurely unnecessary way... I'll know what to do :) Seriously though, the genaral opinion here is it's not needed, but I argue that you never know when stuff like this will save your bacon. It seems more an enhancement for PHP than for CF.

That's pretty much how I see it. It gets PHP into an environment with clustering, DB connection pooling, portability and all the other things we can get out of J2EE. ----- Excess quoted text cut - see Original Post for more -----

The point I was making about PHP and ColdFusion is that it can be a selling point when talking to boss-types who don't know ColdFusion from nuclear fission. Maybe it's not that practical in real-life coding, but if it gets you the decision you want, then the real question is "why not?" Great. The next time I get a project brief to uglify my CF code in an obscurely unnecessary way... I'll know what to do :) Seriously though, the genaral opinion here is it's not needed, but I argue that you never know when stuff like this will save your bacon. It seems more an enhancement for PHP than for CF.

The real million dollar question is why would you want to? Almost anything PHP can do, CF can do. Almost anything CF can do, .NET can do. Almost anything .NET can do, PHP can do. Unless you want to take advantage of the thousands of crappy opensource PHP apps that are out there, but if that's the case, save some time and just open up your firewall. =] !k For those of you who don't know, Coldfusion is built upon Java. Someone has taken it upon themselves to write a Java library, called Quertus, which parses PHP code. Someone else then built upon THAT and wrote a Coldfusion library which references the Quertus library and allows you to combine PHP and Coldfusion code on the same page, pass variables back and forth to each other and more. http://corfield.org/blog/index.cfm/do/blog.entry/entry/ColdFusion_8_running_ PHP I don't know what the speed is (probably not as fast as the native zend interpreter, but still...PHP code mixed in with CF code is pretty kick ass. I read that someone else has done the same thing for Ruby. ____________________________________ Andy Matthews Senior Coldfusion Developer Office:  877.707.5467 x747 Direct:  615.627.9747 Fax:  615.467.6249 amatthews@dealerskins.com www.dealerskins.com <http://www.dealerskins.com/>;

"...why would you want to?" Two words: Cost-savings If CF can leverage existing apps written in other languages even to a modest degree, this greatly increases the value of ColdFusion. We are in this for the money, right? ...not just for the pure love of the ColdFusion gospel? The real million dollar question is why would you want to? Almost anything PHP can do, CF can do. Almost anything CF can do, .NET can do. Almost anything .NET can do, PHP can do. Unless you want to take advantage of the thousands of crappy opensource PHP apps that are out there, but if that's the case, save some time and just open up your firewall. =] !k For those of you who don't know, Coldfusion is built upon Java. Someone has taken it upon themselves to write a Java library, called Quertus, which parses PHP code. Someone else then built upon THAT and wrote a Coldfusion library which references the Quertus library and allows you to combine PHP and Coldfusion code on the same page, pass variables back and forth to each other and more. http://corfield.org/blog/index.cfm/do/blog.entry/entry/ColdFusion_8_running_ PHP I don't know what the speed is (probably not as fast as the native zend interpreter, but still...PHP code mixed in with CF code is pretty kick ass. I read that someone else has done the same thing for Ruby. ____________________________________ Andy Matthews Senior Coldfusion Developer Office:  877.707.5467 x747 Direct:  615.627.9747 Fax:  615.467.6249 amatthews@dealerskins.com www.dealerskins.com <http://www.dealerskins.com/>;

yep, that worked well for OS/2 ----- Excess quoted text cut - see Original Post for more -----

Kevin, Here's a couple of ideas that come to mind: A.  You're a hosting company and it's a lot simpler to all of sudden be offering PHP and Ruby hosting without having to install the extra bits on the server.  You have less maintenance and your clients programs run a bit faster than most other hosts. B.  You're a corporate site with some PHP apps (or there's one you would like to use), again much simpler with fewer chance of complication. C. You're a corporate site with a mixture of CF and PHP and the VP wants to move everything to one environment ( PHP) and rewrite the CF apps.  You can suddenly make a pretty good case for staying the course and running everything through CF-8. I am not saying integration isn't important too but I think Sean's onto something that could be much larger than you think. Rick Mason ----- Excess quoted text cut - see Original Post for more -----

> A.  You're a hosting company and it's a lot simpler to all of > sudden be offering PHP and Ruby hosting without having to install > the extra bits on the server.  You have less maintenance and your > clients programs run a bit faster than most other hosts. I would say this would not be the case.  You're still going to have maintenance issues because you've got extra software installed.  From what I've seen you also are not going to be able to automagically run existing PHP, Ruby, etc software out of the box, there would be a great deal of modification required to get the files to parse, BICBW. Damien McKenna Web Developer The LIMU Company

----- Excess quoted text cut - see Original Post for more ----- I have to agree this is little crazy -- how does allowing folks to combine PHP and CF make an ISP's job *easier*? Enabling php is as simple as adding mod_php to apache or IIS. That was easy. But installing all this stuff on top of ColdFusion (plus buying a ColdFusion license) and caching all the PHP into application scope on a shared server. Yeah -- that's easy ;) Easy to kill a server. I think about the shared hosting issues that TextDrive has on their LAMP+Ruby boxes and they *know* what they're doing. Adding CF to that mix and running the LAMP stuff through there.... argh. Move me to dedicated.. Wait a sec -- that must be the goal of their evil plan -- moving folks off shared. Seriously though, other than session integration with PHP, or some edge case of a tool that's simply not available for CF (eg you just *have* to run Sparklines from Ruby) it seems like a great feature for integration of existing sites and not much more. It's just like using Java for integrating with CORBA in CF -- not something I'm doing often, but glad to know I can. Sun's mantra has always been "the answer is Java, what's the question?" and making it *the* cross-platform JRE for all the web-oriented scripting languages is huge for them and their Solaris and hardware sales. Running CF, Python (using Jython), Ruby (using JRuby) and PHP (using this weird bridge and eventually Zend's native Java scripting compliant version) all on a Java server makes deployment and server management folks pretty happy IMHO. -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) ashenfelterj@transitionpoint.com

Actually, Quercus runs phpBB, Wordpress, Drupal and a bunch of other stuff essentially out of the box. Sean's using part of the Quercus technology to provide the CF integration, but it it is possible to deploy Quercus by itself in a J2EE server to make it run whole PHP apps. > From what I've seen you also are not going to be able to automagically run > existing PHP, Ruby, etc software out of the box, there would be a great > deal of modification required to get the files to parse, BICBW. -- mxAjax / CFAjax docs and other useful articles: http://www.bifrost.com.au/blog/

> > From what I've seen you also are not going to be able to automagically > > run existing PHP, Ruby, etc software out of the box, there would be a > > great deal of modification required to get the files to parse, BICBW. > > Actually, Quercus runs phpBB, Wordpress, Drupal and a bunch of other > stuff essentially out of the box. Quercus is one thing, embedded within CF8 is another due to the extra layers involved. > Sean's using part of the Quercus technology to provide the CF integration, > but it it is possible to deploy Quercus by itself in a J2EE server to make > it run whole PHP apps. Again, at that point you're taking CF out of the equation and dealing directly with the PHP runtime environment provided by Quercus, or JRuby (which is able to run the full Rails suite), etc. That said, it will be interesting to see exactly how much complication is added by running it through CF, Sean's experiment will be interesting to follow. Damien McKenna Web Developer The LIMU Company

Integration.  According to Forta, Integration is two of the three main goals of Scorpio. ~Brad The real million dollar question is why would you want to? Almost anything PHP can do, CF can do. Almost anything CF can do, .NET can do. Almost anything .NET can do, PHP can do. Unless you want to take advantage of the thousands of crappy opensource PHP apps that are out there, but if that's the case, save some time and just open up your firewall. =] !k

"pure love of the ColdFusion gospel?" Well we do have an "evangelist".  Preach it brotha' ~Brad

This reminds of the latest edition to .NET, the DLR.  Will we soon see CFML as a true compiled .NET language... I think so... Which is only a good thing. "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com "...why would you want to?" Two words: Cost-savings If CF can leverage existing apps written in other languages even to a modest degree, this greatly increases the value of ColdFusion. We are in this for the money, right? ...not just for the pure love of the ColdFusion gospel? The real million dollar question is why would you want to? Almost anything PHP can do, CF can do. Almost anything CF can do, .NET can do. Almost anything .NET can do, PHP can do. Unless you want to take advantage of the thousands of crappy opensource PHP apps that are out there, but if that's the case, save some time and just open up your firewall. =] !k For those of you who don't know, Coldfusion is built upon Java. Someone has taken it upon themselves to write a Java library, called Quertus, which parses PHP code. Someone else then built upon THAT and wrote a Coldfusion library which references the Quertus library and allows you to combine PHP and Coldfusion code on the same page, pass variables back and forth to each other and more. http://corfield.org/blog/index.cfm/do/blog.entry/entry/ColdFusion_8_running_ PHP I don't know what the speed is (probably not as fast as the native zend interpreter, but still...PHP code mixed in with CF code is pretty kick ass. I read that someone else has done the same thing for Ruby. ____________________________________ Andy Matthews Senior Coldfusion Developer Office:  877.707.5467 x747 Direct:  615.627.9747 Fax:  615.467.6249 amatthews@dealerskins.com www.dealerskins.com <http://www.dealerskins.com/>;

There's no way I would ever use (let alone purchase) such an animal. I'm sure I'm not the only one. Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ BlueDragon Alliance Member jordan@viviotech.net Robertson-Ravo, Neil (RX) wrote: > This reminds of the latest edition to .NET, the DLR.  Will we soon see CFML > as a true compiled .NET language... I think so... > > Which is only a good thing.

If by Cost-savings you mean having to hire 2 developers instead of one to support both/all code sets, than I'm at a loss for words. My point is that sometimes it's better to deal with the devil you know than the devil you don't... !k "...why would you want to?" Two words: Cost-savings If CF can leverage existing apps written in other languages even to a modest degree, this greatly increases the value of ColdFusion. We are in this for the money, right? ...not just for the pure love of the ColdFusion gospel? The real million dollar question is why would you want to? Almost anything PHP can do, CF can do. Almost anything CF can do, .NET can do. Almost anything .NET can do, PHP can do. Unless you want to take advantage of the thousands of crappy opensource PHP apps that are out there, but if that's the case, save some time and just open up your firewall. =] !k For those of you who don't know, Coldfusion is built upon Java. Someone has taken it upon themselves to write a Java library, called Quertus, which parses PHP code. Someone else then built upon THAT and wrote a Coldfusion library which references the Quertus library and allows you to combine PHP and Coldfusion code on the same page, pass variables back and forth to each other and more. http://corfield.org/blog/index.cfm/do/blog.entry/entry/ColdFusion_8_running_ PHP I don't know what the speed is (probably not as fast as the native zend interpreter, but still...PHP code mixed in with CF code is pretty kick ass. I read that someone else has done the same thing for Ruby. ____________________________________ Andy Matthews Senior Coldfusion Developer Office:  877.707.5467 x747 Direct:  615.627.9747 Fax:  615.467.6249 amatthews@dealerskins.com www.dealerskins.com <http://www.dealerskins.com/>;

I completely agree. We've had really good luck with using compiled .NET... !k This reminds of the latest edition to .NET, the DLR.  Will we soon see CFML as a true compiled .NET language... I think so... Which is only a good thing. "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com "...why would you want to?" Two words: Cost-savings If CF can leverage existing apps written in other languages even to a modest degree, this greatly increases the value of ColdFusion. We are in this for the money, right? ...not just for the pure love of the ColdFusion gospel? The real million dollar question is why would you want to? Almost anything PHP can do, CF can do. Almost anything CF can do, .NET can do. Almost anything .NET can do, PHP can do. Unless you want to take advantage of the thousands of crappy opensource PHP apps that are out there, but if that's the case, save some time and just open up your firewall. =] !k For those of you who don't know, Coldfusion is built upon Java. Someone has taken it upon themselves to write a Java library, called Quertus, which parses PHP code. Someone else then built upon THAT and wrote a Coldfusion library which references the Quertus library and allows you to combine PHP and Coldfusion code on the same page, pass variables back and forth to each other and more. http://corfield.org/blog/index.cfm/do/blog.entry/entry/ColdFusion_8_running_ PHP I don't know what the speed is (probably not as fast as the native zend interpreter, but still...PHP code mixed in with CF code is pretty kick ass. I read that someone else has done the same thing for Ruby. ____________________________________ Andy Matthews Senior Coldfusion Developer Office:  877.707.5467 x747 Direct:  615.627.9747 Fax:  615.467.6249 amatthews@dealerskins.com www.dealerskins.com <http://www.dealerskins.com/>;

What do you mean .NET?   "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com There's no way I would ever use (let alone purchase) such an animal. I'm sure I'm not the only one. Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ BlueDragon Alliance Member jordan@viviotech.net Robertson-Ravo, Neil (RX) wrote: > This reminds of the latest edition to .NET, the DLR.  Will we soon see CFML > as a true compiled .NET language... I think so... > > Which is only a good thing.

And from a BD alliance member I would say that you should be used to ColdFusion as a .NET language (albeit interpreted in it's current guise). "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com There's no way I would ever use (let alone purchase) such an animal. I'm sure I'm not the only one. Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ BlueDragon Alliance Member jordan@viviotech.net Robertson-Ravo, Neil (RX) wrote: > This reminds of the latest edition to .NET, the DLR.  Will we soon see CFML > as a true compiled .NET language... I think so... > > Which is only a good thing.

Oh I'm not knocking .NET integration. I'm sure that it helps a lot of folks. I'm just saying that I'd personally never use or buy a CFML server that was compiled in .NET. It's a personal fact, and I doubt I'm alone in that thought. That's all I was saying. ;) I commend NewAtlanta for spearheading the CFML/.NET integration idea. It's interesting to me that Adobe is playing catch-up in this regard. NA is clearly an innovative company and I'm honored that they allow me to carry the brand of one of their products in my signature. .NET just holds 0 interest or relevance for me. Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ BlueDragon Alliance Member jordan@viviotech.net Robertson-Ravo, Neil (RX) wrote: > And from a BD alliance member I would say that you should be used to > ColdFusion as a .NET language (albeit interpreted in it's current guise).

> If CF can leverage existing apps written in other languages > even to a modest degree, this greatly increases the value of > ColdFusion. Since PHP, Ruby, etc are free, the only possible value can come from integration between existing apps. I can see that value with Java, where I can use CF as essentially a replacement for a JSP view, but I just don't see much value for PHP integration. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! This email has been processed by SmoothZap - www.smoothwall.net

----- Excess quoted text cut - see Original Post for more ----- Except maybe integrating session data between sites that use multiple languages. I've been asked before to do things like mating a Ruby on Rails e-commerce application with a Drupal community site. Being able to share the session data directly seems (at least from THIS side of the project) a lot easier than trying to wrap each one as a service. Though IMHO, there are probably better ways to share common session data (typically login) using a single sign-on library like OpenID or the like. ----- Excess quoted text cut - see Original Post for more -----

> but I just don't see much value for PHP integration. You just *know* there are people out there who think running Drupal from within ColdFusion would be a good idea.  <shudders> Damien McKenna Web Developer The LIMU Company

> > but I just don't see much value for PHP integration. > > You just *know* there are people out there who think running Drupal from > within ColdFusion would be a good idea.  <shudders> Clearly those people have never tried to develop with Drupal :) That'll fix them. > > Damien McKenna > Web Developer -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) ashenfelterj@transitionpoint.com

> Clearly those people have never tried to develop with Drupal :) > That'll fix them. OTOH, it makes writing a Drupal->CF bridge a whole lot easier :-) And by extension, a Flex frontend to Drupal :-) -- Tom Chiverton, whos blog runs Drupal **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF.  A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged.  If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents.   If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com.

I can think of one real world example that I cannot do with CF at unless I'm on a 64-bit JVM. For me dropping into PHP to do that tiny bit would solve a whole host of albeit self imposed issues surrounding the use of CFHTTP to call a math function that returns a very large integer as the HTTP response string. In case you are wondering what task I need this for, it's to calculate Page Rank hashes. Paul

Yeah, PHP integration just seems pointless. If you want to do PHP, use PHP. "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com > If CF can leverage existing apps written in other languages > even to a modest degree, this greatly increases the value of > ColdFusion. Since PHP, Ruby, etc are free, the only possible value can come from integration between existing apps. I can see that value with Java, where I can use CF as essentially a replacement for a JSP view, but I just don't see much value for PHP integration. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! This email has been processed by SmoothZap - www.smoothwall.net

Simply because you personally immediately see the benefits of integrating PHP into CFML code, doesn't mean that the value is not there. It only means that you can't see it (yet). Personally, I see a lot I could do with this. One example would be that I've been using CFEXECUTE in conjunction with command-line PHP for a while now in order to generate high-quality image thumbnails. The GD libraries that are included in PHP are far superior to anything I've ever seen from a Java environment. With this innovation - I can just write PHP code right in the middle of my CFML code to generate my thumbnails. No funky code separation with CFEXECUTE - and much simpler variable sharing. Previously I've had to pass variables via command line attributes. This method is much simpler. > If you want to do PHP, use PHP. Haha - I don't even know where to begin with this statement. Isn't using PHP the whole point? And why just use one language when I can combine them and leverage the advantages of each? Silly human. =P The power and freedom to choose is *always* a good thing. Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ BlueDragon Alliance Member jordan@viviotech.net Robertson-Ravo, Neil (RX) wrote: ----- Excess quoted text cut - see Original Post for more -----

> The GD > libraries that are included in PHP are far superior to anything I've > ever seen from a Java environment. With this innovation - I can just > write PHP code right in the middle of my CFML code to generate my > thumbnails. Well, this innovation (thank you!) requires Java 6 so in terms of Adobe ColdFusion, that means CF8 since CFMX 6.x and 7 are not supported on Java 6. So if you're using CF8, you might just as well use CF8's built-in - and very high quality - image manipulation tools. Where I see this being useful is in taking existing PHP sites and integrating them partially or wholly into ColdFusion. Or taking open source PHP libraries and being able to use them with ColdFusion. If people show enough interest - and I can get some dedicated collaborators on the project - then it might be worth cracking open the source of Quercus and wiring it more tightly into ColdFusion to provide better native data support and library integration. Mostly, however, I did it for fun. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

There are a number of reasons to run PHP from a J2EE server using Quercus (as Sean's work does), rather than deploying PHP itself; 1) PHP should be run on a single threaded webserver, as some of the C libraries used in PHP apps aren't thread safe. This means running Apache 1, or Apache 2 in prefork mode. CF (for example) is quite happy running in multithreaded configurations of Apache. 2) The PHP apps automatically get the benefit of datasource connection pooling, clustering and all the other good things J2EE provides. 3) The PHP apps can integrate with Java objects and code. http://quercus.caucho.com/ > Yeah, PHP integration just seems pointless. > > If you want to do PHP, use PHP. -- mxAjax / CFAjax docs and other useful articles: http://www.bifrost.com.au/blog/

> 1) PHP should be run on a single threaded webserver, as some of the C > libraries used in PHP apps aren't thread safe. This means running > Apache 1, or Apache 2 in prefork mode. CF (for example) is quite happy > running in multithreaded configurations of Apache. Although I will point out that the way I've had to implement caching and script compilation, each individual script block has to be single threaded (although multiple *different* blocks can execute concurrently). I'm being conservative here because I'm not sure of the inner workings of the CompiledScript implementation in Quercus... > 2) The PHP apps automatically get the benefit of datasource connection > pooling, clustering and all the other good things J2EE provides. I haven't tried data source integration yet - that may require cracking open the Quercus source and hacking it around some (to get integration with ColdFusion). Remember that the ScriptEngine is running outside of its native Servlet environment. It *may* work out of the box (try it someone!) but it may well not. > 3) The PHP apps can integrate with Java objects and code. Yes, and in the docs for running PHP in CF8, I show how PHP can manipulate CF data structures (which are really just Java). That aspect is definitely very powerful. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

Thanks for the extra info Sean. I was mainly addressing the genenral "why bother?" question regarding running a PHP app on J2EE and it's good to know about the extra caveats when trying to integrate with CF in this way. ----- Excess quoted text cut - see Original Post for more ----- -- mxAjax / CFAjax docs and other useful articles: http://www.bifrost.com.au/blog/

> Simply because you personally immediately see the benefits of > integrating PHP into CFML code, doesn't mean that the value > is not there. It only means that you can't see it (yet). One could say the same to your reaction to .NET. But then one could be accused of snarkiness, I suppose. > The GD libraries that are included in PHP are far superior > to anything I've ever seen from a Java environment. Aside from that, which you've been able to integrate with CF via CFEXECUTE already, are there any other examples that come to mind? There just aren't that many things PHP can do that CF can't (and vice-versa). This might be useful when transitioning from one environment to another, but beyond that, I just don't see much value. Whereas with Java and .NET, I can see all sorts of value from integration - primarily, because those are the big areas where people are writing business applications and components (and not necessarily web-specific stuff). Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! This email has been processed by SmoothZap - www.smoothwall.net

Dave, >Aside from that, which you've been able to integrate with CF via CFEXECUTE >already, are there any other examples that come to mind? There just aren't >that many things PHP can do that CF can't (and vice-versa). I could see where being able to run some PHP code could be useful to a small company without a lot of developer resources. Maybe their trying to connect with a 3rd party software service and they have PHP example code, but no CF examples. Sean's project would give them an easy way to implement a solution without having to re-engineer the code. For those who are going to reverse engineer the code, it could be useful to run the re-engineered code with the original on the same page to see if the output matches. My last comment is where I could see it be useful to me--if it does indeed interpret the PHP code identical to the standalone version. -Dan

Dave Watts wrote: ----- Excess quoted text cut - see Original Post for more ----- Everyone knows I disagree with a lot of Microsoft philosophy, but I've honestly never had a problem with .NET integration. All I've said is that I would never use it. If it helps you, then good for you. It just won't help *everyone*. I've always believed in the freedom to choose. I see many similarities between .NET integration and PHP integration. I could say "If you want to do .NET, then use .NET", but that would be a foolish statement - wouldn't you agree? > This might be useful when transitioning from one environment to another, but > beyond that, I just don't see much value. Whereas with Java and .NET, I can > see all sorts of value from integration - primarily, because those are the > big areas where people are writing business applications and components (and > not necessarily web-specific stuff). I see where you're coming from, but that doesn't negate the potential usefulness of simply having the choice. -Jordan

There is absolutely no basis in this, why wouldn't you touch it?  CFML upon .NET would be the same as running CFML upon Java - it would probably run faster as well.  <cfif> on ColdFusion on .NET would be exactly the same as ColdFusion using Java etc. Is it just a stupid "anti-Microsoft" stance? I would say you are in the minority, certainly in the circles of technical fellows who understand and realise where .NET lies in the landscape.. I would be interested to see understand why it would have zero interest... "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com Oh I'm not knocking .NET integration. I'm sure that it helps a lot of folks. I'm just saying that I'd personally never use or buy a CFML server that was compiled in .NET. It's a personal fact, and I doubt I'm alone in that thought. That's all I was saying. ;) I commend NewAtlanta for spearheading the CFML/.NET integration idea. It's interesting to me that Adobe is playing catch-up in this regard. NA is clearly an innovative company and I'm honored that they allow me to carry the brand of one of their products in my signature. ..NET just holds 0 interest or relevance for me. Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ BlueDragon Alliance Member jordan@viviotech.net Robertson-Ravo, Neil (RX) wrote: > And from a BD alliance member I would say that you should be used to > ColdFusion as a .NET language (albeit interpreted in it's current guise).

Robertson-Ravo, Neil (RX) wrote: > There is absolutely no basis in this, why wouldn't you touch it? Because I'm a firm believer in choice - and I find .NET restrictive and limiting. > CFML upon .NET would be the same as running CFML upon Java False. .NET and Java are very different. Platform independence is one of the MANY ways that they are different. > it would probably run > faster as well. Presumption. > Is it just a stupid "anti-Microsoft" stance? It is a pro-choice stance. > I would say you are in the minority, certainly in the circles of technical > fellows who understand and realise where .NET lies in the landscape.. You make it sound like I'm denying the existence of .NET. I'm fine with .NET. If if helps you, then happy for you. I'm not denying that it can perform specific tasks. What I *AM* saying, (read this part carefully) is that it limits you in your choices once you invest in it. CFML, Java, PHP, and Ruby do not include this limitation, and also allow you to perform the same tasks that .NET does. So... why would I purposely chose to limit yourself when there are non-limiting alternatives available? > I would be interested to see understand why it would have zero interest... It's simple really: I enjoy freedom. -Jordan

"Haha - I don't even know where to begin with this statement. Isn't using PHP the whole point? And why just use one language when I can combine them and leverage the advantages of each? Silly human. =P The power and freedom to choose is *always* a good thing." Lol, silly human :-). Indeed, but the same rings true if .NET was involved as you would have even more choice of languages etc (devils advocate here :-) "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com Simply because you personally immediately see the benefits of integrating PHP into CFML code, doesn't mean that the value is not there. It only means that you can't see it (yet). Personally, I see a lot I could do with this. One example would be that I've been using CFEXECUTE in conjunction with command-line PHP for a while now in order to generate high-quality image thumbnails. The GD libraries that are included in PHP are far superior to anything I've ever seen from a Java environment. With this innovation - I can just write PHP code right in the middle of my CFML code to generate my thumbnails. No funky code separation with CFEXECUTE - and much simpler variable sharing. Previously I've had to pass variables via command line attributes. This method is much simpler. > If you want to do PHP, use PHP. Haha - I don't even know where to begin with this statement. Isn't using PHP the whole point? And why just use one language when I can combine them and leverage the advantages of each? Silly human. =P The power and freedom to choose is *always* a good thing. Warm regards, Jordan Michaels Vivio Technologies http://www.viviotech.net/ BlueDragon Alliance Member jordan@viviotech.net Robertson-Ravo, Neil (RX) wrote: ----- Excess quoted text cut - see Original Post for more ----- see ----- Excess quoted text cut - see Original Post for more -----

Hey Rick... just some comments: A. I know 5 or 6 owners of rather large hosting companies (10-20000) and not one thought it was a good idea. The concept is nice, but utterly pointless in regards to the overhead and added complications involved... if you really want to share sessions between PHP and Coldfusion, it can be done. If you want to integrate something from PHP to CF, it can be done. B. Like I mentioned, just use PHP. I don't see the need to have shared execution with this one at all. C. This brings us back to the question... what makes this a good idea? Why overly complicate something? I'm sure this might piss some people off, but I don't think Coldfusion is the be all and end all. I believe in using the right tool for the right job. Sometimes CF isn't up to the task and something else better suites the situation. The part of this conversation that scares me is that the whole thing runs around the idea of being able to swing PHP/.NET/Drupal (=]) guys over to CF because of what it could accomplish... and sorry to say, but that won't work either. PHP guys aren't used to PAYING for their environment... nor would any of them start to just because they see a few things that are neat. I've said this before and I'll say it again, Coldfusion will never take on the same amount of developers as PHP/.Net/Java while theirs a price tag involved for the standard edition. If they want a larger developers pool, than strip down the standard edition, give it away, and watch the money pour in for the added features and abilities of the Enterprise edition. And the funny part about how I know this...  I was the PHP developer who felt that way before my current job. !k Kevin, Here's a couple of ideas that come to mind: A.  You're a hosting company and it's a lot simpler to all of sudden be offering PHP and Ruby hosting without having to install the extra bits on the server.  You have less maintenance and your clients programs run a bit faster than most other hosts. B.  You're a corporate site with some PHP apps (or there's one you would like to use), again much simpler with fewer chance of complication. C. You're a corporate site with a mixture of CF and PHP and the VP wants to move everything to one environment ( PHP) and rewrite the CF apps.  You can suddenly make a pretty good case for staying the course and running everything through CF-8. I am not saying integration isn't important too but I think Sean's onto something that could be much larger than you think. Rick Mason ----- Excess quoted text cut - see Original Post for more -----

> C. This brings us back to the question... what makes this a good idea? Why > overly complicate something? While it may not be common, there are a lot of large organizations out there with multiple applications in multiple languages. Having a tool that can integrate these applications can be very powerful. Getting a couple of developers up to speed on CF to write some "glue" code to get, say a .NET app and a PHP app talking to one another may make more sense than completely porting applications to another language. This isn't just an abstract scenario - this is a potential solution to a real world situation I was in a year or so ago - two large (50+) development teams combined - one team was .NET, one was Java, and they wanted to create a system that could leverage apps from both teams. The "solution", at the time, was to choose .NET as the standard, and port all of the Java code. Ick. Now with CF8's .NET support, one or two developers could simply have created the "bridge" app, and the rest of the developers could have continued moving forward with either Java or .NET or both.

----- Excess quoted text cut - see Original Post for more ----- Though one could argue that today, the right solution would be to put web service (SOAP, REST, whatever) around the various services produced by each group in a SOA architecture. In that scenario, ColdFusion is not really needed to provide the bridge. Sharing objects directly is useful in some situations; sharing data though IMHO seems the more necessary integration challenge. -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) ashenfelterj@transitionpoint.com

So patch the problem and deal with it later? And who's best practices do you follow? And which company do you call when it breaks? Every example, though valid, is still an instance of the "easy" way instead of the "right" way... and that's fine if you're happy with that But I'm not... !k > C. This brings us back to the question... what makes this a good idea? Why > overly complicate something? While it may not be common, there are a lot of large organizations out there with multiple applications in multiple languages. Having a tool that can integrate these applications can be very powerful. Getting a couple of developers up to speed on CF to write some "glue" code to get, say a .NET app and a PHP app talking to one another may make more sense than completely porting applications to another language. This isn't just an abstract scenario - this is a potential solution to a real world situation I was in a year or so ago - two large (50+) development teams combined - one team was .NET, one was Java, and they wanted to create a system that could leverage apps from both teams. The "solution", at the time, was to choose .NET as the standard, and port all of the Java code. Ick. Now with CF8's .NET support, one or two developers could simply have created the "bridge" app, and the rest of the developers could have continued moving forward with either Java or .NET or both.

> So patch the problem and deal with it later? I didn't say it was ideal, but in a business situation when you have numerous, large legacy apps, and your choice is to spend a small amount of effort to do some integration,  vs. multiple thousands of man hours recreating the wheel simply so everyone is using the same environment, idealism often takes a back seat. And who's best practices do you > follow? Best practices aren't language-specific. You can institute practices that apply to everyone. And which company do you call when it breaks? Depends on what breaks. Since this is in-house developed software, it would be whomever wrote it who, one would presume, wouldn't be hard to find. Every example, though valid, is still an instance of the "easy" way instead > of the "right" way... and that's fine if you're happy with that If "easy" is (literally) millions of dollars in developer time cheaper than "right", "easy" quickly becomes "right". But I'm not... It's nice that you have that luxury. Not everyone does.

Porting functionality isn't interop though. That's a business decision to rewrite -- as well as bridge options now available to you you no doubt had Web services,   COM, Shared DB procs as options? "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com > C. This brings us back to the question... what makes this a good idea? Why > overly complicate something? While it may not be common, there are a lot of large organizations out there with multiple applications in multiple languages. Having a tool that can integrate these applications can be very powerful. Getting a couple of developers up to speed on CF to write some "glue" code to get, say a .NET app and a PHP app talking to one another may make more sense than completely porting applications to another language. This isn't just an abstract scenario - this is a potential solution to a real world situation I was in a year or so ago - two large (50+) development teams combined - one team was .NET, one was Java, and they wanted to create a system that could leverage apps from both teams. The "solution", at the time, was to choose .NET as the standard, and port all of the Java code. Ick. Now with CF8's .NET support, one or two developers could simply have created the "bridge" app, and the rest of the developers could have continued moving forward with either Java or .NET or both.

> Porting functionality isn't interop though. That's a business decision to > rewrite -- as well as bridge options now available to you you no doubt had > Web services,   COM, Shared DB procs as options? Absolutely. There are a lot of ways to skin the cat, and CF8 is looking like an interesting addition to that toolbox. My response is to the question "why bother", which always strikes me as a silly question in general, because even if it's not the right answer in MOST cases, in those cases where it IS useful, it's VERY useful.

Out of curiosity, why is that a problem with cfhttp? I can think of one real world example that I cannot do with CF at unless I'm on a 64-bit JVM. For me dropping into PHP to do that tiny bit would solve a whole host of albeit self imposed issues surrounding the use of CFHTTP to call a math function that returns a very large integer as the HTTP response string. In case you are wondering what task I need this for, it's to calculate Page Rank hashes. Paul

> Out of curiosity, why is that a problem with cfhttp? > Don't you think using cfhttp or any http client for that matter to perform what should essentially be a function call and handled either by a UDF or the language itself is a little bit of overkill? I guess I could always write a CFX tag in C++ or Delphi to achieve the same result but again, for the problem at hand, it seems like overkill. *BUT* As I write this, it occurs to me that if I were to write a C++ or Delphi CFX tag, I would be solving my particular real world problem in a way that is akin to the possibilities that Sean is showing us with the new capabilities that moving to Java 6 offers. Although the capabilities of Scorpio and their repercussions are much wider than the CFX interface provides for, the intent I believe isn't that different from CF 7 and below. ColdFusion has, since version 3 supported extending its capabilities by using alternative technologies like C++ and Delphi etc. When you consider this, the question then becomes, "If there are reasons to write non-Java CFX tags then why wouldn't there be reasons to use the capabilities that Scorpio will offer us in the future?" Paul

Doug, Don't get me wrong... I understand that in some circumstances, it's nearly impossible to implement what I'm talking about, but on the same token I had the choice to either provide the quick fix, or handle it the best I could when I took over a legacy app. Now 3 years later and I'm finally caught up and surpassed where this should be. Now it's easier to implement changes, fix issues and accommodate radical new ideas... but it was trying to say the least. I know that if I get hit by a bus tomorrow the company won't grind to a halt and that kind of security is something that any company can appreciate. I understand that this approach isn't for everyone, but in my experience it pays out big in the end. @@ !k > > So patch the problem and deal with it later? I didn't say it was ideal, but in a business situation when you have numerous, large legacy apps, and your choice is to spend a small amount of effort to do some integration,  vs. multiple thousands of man hours recreating the wheel simply so everyone is using the same environment, idealism often takes a back seat. And who's best practices do you > follow? Best practices aren't language-specific. You can institute practices that apply to everyone. And which company do you call when it breaks? Depends on what breaks. Since this is in-house developed software, it would be whomever wrote it who, one would presume, wouldn't be hard to find. Every example, though valid, is still an instance of the "easy" way instead > of the "right" way... and that's fine if you're happy with that If "easy" is (literally) millions of dollars in developer time cheaper than "right", "easy" quickly becomes "right". But I'm not... It's nice that you have that luxury. Not everyone does.

True, but if Adobe released a ColdFusion for .NET then you would have choice and granted if you couldn't use Windows (or don't) then it is out of the question! You eloquently cut out some parts of .NET v Java in my post,i never said they were the "same" as in identical my point is that if you write cfif/cfcomponent in either a ColdFusion for Java or ColdFusion for .NET the process to you is the same and in that way, since ColdFusion is a tag based languague you shouldn't need to care what gives you the result back.  Just like you are not programming in Java when you develop ColdFusion now, you will not be developing in C#, VB whatever (though you could). Personally, I think a  pure .NET version of ColdFusion will run faster on Windows due to the fact its components will be native whereas ColdFusion now is a myriad of components (ADO v .JDBC, .NET runtime v JRE) abeit doing an outstanding job.  I am not sure what DB/OS you are running but I would say a large portion of us run upon Windows and use SQL server and it is these users who would benefit from native support for drivers etc within Windows. The only way I can see .NET limiting you is to limit you to Windows and not much else.   You could leverage Java apps if you really wanted to just like CF8 allows you to interop with .NET now. What other limitations do you envisage? I ask this not provoke :-) but to forward a serious opinion to develop release a .NET version of ColdFusion, branded and approved as a .NET compliant language to allow for more native choice with ColdFusion. N "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com Robertson-Ravo, Neil (RX) wrote: > There is absolutely no basis in this, why wouldn't you touch it? Because I'm a firm believer in choice - and I find .NET restrictive and limiting. > CFML upon .NET would be the same as running CFML upon Java False. .NET and Java are very different. Platform independence is one of the MANY ways that they are different. > it would probably run > faster as well. Presumption. > Is it just a stupid "anti-Microsoft" stance? It is a pro-choice stance. > I would say you are in the minority, certainly in the circles of technical > fellows who understand and realise where .NET lies in the landscape.. You make it sound like I'm denying the existence of .NET. I'm fine with ..NET. If if helps you, then happy for you. I'm not denying that it can perform specific tasks. What I *AM* saying, (read this part carefully) is that it limits you in your choices once you invest in it. CFML, Java, PHP, and Ruby do not include this limitation, and also allow you to perform the same tasks that .NET does. So... why would I purposely chose to limit yourself when there are non-limiting alternatives available? > I would be interested to see understand why it would have zero interest... It's simple really: I enjoy freedom. -Jordan

Oh, I thought you were saying that you received an error when trying to cfhttp to a php page which returned a large number.  You were just saying it seemed like overkill. I'm guessing 32-bit CF doesn't support numbers large enough for you to do the calculations directly in CF code? I guess this would be a case where there was something another language like PHP (on a 64-bit machine, I assume) could do and CF could NOT do. ~Brad > Out of curiosity, why is that a problem with cfhttp? > Don't you think using cfhttp or any http client for that matter to perform what should essentially be a function call and handled either by a UDF or the language itself is a little bit of overkill?

> Oh, I thought you were saying that you received an error when trying to > cfhttp to a php page which returned a large number.  You were just > saying it seemed like overkill. Indeed. > I'm guessing 32-bit CF doesn't support numbers large enough for you to > do the calculations directly in CF code? > I guess this would be a case where there was something another language > like PHP (on a 64-bit machine, I assume) could do and CF could NOT do. > It's all to do with signed and unsigned integers and the fact the CF operates using signed integers whereas PHP uses unsigned integers. If CF supported unsigned math functions then a 32-bit JVM would be enough... Paul

> Because I'm a firm believer in choice - and I find .NET > restrictive and limiting. Is this solely because it requires Windows? If so, that's certainly a valid answer, but perhaps irrelevant to lots of people. > What I *AM* saying, (read this part carefully) is that it > limits you in your choices once you invest in it. CFML, > Java, PHP, and Ruby do not include this limitation, and also > allow you to perform the same tasks that .NET does. So... why > would I purposely chose to limit yourself when there are > non-limiting alternatives available? There are quite a few things that you can do with .NET that the other languages listed cannot, just as there are some things (like GD) that you can use from PHP. I submit to you that this list of things is pretty large, actually. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! This email has been processed by SmoothZap - www.smoothwall.net

Paul, ----- Excess quoted text cut - see Original Post for more ----- Just remember that even though it's interpreted PHP code, it's still compiled to Java--so you may still have the same issue. -Dan

The manual says PHP doesn't support unsigned integers either... http://www.php.net/manual/en/language.types.integer.php > It's all to do with signed and unsigned integers and the fact the CF > operates using signed integers whereas PHP uses unsigned integers. If CF > supported unsigned math functions then a 32-bit JVM would be enough... -- mxAjax / CFAjax docs and other useful articles: http://www.bifrost.com.au/blog/