Connecting PHP and Java

Have you ever had a project written primarily in PHP, but there were some java systems that you wanted to connect to? Perhaps there was a third party library or a java API that you really want (or are required) to use, but PHP had been chosen for other reasons.

The php java bridge is your solution. The documentation is good, and the performance is pretty darn good (if you’re looking for benchmarks, search for ‘How fast is it?’). You can use the bridge over sockets, a xml based protocol via servlets, or over a mono application. The mailing list is active, and it looks like the primary developer actually answers questions on said list (as of May 2007).

I’ve always been a bit hesitant regarding cross language programming: “Great, now I get to debug in two languages that communicate via sockets! Yahoo!”. But for a certain set of circumstances, using this bridge can be the right answer.

[tags]php, java, cross-language programming,php java bridge[/tags]

Review of MODx

Update 7/2010: Here’s a more recent review of MODx.  I’m bummed, but I have not yet had another opportunity to use MODx.

A couple of weeks ago, I mentioned I’d be reviewing MODx in the near future. I recently used it and was quite impressed by this project. It is a web CMS written in PHP with mysql as the datastore. I say ‘web CMS’ because MODx is designed to manage web content, as opposed to a more enterprisey CMS like StoryServer, which can manage all different types of content with complex workflows. You could use MODx to manage, say, printed brochures, but that would take some finagling. Web content is the sweet spot of this framework. Currently at version 0.9.5, it is fairly mature and ready for use.

I wanted to review MODx because I believe it deserves more attention, and as an example of how I’d evaluate an open source project, on the back end, rather than on the front end, of a project.

The good:

full featured

I was able to find everything I needed in MODx, or in the extensions repository. This included a thumbnail generator, email forms, integrated rich text editor, SEO friendly links, database updating forms, and a content redistributor (that syndicated content internally within the site).

admin interface

I think the administrative interface is excellent for non technical users. It’s responsive, and intuitive.

user access/authentication system

There’s a very well thought out access system. You can assign users to roles, which lets them access certain
functions in the admin interface, and groups, which define groups of documents that a user may modify. Here is more documentation on this feature.

defined development architecture

When you start working with MODx and you want to do something more than a cookie cutter website, you start hearing jargon, like snippets, plugins, chunks and template variables. All of these are MODx specific concepts, and it takes a while to wrap your head around them. But when you do, you appreciate the thoughtfulness of the architecture. In particular, you rarely have to modify existing source–there are hooks and easy ways to tie in custom code. (Most of these hooks are for the user side–to modify the admin interface, I had to hack some existing PHP.)


The MODx forums are the heart of the community. There are quite a few active members. I found the community to be very responsive and friendly to any questions I had, no matter how dumb.

a growing set of extensions

The MODx repository has a number of useful extensions. I especially liked that each entry in the repository is labeled with the version of MODx it supports.

active development

The project has gone from start up to 0.9.5 in less than two years.

open source

The license is GPL version 2.


You can turn on a simple form of caching, which will serialize a generated page to disk. Unfortunately, there’s no way to expire that cache. You can delete it, on a site wide or page by page basis, but you can’t say ‘expire the cached version of this page in one month’. Still, for many pages, this is an appropriate form of caching and can noticeably speed up the site.

The bad:


There is a ton of documentation for MODx, even a wiki. But I always felt like I was missing something–either it was hard to find what you wanted, or when you did, it wasn’t enough. An example is the API documentation. Here’s a sample function call that you’d make on the $modx object. No explanation of the returned data structure is available, and no actual example of how to call this function. I became very friendly with var_export($var,TRUE); and print statements to navigate these returned structures.

dependency on the database

MODx is very tightly bound to mysql. No problem there–mysql is a great database. But I mean, it’s really tied to mysql. By default, all code you write (see ‘defined development architecture’ above) is stored in the database. That’s not the place for code! Luckily, you can avoid that by using an include: include($modx->config['filemanager_path'].'/assets/libs/thumbs/thumbplugin.php');

This way, the code is on the file system, and can be versioned, etc. Also, since MODx depends on the database for so much functionality, make doubly sure you backup the database.

error messages in development

PHP syntax errors can be hard to track down. I ended up using a lot of command line debugging: php -l -f foo.php and looking in error log to see messages.

5000 document limit

This is a big one. Because of the caching mechanism, you can’t have more than 5000 documents in a MODx website.  However, this is acknowledged as a lack, and the team is working on it.

no search in specific forum

The forums are great, and are divided up into various sections. However, there was no way (that I could find), to search within a particular forum, or even within just the forums. This meant that when you were searching, you ended up with a lot of extraneous results.

Sure, MODx isn’t right for every site. But if you have a PHP savvy developer, a non technical userbase, requirements more complex than brochureware, and want to get a site up and running quickly, MODx is worth a look. As I’ve said before, use the right tool for the job.

Much thanks to the developers of MODx for putting together a great generic web CMS development platform!

Update 11/2009: HostColor offers MODx hosting for a reasonable price.  If you’re looking, check ’em out (click the CMS Hosting link).  Disclaimer: I make a bit of money if you visit them and/or sign up.

[tags]modx,php, web cms[/tags] doesn’t allow file uploads using php

I’m doing some work for a client using the MODx CMS. I will be writing more about that cool framework later, but I wanted to let the world know that hosting does not allow file upload via php scripts.

It doesn’t matter what your php.ini file says, the hosting environment doesn’t allow it. I was so astonished by an email telling me this that I called their customer service. Very politely, the fellow on the other end of the line repeated the prohibition. I asked “So, if I need file uploads, the only way to get them is to leave XO.” He was pretty uncomfortable, but said that was the case.

I guess has spoiled me. I simply can’t believe that a modern hosting service wouldn’t allow that kind of fundamental functionality.

Am I off base here? Do most hosting providers prohibit this functionality? Did I just not talk to the correct folks at XO?

[tags]php, file upload,[/tags]

Uploading a file in php using an iframe

I recently wrote a PHP file upload application. Yawn, right? There’s a manual entry on this task, which tells you just how often folks need to do it.

Well, I threw in a few new tricks–they were new to me at least. Basically, instead of posting to a page in the typical way, I post to a 1px by 1px invisible iframe, which then generates some javacript:

<form action="/upload.php" enctype="multipart/form-data"
method="post" target="target_upload">
<iframe id="target_upload" name="target_upload"
style="border: 0pt none ; width: 1px; height: 1px">


<script type="text/javascript">
if (parent && parent.uploadFinished) {
parent.uploadFinished(<?php echo $result;?>);
} </script>

The next question is how to communicate from the iframe, which is handling the processing, to the parent window, which is where the user interface is. The upload process parses the file and puts it in a database. If there are any errors, the parsing code ouptuts “0”, otherwise, it returns “1”. This value is passed to a javascript function which is written to the iframe. It looks something like the above, where the uploadFinished function basicly shows divs containing an appropriate message.

How is this superior from a regular page post? Not by very much. It’s not truly asynchronous–you still see the browser wheel spin. The only browser actions you can take while an upload is proceeding are those that open in a new window. That’s not much, but it’s more than a normal post allows you to do. In addition, this is relatively easy to do and you don’t have to deal with creating a new ‘successful upload page’.

[tags]PHP, file upload[/tags]

© Moore Consulting, 2003-2021 | Twitter