There are already a few posts on SO discussion whether this architecture is a good idea or bad idea. For many reasons within our company including the existing programming talent, we’ve decided to use Java for the backend and PHP for the front end. Our objective is something like…
Java – Models/Controllers
PHP – Views
We’re working on building a prototype of the interaction between Glassfish and Apache. One thing we’re still working on is when a user visits http://domain.com/login.html and they login, that login will be sent to the Glassfish controller which exists somewhere like
/login.java. We can do that no problem, the trouble is getting the view to be rendered at that URL.
Has anyone does this with PHP or any other technologies?
I am sorry to bring this up but it seems like it would make things a lot simpler to stick with just one of these languages. If you are using PHP to add more logic into your view, it might be worth taking a look at Velocity. It allows you to access and create variables, iterate through lists, use conditionals, define macros, make method calls, etc. This seems like it might make things much cleaner. However, it is usually a good idea to try to keep as much logic out of your templates as possible.
If you would like to use PHP because that is what is required I would suggest taking a look at using web services to communicate. Take a look at Googles GSON library. It is really nice tool (on the java side) for mapping JSON Objects to your model (and vice versa).
On your front-end, it might also be worth taking a look at Backbone. It is a tool that makes it simple to mock up your model Objects and bind events to them, or add tie them directly to fields, etc.
Have you considered setting up a soap/rest server in java and having PHP talk to that? I imagine that would be much simpler than what you’re trying to achieve.
I’ve had first hand experience at two companies that use the Java Service layer and PHP Client layer technology stack, although it was not used exclusively. To clearly separate the layers a well-defined JSON REST API was built so each layer had a contract it could code to.
The Java layer used SpringMVC in-between the persistence layer to generate JSON views with well-defined routes (i.e. URL structure) in order for the PHP layer to
Regarding the login issue specifically, there were actually two Java services, one specifically for login/logout and the other for the regular backend.
/login which I assume would be a
.php file. A submit of the login
<form> to the “Login” service resulted in a session cookie being added but also an encrypted “user ID” cookie. The encrypted cookie could then be used to protect access to the Java Service layer for the product. Each REST request from PHP to Java would have access to the cookie, and the Java layer could then decrypt the “user ID” and respond to the PHP REST call if it was valid. The Java layer would then have access to the real user ID in order to return user-specific data from the persistent store.