Customer Reviews

Program Generators with XML and Java

5 star:		(5)
4 star:		(2)
3 star:		(0)
2 star:		(3)
1 star:		(0)

 

 

I would have given 4½ stars...

Why do I like this book? The author explains how code generation can be used to separate concerns when programming. He compares program generation to the use of run-time configurations, separation of concerns the way it's done with frameworks, with aspect oriented programming etc. What these technologies have in common is, that they try to figure out what a problem domain is really about - what is common between all applications needed in the domain, and what are the differences. Program Generation is ONE of several possible ways of making the common stuff once, while making 'configuration' of the stuff that varies from app to app as easy as possible.

What I like is he doesn't use a lot of pages explaining the technologies he uses (like most other books do). He expects the reader to know Java and XML - and only includes short resumes(including DOM, XSLT). He shows severel different ways of generating code, explained in an interesting, understandable, babble-free way.

On the down-side, you are sometimes wondering why you are reading what you read - after a while you figure it out. I would have preferred a short introduction to each chapter explaining WHAT it is about, and WHY it is relevant...

I have been working on program generators on and off for many years, and just recently completed a project using Java and XML to generate a variety of output files. This book hits on some of the key issues I encountered and provides insight towards solutions to these problems. This book will be a good read for anybody new to writing program generators, and provides useful information even to those who've been doing it.

Agreed that XML may not be the best language to capture domain
specification expressiveness. But use of XML/XSLT to do
custom code generation has the benifit of rapid application
prototyping and development. The crucial fact is that the
domain specification is captured in XML only relatively few times
and project software developers mainly use the generated code.
The question is how many people in the project is exposed
to 'ugliness' of XML and how many times. The advantages
of 'neat' code generation far outweigh the disadvantages
of 'ugliness' of domain specification in XML.

In a real Network Management Software development I achieved
60% of generated code (EJB, SNMP, Java utilities) by using
custom code generation by XML/XSLT. Only myself dealt with
XML other software developers happily used generated code. You
can imagine the lead the project had and continues to have
because of use of XML/XSLT in project specific custom code
generation. The code generation system is stable now -- any new
addition in EJB, SNMP model results in thousands of lines of
Java/SQL/XML/SVG code without any additional effort.

I would, therefore, continue to recommend the book as worth
exploring. This book really contributed new techniques in
software development. More specically with XML/XSLT you have
freely available tools to implement "model driven programming"
in your software project.

Cleaveland hits just the right balance in his unique
book on program generators. Just look at the negative reviews.
The review by Carpenter whines about not getting enough XML
in his book. Thank God, Cleaveland doesn't waste
our time and money on just learning XML. There are
plenty of other books that do that. Cleaveland
rightly focuses on how to apply XML to Program
Generators. The other negative review, "Soso", whines
about the exact opposite; that there is too much XML.

Again, thank God, Cleaveland doesn't do that either,
but rather shows the proper role of XML in the
design of Program Generators, namely that XML is
an abstraction interface for the separation of concerns
between expressing specifications
and transforming specifications. Kudos to
Cleaveland for getting it just right!

Hello,

I am interested in code generation and this book helped
me quite a lot. Out of many techniques presented, I liked the
use of XML transform for code generation most. This is really
a relatively easy way of achieving custom code generator in
application software development projects. I applied this
technique heavily in our Network Management System project
in the areas of:

* EJB code generation
* SNMP code generation
* Java parametric code generation like C++ template

(....)

The ideal reader for this book would know Java, but would know nothing about program generators (or compilers) and nothing about XML. They'd want to take things slowly, and wouldn't mind if they didn't get very far. In return, they'd get a surprisingly long introduction to "domain analysis", a decent medium-length introduction to XML and XSL, a quick look at using the Java DOM parser for XML, and some examples.

I was disappointed with the lack of discussion of program generator basics, most fundamentally when to write a program generator versus when to write an interpreter, a parametric program, or as is more typically required, some mix of these approaches. And what about wizards, the most transparent modern incarnation of program generators? And how does this all interact with frequency of program generation and version control? There was no discussion of programming language basics like semantic versus syntactic well-formedness and error reporting, which have their peculiarities in XML and Java.

A primary concern with the whole XML (not to mention Java) enterprise is scalability. There was no discussion of writing efficient program generators; SAX is only mentioned in passing! Even more surprisingly, there is no discussion of generating efficient code, the latter being a primary motivator for many program generation efforts.

Despite the daunting number of pages, this book can be read in one sitting due to the huge font and wide margins.

This book is definitely interesting in understanding how code generation works and how to utilize some of the newer technologies like XML and XSL to generate software. I am very impressed with some of the new, advanced code generators like CodeCharge, which utilize XML and XSL but do not give us insight to the internals of how it works. While those tools prove that XML and XSL are great for generatng code, this book explains how it is done.

I can only assume that Mr. Cleaveland was attempting to woo the legions of Web site developers into writing program generators (PG) with this book. The book centers around a pointless example of how to generate pop-up web pages which call each other when their respective buttons are pressed.
Out of the 13 chapters, 3 are worth mentioning. Chapters 4, 6, and 7 deal with what to consider when writing a PG and how to make it flexible and Mr. Cleveland does bring some worthwhile points to the table. Throughout the other chapters, trivial code snippets are given of how to write the code (in Java, DOM, and XSLT) to generate the pages, however, because the examples are so simplistic any one who knows these languages would know how to write them anyway.
In the future, I would strongly recommend the following:
1. Give examples that people will actually want to use
2. Give examples that highlight your points
3. Get rid of chapters 2 and 3 (domain analysis), they are useless.

After getting this book, I find out that it is really a new area for me, as a Java programmer. Actually, this book clearly illustrates what is a program generator and how we should "generate" such a tool using Java and XML. I appreciate the author's excellent experience and work.

While the book has interesting ideas, it ignores useful results of the domain-specific language community. More important, it preaches to use XML as a domain-specific language, which is in my opinion a disastrous idea.

Terence Parr (jGuru.com) provides an excellent argument why this is the case in his article "Answers to the question 'When shouldn't you use XML?'", August 2001, IBM developerWorks : XML zone : XML zone articles:

"XML is a poor human interface: Humans have an innate ability to apply structure to a stream of characters (sentences), therefore,
adding markup symbols can only make it harder for us to read and more laborious to type. The problem is that most
programmers have very little experience designing and parsing computer languages. Rather than spending the time to design
and parse a human-friendly language, programmers are using the fastest path to providing a specification language and
implementation: "Oh, use XML. Done." And that's OK, but I want programmers to recognize that they are providing an inferior
interface when they take that easy route."

Besides, the book is poorly typeset. It appears that the font was increased until the book had more than 400 pages. I have never seen a bigger font in a computing book! I don't know why Prentice Hall endangers their good reputation with such a poorly typeset publication. Better try to borrow the book first before potentially wasting your money.