Kenneth Barclay

XML Builders and parsers

XML has quickly established itself as a technology that can be used for a variety of applications. As simple XML markup, it can represent both data and its structure. XML is so adaptable that it also finds uses for object configuration, GUI architecting, and application building and deploying. Groovy supports a tree-based markup generator BuilderSupport, that can be subclassed to make a variety of tree-structured object representations. Commonly, these builders are used to represent XML markup, HTML markup, or, Swing user interfaces. Groovys markup generator catches calls to pseudomethods and converts them into elements or nodes of a tree structure. Parameters to these pseudomethods are treated as attributes of the nodes. Closures as part of the method call are considered as nested subcontent for the resulting tree node. These pseudomethods are an illustration of the meta-object protocol (MOP). The Bull derSupport class, from which concrete builder classes are derived, includes an implementation of the MOP method invokeMethod, which translates the pseudomethods into the nodes of the resulting tree.

Case study: A library application (GUI)

This chapter revisits the library case study of a previous chapter. The aim here is to give the application a more modern look and feel by adding a GUI. Happily, it is easy to reap the benefit of its MVC architecture by not having to change any of the model classes. Similarly, the decision to use a DAO means that no changes to classes that access the database are required. Finally, Groovys SwingBuilder makes the construction of the GUI relatively easy. In the first iteration, the aim is to demonstrate that the text-based menu developed in the case study of the previous chapter (chapter 18) can be replaced with a GUI. The intention here is that it should mirror the GUI developed in Example of another chapter. Therefore, here the options presented by the menu is replaced with suitably labeled FixedButtons and replace Action class methods with event handlers. The application now requires event handlers to provide the required functionality. The aim of the second iteration is to put most of them in place.

Numbers and expressions

This chapter is concerned with how to manipulate basic numeric values in Groovy. When doing so, one must be especially conscious that Groovy has been constructed as an object-oriented language. This means that everything in Groovy is ultimately an object—an instance of some class. For example, everybody is familiar with the integer value 123. In Groovy, this is actually an object instance of the class Integer. To make an object do something, one of the methods declared in its class must be invoked. Hence, to obtain the absolute value of such an integer, the Groovy environment invokes the method abs with the expression 123. abs (). Equally, to ask 123 for the value that follows it (124), the Groovy environment calls the successor method, next, as in 123.next (). This chapter deals with the manipulation of arithmetic values in a relatively straightforward manner. However, it is an important field of study in its own right, and a more detailed discussion is presented in Appendix C.

Lists, maps, and ranges

This chapter introduces the list, map, and range. All are collections of references to other objects. The List and Map can reference objects of differing types. The Range represents a collection of integer values. The List and Map also grow dynamically. Each object referenced in a List is identified by an integer index. In contrast, a Map collection is indexed by a value of any kind. Because the class of the objects maintained by these collections is arbitrary, the elements of a List might be a Map and the elements of a Map might be a List. In this way, it can be used to create data structures of arbitrary complexity. The List is a structure used to store a collection of data items. In Groovy, the List holds a sequence of object references. The Groovy List class supports a host of methods that make list processing pleasing and easy. The List class removes much of the work that would otherwise have to be programmed in an application. A Map (also known as an associative array, dictionary, table, and hash) is an unordered collection of object references. The elements in a Map collection are accessed by a key value. The keys used in a Map can be of any class. The Map class supports a range of methods that make map processing very easy. A range is shorthand for specifying a sequence of values. A Range is denoted by the first and last values in the sequence, and Range can be inclusive or exclusive.

Case study: A library application (methods, Closures)

This chapter illustrates the power of Groovy methods and closures by constructing solutions to the small case study introduced in a previous chapter of this book. As before, a simple model of the loan data kept by a library is presented. The library maintains a record of the titles of the books in stock and the names of the borrowers who have been loaned one or more books. As in the previous case study, the library application is developed as a series of iterations. This lets it add functionality to the application in a controlled manner. It also ensures to having a working (partial) solution as early as possible. The first iteration demonstrates that the required functionality can be achieved while the second implements a simple text-based, command-line user interface. The third iteration simplifies the coding of the second. The aim of this chapter is to make it easier to understand and maintain.

Chapter 6 – Case study: A library application (modeling)

