RE: Application Design

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

On Sat, 11 Aug 2001 Mike.Champion@SoftwareAG-USA.com wrote:

> Thanks for such a thorough response.  I think I need to learn more
> about PHP; my response took a more generic "procedural vs. declarative"
> spin.  It sounds like PHP (like XSLT) has a bit of both characteristics.

It's almost identical to ASP in many ways. It's different from JSP in that
JSP has the "custom tags" feature which is nice, but is harder to install
(classpaths get me every time with Java :-)

> The essence of my point is not that XSLT is better than PHP, but that
> presenting a unified XML view of a heterogeneous back office" full of
> different DBMSs, other applications, and assorted legacy cruft gives you
> lots more technology choices, lots more ability to use existing skills, and
> generally a lower "total cost of ownership" than gluing it all together with
> code to generate Web applications.  If PHP could replace XSLT in that
> overall scenario, I'd not complain one bit... but if you take the XML view
> out entirely, I think you're losing something very valuable.

If your back office is already all XML, then you're lucky, but just as
lucky as somebody whose back office is all SQL or CORBA, both of which PHP
backend onto. As well as XML and SOAP and all that. XSLT is very
XML-specific, although I have been wondering about the intriguing
possibility of salvaging it by defining "XPaths" for other types of input
than XML and subsituting those into XSLT. Imagine an XSLT engine with SQL
queries instead of XPath expressions, and some rules defining how the
result of an SQL query is turned into a string, number, boolean, or node
set ("SELECT COUNT(*) FROM ..." would make a number, for instance, while
"SELECT * FROM <table>" would produce a node set with one element node per
row, fields mapping into attributes). That might be neat!

> Sigh. Worse is Better. But that's the world we live in ... if you know
> someone selling passage on the next starship to a better world, let me know!

Actually, I may know a man...

...no, only joking :-)

> But seriously, in a world where "nobody gets fired for choosing X" (where X
> was IBM in the 1970's-1980's, Microsoft in the 1990's, and maybe XML in the
> next decade )... does someone do their clients a service to say "NO! X is a
> technically inferior solution!  Use Y (CDC, Mac, OS/2, X, whatever)
> instead"?  Maybe, but think of all the little ways it pays to just "come to
> the dark side, Luuuke" ... You get more choices of tools, a larger pool of
> experienced people, a high likelihood that there is some widget you can
> buy/borrow to do little obscure things, etc.  For example, let's accept for
> the purposes of this discussion the proposition that PHP is technically
> superior (in skilled hands) to XSLT for writing templates for generating web
> applications from back-end data sources.  BUT I can buy lots of books to
> teach newbies about XSLT, I can get free XLT engines for virtually any
> modern development platform,

So far this all applies to PHP, but:

> I can bet that community colleges are (or soon
> will be) teaching XSLT to most people getting an entry-level IT degree, I
> can buy "Visual XSLT" tools from several vendors ... is any of this true of
> PHP?

Although there is a visual PHP
tool:

http://marc.theaimsgroup.com/?l=php-general&m=98996546925996&w=2

(not that I've tried it), there remains to be PHP tought to most people
getting entry-level degrees :-)

However, you had to ask me that. Why don't you know already, so that you
can make a sensible choice betwen PHP, JSP, ASP, XSLT, etc? The root
problem lies there, my friends; information flow is still so sluggish in
the computing field. Progress is so fast that nobody can keep up with all
the new stuff coming out. Only the things that get high profile coverage
due to being associated with somebody the press is interested in get heard
about and blessed with hundreds of books and third party development.

Which is why people like me (who like digging into corners to find out
what's out there) get so irate when people jump on bandwagons, and this I
feel compelled to come onto XML-DEV and preach ASN.1, PHP, ONC-XDR, and so
on - lest you all get complacent and think you're on the bleeding edge of
technology or something :-)

I was pleased at the talk a while back about starting again with a simpler
XML. I'd contribute to that.

One word of advice: to keep everything in perspective, think about CSV
files. That textual format has been around for ages without changing the
world much. People use it as an interchange format or when interfacing
with Perl and UNIX shell scripts as a quick-to-define interchange format,
but rarely for "serious" interchange or storage (although I did once put
together a system involving transactions between companies defined using
CSV files). If XML is to fill *that* niche, it is to be no more complex
than CSV. If it is more complex, then it must fill another niche :-)

> [Disclaimer: Forgive my lack of dedication to "the right thing," but as a
> former OS/2 weenie, I got burned by being on the wrong side of the "but Y is
> technically superior to X!!!" issue back in the early '90's. Back then, OS/2
> was "technically superior" to Windows 3.x ... but Windows had the books, the
> components, the people, the vendors, the visual tools, the hype, (the
> illegal monopoly, but we won't go there!) ... and time on its side so that
> MS sooner or later got the bloody thing to work right.]

Yep, and we're still suffering as a result (Win NT has kinda caught up
with OS/2 in most respects, but still...). Fight now before XML does the
same! :-)

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