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

Reply via email to