I have done both kinds of transformations. In fact, I currently work (as a
consultant - I have my own little business, really) at a firm that
specializes in data warehouses for the insurance industry. I wrote two XSL
stylesheets that create documents to describe (the descriptions are stored
as metadata in the warehouse, by the way) the elements in the warehouse.
One stylesheet produces an FO file that I feed to FOP and one produces
HTML files (one per element and some other files). At the same time, I use
XML as the storage and editing format for user guides and API guides and
other "conventional" documents and then use two other stylesheets to
produce PDF and HTML output for those documents. I also wrote the DTDs for
all of it, so I have had the luxury of defining the input that I
transform. I find that XSL supports either use case very well, provided
one works with the language rather than trying to force it work like some
other language. To that end, I use templates and recursion a lot and
rarely use for-each statements. One big template with a bunch of for-each
statements would strike me as ill-conceived whether the source of input is
a database or a document.
Of course, some people do write very long methods --
I have seen a method, whose code occupied 29 printed
pages. With such a beast the question "What does this
method do?" becomes very difficult to answer.
Unlike most of the folks on the list, I am a writer rather than a
programmer. I CAN program in half a dozen languages and have done so for
varying percentages of my job for 17 years, but I always do it as part of
helping my readers understand, not as the main task. (The exception is
actually XSLT and XSL:FO, which I use to create my output documents these
days.) From that point of view, I can tell you that a 29-page method would
be very unwelcome. The only time I've seen something like that (a 36-page
class) was from a C programmer who had been told to write his code in C++,
so the class was basically a wrapper for a C program. Anyway, enough
background.
If I may suggest a slightly different rule of thumb, I prefer "Each method
must have a goal that can be stated in one sentence." I have helped a
development team develop a new product that included an extensive API, and
we did very well by sticking to that rule. We did break it for classes,
but not often. We also stuck to the class=noun, method=verb idea, and that
helped a lot, too.
Anyway, I have wandered off topic, but "method, whose code occupied 29
printed pages" creates a certain gut-level reaction....
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--