RE: Application Design

[Al Snell <alaric@alaric-snell.com>]

On Thu, 9 Aug 2001 Mike.Champion@SoftwareAG-USA.com wrote:

> OK, this sounds like an interesting challenge ... why DO XML advocates think
> that it is good for problems such as this.  I'd start with:
>
> 1) It's not a programming language, just data.

No, it's a programming language. I'm not sure if it's turing complete, but
writing XSLT is definitely a programming task. PHP source code is, also,
just data - but it's the semantics on top that count :-)

> You don't need to care
> whether PHP (or whatever) programming environment is supported on your
> platform of choice.

It'd be nice if XSLT was supported! What do you mean?

> Instead of writing procedural code that directly calls
> the database, use a "virtual database", XML server, or the XML mapping tools
> from the RDBMS vendor to pull out an XML view of the underlying data. You
> can then use a vast array of tools, techniques, and products to manipulate
> it from pretty much any development environment.

Same with SQL databases; what difference is there?

> 2) It's declarative (well, sortof anyway ... XSLT has certainly got lots of
> procedural aspects to it), which means that you specify "what, not how".
> You can focus on what you do best (which for most of us is *not* designing
> optimized, scalable, multithreaded, robust system software).

You don't need to be able to do that to write templates in PHP. If you
*do* need optimized, scalable, multithreaded, robust system software then
your needs are different.

> 3) XSLT in particular has a good story (on paper, and increasingly in
> reality) for supporting changing output requirements.  You need to support
> some HTML subset or WML for wireless?  Write another stylesheet. You need to
> put out the data in your industry's new XML schema?  Write another
> stylesheet.

Or write another template in PHP or whatever!

> In a programming/imperative architecture, you get to write the
> same code over and over again; OK, maybe you can modularize your code well
> enough to do this cleanly (after a few trips around the spiral model or
> after a few Extreme Programming refactorizations),

Not true... if modularising back end away from front end is that hard,
then XSLT would be a big pain in the ass. Why? because for an XSLT side,
you need a backend engine that makes the XML and the XSLT frontend. You
need to decided what to put where. Do you make the backend calculate the
totals to put at the bottom of the table, or do you use a sum() XPath in
XSLT? etc, etc. But with PHP or something you can move things between
backend and frontend much more easily since they're the same language, and
backending something just means wrapping it in a function declaration and
popping it in a different file.

> but you still need a
> programmer skilled in your specific environment to do each new output
> format.  XSLT editing tools are getting good enough so that it's not a big
> stretch to think that a person with ordinary web design skills will be able
> to do the stylesheets in the near future.

I've had people with only web design skills writing PHP templates. They
don't need to learn to program; they need to learn to call functions from
in their HTML.

...<title><?= title() ?></title>...

> 4) Portability. If the new boss comes in, decrees a move to a different
> server, development environment, whatever ... and you mention that all that
> PHP code you were responsible for creating will now have to be re-written in
> C# (or whatever), you are NOT going to be first on the list when the bonuses
> are distributed.

If he decides to move away from XSLT, you're just as shafted. If you want
the backend code that does the maths and queries the database to get the
raw data for a bill of materials to format into XSLT rewritten, you're
just as shafted. Just because you use XSLT instead of PHP for the
templates doesn't make you any less likely to have to port to a different
language! PHP is just as portable as XSLT, I reckon - at least, it's been
around to be ported for longer, and runs on anything that will run Apache,
I reckon.

> 5) Interoperability. Let's say you are asked to support some additional
> system (within your enterprise or from a partner company), that provides
> data for your website, or that your web application must update.  If you
> build the original system on XML, the chances are awfully good that the
> other system will have some sort of XML-enablement story, and you can
> rewrite the stylesheets to incorporate the additional input source.  If you
> built the original system with procedural code, you're going to have to
> figure out the remote system's APIs, protocols, data formats, etc. and
> either shamelessly hack or spiral around/refactor the code once again to
> handle them.

I thought XML was supposed to solve that problem :-)

If the remote system provides an XML interface, you can access it from PHP
too, you know :-)

Anyway, to summarise, your main point seems to be that XSLT is different
from any other programming language in some major way. It's very domain
specific, yes; but there is a very similar subset of PHP, and consider JSP
with custom tags too!

I have run a very successful Web project which had programmers writing the
engine in PHP as sets of classes and functions, and the front end people
telling them what they needed ("I want a function that returns the name of
the town the user has selected, but prettied up - rather than use the
capitalisation and spelling they entered, can we return the spelling that
was found in the database?") and (using a shared document describing the
list of functions available, which is equivelant to the DTD of the
exchanged XML in an XSLT model) writing HTML pages with tiny PHP function
calls embedded.

The advantage of using PHP on both sides, and a function call API
interface inbetween was:

1) Since we are calling functions when we want data, rather than having to
generate an XML page in advance and let that be queried, the back end only
does expensive queries if the frontend decides it wants it. To get the
same effect with XML we would have to have backend logic that *recognises
the cases where the front end WILL want that data*, thus bringing frontend
logic back in.

2) Adding a new function to the backend and documenting it is less work
than adding that function and adding the glue code to call it and convert
results to XML and poke them into a DOM tree, documenting the function,
*and* updating the XML DTD, thus allowing for a more flexible and
responsive communication between developers and designers when
experimenting with stuff.

3) The developers were happier with PHP's syntax when they made their own
function libraries of common page navigation that was shared by lots of
pages. Compare:

function output_page_header($title,$up_link_url,...) {
?>
<html><head>...<title><?= $title ?>...
<?
}

against:

<xsl:template name="page_header">
  <xsl:with-param name="title" />
  <xsl:with-param name="title" />
	...<title><xsl:value-of select="$title" /></title>...
</xsl:template>

And this isn't my idle conjecture. This is real world, multi-million pound
project, money saving. We didn't need XSLT and PHP experts and books to
support XSLT and PHP developers; just PHP experts to support PHP
developers and the designers who used the occasional looping or
conditional construct. We didn't need to install PHP and XSLT, just PHP.
This meant that we needed less software in memory for each hit on the web
site, and memory was the limiting factor for our server's performance, so
hardware money was saved. Using XSLT would have caused a lot of problems,
and I can't see any problems it would have solved.

Recently, that company is starting to move over to an XML/XSLT model. When
asked why, the person who made this decision said he didn't know what the
technical issues were (he was a manager) but he'd read a lot of magazine
articles and stuff saying that XML was the wave of the future so they'd
better "catch up". Eurgh! What a way to make a technical decision! :-)

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software