Re: What is/is not considered to be good OO programming

From: André Næss (andrena.spamreallysucks_at_ifi.uio.no)
Date: 12/10/03 

Date: Wed, 10 Dec 2003 16:45:06 +0000

Tony Marston:

>> For that matter, the same argument can be made for using XSLT to
>> abstract your presentation layer. XSLT is overblown and introduces
>> nothing but delays, I find.
>
> Then your guys haven't learnt how to use XSL properly. It is a
> scripting language just like PHP, and as such you can make use of
> standard reusable modules. For example, in my sample application
> (which you can try online at

It's not like PHP at all. It's functional, for one, and that's actually
great. But the implementation is terrible, the syntax is a chore, and you
constantly find yourself having to go outside the language because it's so
constrained.

> http://www.tonymarston.net/sample/index.html) I have a family of 6
> components for each entity/table – list, insert, update, enquire,
> delete, search – for which I need only 2 (two) XSL stylesheets. Within
> each of these stylesheets I make use of the <xsl:include> and
> <xsl-call-template> functions to invoke common code. When I want to
> paint a data field on a form all I use is the following:
>
> <xsl:call-template name="datafield">
> <xsl:with-param name="item" select="tree_type_desc"/>
> </xsl:call-template>
>
> This template/subroutine then decides how to paint the field
> (display-only, single-line textbox, multi-line textbox, dropdown list,
> radiogroup, checkbox, whatever) using information supplied either in
> the XML file or as a parameter supplied at runtime to the XSL
> transformation process.

I've always found your love for XML and XSLT rather interesting considering
your other practices. How do you apply your beloved KISS principle in this
case? After all, what you propose is to do:

Data->Transformation to XML (presumably in PHP->XML->Transformation in
XSLT->Output

When you could do:
Data->Transformation in PHP->Output

Not only is the former much more tedious to actually implement, it's also
slower, and more prone to bugs because the pipeline is longer, meaning more
code, meaning more chances of bugs.

I'm not saying this is the case for you, but for anyone who are starting
out, who don't have your collection of modules and components, wouldn't you
agree that the XML/XSLT solution looks much more complex?

In short, I understand that you like it. But you can't really say "Now that
I've built a huge library of boilerplate code I can write my apps really
fast", and expect us to take this as an argument in favour of XML/XSLT. It
is an argument in favour of writing reusable code, but from this it is not
clear that XML/XSLT actually makes it easier to do so. So I think you
should explain why:

A) XML/XSLT using two transformations is better than simply doing a single
transformation.
B) XML/XSLT makes it easier to write reusable components.

> I suggest you learn to use XSLT effectively because it is here to
> stay. Version 2.0 is in the pipeline, and the recently-released
> standard for XFORMS (see http://www.w3.org/MarkUp/Forms/) which will
> do away with all that non-standard javascript, is based quite heavily
> on XML and XSL.

Well, I'd be surprised to see browser support for XFORMS get to an
acceptable level within the next 4 years :P As long as MS dominates they
have no incentive to improve their browser, and they will continue to
dominate :/

André Næss