I have a few application design questions that I was hoping someone might have some thoughts on. I'll warn you in advance that this post is kinda long winded. I'll try my best not to use two many trendy buzzwords, but I may not be able to avoid it. :-)
I work for a real-estate company and one of the functions of our website is to (obviously) allow customers to search our listings database. I currently have a fairly straightforward set of PHP pages that accepts search criteria, constructs SQL queries, and then displays the listing data. For quite some time this was more than sufficient for our needs. Recently we added a new application to what we provide that allows customers to sign up to receive new listing notifications based on a certain set of search criteria. I was charged with the responsibility of creating this application. I decided (for various reasons) to implement this application in Perl. As I was putting the Perl script together I realized that I was going to have to duplicate all of the business logic that existed in my PHP pages to build the SQL queries and display the results. For example, different listings have different rules for display. Some bits of information cannot be legally displayed based on the location the listing is in. All of this business logic was wrapped up tightly inside my PHP pages, and I realized I was going to have to implement it again in my Perl script. Worse yet, I realized that if any of this business logic changes (which it often does), I was going to have to remember to change it in TWO places. Up until this point there was only the website, but now that I had two completely seperate applications that I have to maintain whenever anything changes. I realized at this point that I would be really nice if the business logic that determines how to construct the queries and which bits of data to display were completely seperated from the presentation logic that existed in my PHP pages. If I had some sort of component that merely accepted search parameters and returned data then I could access this component from both the PHP page and the Perl script. If the business logic changed later I could simply update the component and I (theoretically speaking) wouldn't have to touch the PHP page or the Perl script. I've been doing research into this kind of application design. From my limited and inexperienced perspective, it does appear that Microsoft does offer some advantages in this area. But COM is not an option for me, for several reasons, not the least of which is the fact that our servers run Linux and I cannot access PHP's COM functions. I have considered setting up a PHP page that runs on a seperate port. This page would accept search criteria via a query string, and then return listing data in XML format. Then on the PHP presentation side (or my Perl script), I would parse the XML and either display it manually, or use XSLT. I don't have a lot of experience with this, however. It seems that XML support in PHP is still in a state of infancy. I'm aware of Sablotron, and I have successfully compiled PHP with Sablotron support. But I've read articles that the SAX implementation that PHP employs is inferior that the DOM model. I've also read that the PHP developers are working on improving the support for XML and XSLT by using libxslt instead of Sablotron in later versions. After reading all of this, it seems like the best thing to do is to wait a bit until XML support in PHP solidifies a little more. Also, I am concerned that the overhead of connecting via TCP (even if on the same physical web server), having a page generate XML, receiving the response, and then having to parse it back out again, might impact peformance too severely. On our website, the most popular thing is searching listings. If I drastically reduce responsiveness by adding all of this overhead, then I've made things easier for programmers, at the expense of the end user. Another technology I was toying around with is Java servlets and Java Beans. I'm a complete newbie when it comes to this stuff too, but from what I've read it seems that Java Beans are designed to wrap up business logic in reusable components. Money is an issue, however, so if I implemented anything in Java I would have to use Apache's Tomcat, and not one of the commercial Java platforms. I realize this is wildly off-topic for this list, but if anyone here has any experience with Tomcat I'd appreciate any advice (off-list if necessary) as to whether I'm barking up the wrong tree or not. :-) Thanks in advance to any advice anyone can give... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
