|
|
|
XML @ Web Programming
Programming Shed : Programmer Store & Resources |
|
|
|
|
|
XML Index - XML Book :
Program Generators with XML and Java
by J. Craig Cleaveland Paperback - 448 pages Bk&Cd-Rom edition (February 7, 2001) Prentice Hall PTR ISBN: 0130258784 Dimensions (in inches): 1.21 x 9.22 x 6.99 Guide to creating program generators that automate much of the work of software development, using XML and Java. The CD-ROM contains software and other helpful materials for use with the text. System requirements include CD-ROM drive, and Windows 95, 98, NT or 2000. From the Inside Flap: I've dreamed about writing this book for many years, but it did not turn out as I imagined. XML and Java are recent technologies that did not appear in my dreams. I've been working with program generators and domain engineering for nearly 20 years using primarily C and hand-crafted plain text languages. XML and Java provide a new context for these older technologies and they fit together. It was a joy to retrace the steps I had taken many years ago, and see how much easier and more... Customer Reviews Reviewer: Bob Carpenter from New York, NY USA I bought this book before I began my current project, which happens to be writing a program generator in Java using XML as the source language and Java as a target language. I litterally did not learn one thing I didn't already know. And it wasn't even a nice summary where I could nod along at the beautiful presentation of something I already know. Perhaps I came to the book too well educated, knowing the XML SAX and DOM parsers, Java, as well as old-school tools such as YACC and JavaCC. But even if you didn't know these things, this is not the book I'd recommend to learn them. "Program Generators with XML and Java" is so slow to start that XML isn't introduced until page 99, after 98 pages of tedious "domain analysis" of examples involving a play with characters named Jack and Jill, who, you guessed it, run up and down a hill with water. I find most discussions of formal methodologies for "software engineering" to be both vague and patronizing, and Cleaveland's offering is no exception. Then it's more slow going until the DOM parser is introduced on page 205. The treatment is superficial, and SAX is only mentioned in passing! Only about a third of XSL is covered, so even if you do get this book, it'll need to be supplemented with some serious reference materials and tutorials. A book I can wholeheartedly recommend for learning SAX, DOM, XML, and XSLT is Brent Spell's "Professional Java Programming", which as an added bonus, contains extended coverage of at least half a dozen other topics, such as Swing layout managers, JTable, and JDBC. You probably already know Java, or wouldn't be reading this book, but if not, check out Arnold and Gosling's "The Java Programming Language", the gang of four's "Design Patterns" and Fowler's "Refactoring". You probably also want a modern compiler book, but I haven't read one since Aho, Sethi and Ullman's classic "Compilers" (aka the Dragon book). Maybe I accidentally received the "large type" edition; if this book had been set with a sensibly sized font, a traditional eye to conserving vertical white space, and normal margins, it couldn't have topped 150 pages. I'm frankly sick of these padded computer science books, the goal of which seems to be to dominate my shelves with their titles and break my back under their weight; I simply wasn't impressed that this book had room for a hologram saying "XML" on the spine. It's not so much that the material in this book is wrong or even misleading, it's just that it barely even gets started. Reviewer: A reader from San Jose, CA United States 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. Reviewer: Soumen Sarkar from Fremont, CA United States 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. Reviewer: A reader from Victoria, Canada 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. |
|
|
|
© 2005-2006, Programming Shed
|