This chapter illustrates how Groovys Lists and Maps might be used in practice. For this first case study, a simple model is constructed, of the loan data, maintained by a library. In keeping with modern practice, the library application is developed as a series of iterations. This lets it change the implementation of the case study in a controlled manner. The first iteration illustrates the use of a List and the second a Map. A library maintains a record of books on loan to its borrowers. In this very simplistic solution, each book is known by its title and each borrower by his or her name. The librarys database of books on loan can be represented in a number of ways. However, the choice is made easier by Groovys support for two important data structures: List and Map. An alternative approach might be to use a Map to represent the loan database.

Case study: A library application (persistence)

This chapter extends the final iteration of the application developed in a previous chapter so that the library, its borrowers, and publications (the domain model) persist in a database. Earlier in the book, an Action object was uses to implement a MVC (model-view-controller) architecture and, as a consequence, keep the domain model separate from the user interaction code. In this case study, this chapter introduces a data access object (DAO) to keep the domain model separate from database persistence code. It is implemented with the Spring framework and the Cloudscape DBMS. The Publication, Book, and Journal classes are unchanged and only a minor change is required in the Borrower class. However, there are significant changes made to the Library class and the main Groovy script that runs the application. Both rely on the construction of a DAO using the Spring framework. In the first iteration, the required changes are detailed. The second iteration considers the impact of persistence on unit testing. Happily, it is found that all of the earlier unit tests can be run without too much trouble. It is also found that it is surprisingly easy to introduce new unit tests aimed at testing our implementation of persistence. Finally, the chapter reflects on the role of automated unit testing and Groovy.

Unit testing (junit)

This chapter explores the use of the JUnit testing framework within the Groovy environment. This chapter uses classes from the case study of a previous chapter to illustrate how unit testing can be accomplished with the GroovyTestCase class. Next, it shows how several GroovyTestCases can be combined into a GroovyTestSuite. Finally, it reflects on the role of unit testing in an iterative, incremental approach to application development. Throughout this discussion, it is emphasized just how easy it is to benefit from unit testing with Groovy. The fundamental unit of an object-oriented system is the class. Therefore, an obvious candidate for a unit in unit testing is the class. The approach taken is to create an object of the class under testing and use it to check that selected methods execute as expected. Normally, every method is not tested, since it is not always possible or even desirable to do so. The aim here is to detect and correct any likely failures that might arise when a class is deployed in an application.

Case study: A library application (inheritance)

The library application first appeared in previous a chapter where, it was showed how Lists and Maps can be combined to produce data structures to manage the book-keeping required by a library. In that chapter, the data maintained in these collections were simple strings. In a subsequent chapter, the capabilities of the system were enhanced by making use of procedural code and closures. A text-based menu was introduced to support user interaction. Later, in another subsequent chapter, objects with more interesting state information and behaviors were used to represent the library, its borrowers, and books. It also removed any input/output responsibilities from them and introduced another class for this purpose. In the first two iterations in this chapter, the same case study is revisitd and class inheritance is used to model not just books and journals but publications in general. As with the earlier versions, this chapter uses containers to help model the relationships established among objects. Similarly, it continues to make use of unit tests. In the third iteration, it addresses the problem of error detection and user feedback as well as enhancing the functionality of the system. Finally, in the last iteration, it is demonstrated how easy it is to use Groovy to police constraints placed on the model.

Flow of Control

The execution of a program statement causes an action to be performed. The programs that have been developed execute one statement after another in a sequential manner. Because of this execution ordering of the statements, the program logic is described as sequential. Abstract actions can also be created with method definitions and then treat them as if they, likewise, were simple statements through their method calls. The statements that have been explored include the assignment, input/output, and method calls. Additionally, statements are provided in Groovy to alter the flow of control in a programs logic. They are then classified into one of three program flow of control structures: sequence, selection, and iteration. The fundamental iteration clause is the while statement. The while statement is executed by first evaluating the condition expression, and if the result is true, then the statements are executed. The entire process is repeated, starting once again with reevaluation of the condition. This loop continues until the condition evaluates to false. When the condition is false, the loop terminates. The program logic then continues with the statement immediately following the while statement. The group of statements is known as a compound statement or block. The break statement is used to alter the flow of control inside loops and switch statements. Finally, this chapter discusses continue statement. The continue statement complements the break statement. Its use is restricted to while and for loops.