G:

Point your browser to http://grails.codehaus.org. Downloading and installing is explained there. We will go for the latest version, which is 0.3.1 at the moment.

D:

Okay, it needs Java 1.4+ and Ant as prerequisites. I’ve got them already. Strange that it doesn’t need Groovy to be installed. [raises right eyebrow]

G:

Grails comes with the embeddable groovy-all.jar included to avoid any version conflicts.

D:

Wise decision. Now how about installation? Aha—setting a GRAILS_HOME environment variable and adding GRAILS_HOME/bin to the Path environment variable. So far so good—no surprises. But what’s that next thing here: going to GRAILS_HOME and typing ant?

G:

That means we are building Grails from the sources. Isn’t that neat?

D:

Neat or not, it’s a bit odd. But hey—as long as it works, it’s fine with me.

G:

That was it for installation.

D:

Eh—no. Wait. We’re gonna need a database.

G:

Yep. That’s included.

D:

And this will be a web application, right? So we also need a web server.

G:

No, that’s all included. Grails comes with everything you need for development.

D:

That can’t possibly be right. In the end, we’ll have to deploy it on our corporate SphereLogic webserver and the DBacle/2 database! That’s all very special. How could we ever develop against a different environment?

G:

Well, first of all, Grails will produce a full J2EE-compliant web application as a web archive file. We can throw that into any compliant server. Second, Grails uses Hibernate to take care of the database mapping. That means we have a huge variety of databases that we can choose from.

D:

Pretty impressive. Now, how do we start?

G:

Go to any directory you like, and open a command shell.

D:

I’ll take one that’s already under version control.

G:

[nods] Sure. Now create a new application by typing

grails create-app

G:

and enter our application name when asked. I think Tutor would be appropriate.

D:

It’s created a lot of directories. Any idea what they all do?

G:

Yes, it looks like this. [produces table 16.1]

D:

Gosh, it’s lucky you had that table with you. I see that the layout of the grails-app directory suggests that Grails obeys the good-old Model-View-Controller (MVC) separation or even enforces it.

G:

Yes, we will see that throughout the whole project. In general, the model is made by the domain objects, which drive the whole process.

D:

It’s created a whole bunch of files, too.

G:

Those are defaults for our application so that we can start right away.

D:

You mean we can start the application without having done anything?

G:

Yes, we can. [takes the keyboard] Go to the application directory

cd tutor

G:

and run the application.

grails run-app

D:

That’s a heck of a lot of console output. Is anyone meant to understand that?

G:

Well, we’re running at warning log level per default. I bet you’d be glad if anything went wrong.

D:

Now it waits and says: watch-context. What does that mean?

G:

That’s the Jetty web server, which is included in the distribution. Grails has generated a full-blown J2EE web application and started the server on it.

D:

Very helpful. No tinkering with server configuration files. That’s a big plus. And where is it running now?

G:

http://localhost:8080/tutor/.

D:

[grabs the keyboard] Here we go. [figure 16.1 is displayed]

G:

Okay, the setup works.

D:

Yes, that’s a good installation check. How did you know the URL?

G:

8080 is the default port, but we can of course change it if we want. The /tutor part comes from the name of the J2EE “application context” that has been created for us.

D:

I see. And now we hack away some static HTML pages to create a prototype?

G:

Why would we want to write static HTML pages? Don’t you want to see real data?

D:

Of course, eventually, but surely a few dummy pages come first, don’t they?

G:

No. If we were going to do any more coding right away, we would create domain classes, but I think we should lay out some plans first.

D:

[nods] Does that mean you’re calling a coffee break?

G:

Or tea. 15 minutes after lunch is the perfect time for this.

G:

Yes. We have authors who create a tutorial and users who read it. To make the authors’ lives easier, it would be nice if they could post tutorial pages through the web application.

D:

You mean like posting to a blog or a wiki?

G:

Yes, exactly. We’ll find out what works best. We’ll also need a tree-like structure for the tutorial entries to organize the tutorial and show a table of contents.

D:

And where is the interactive part?

G:

I talked with our boss about that before. He has the idea that logged-in users should be able to see what tutorial elements they’ve already worked through so that they can concentrate on the new ones.

D:

Hm, that’s a bit tricky. A user can scan through the material without reading much of it. That shouldn’t count as “reading.”

G:

Maybe the user clicks a button, indicating that they have visited the page.

D:

Hm, sounds doable—with considerable effort.

G:

We don’t have much time, so we will follow the simplest possible route. Let’s see what we have. [sketches figure 16.2 on the whiteboard]

D:

That’s rather simple.

G:

It will become more complex over time. You know: every complex solution that works is based on a simple solution that works.

D:

So, what have we got? TutorialEntry seems to be the central abstraction.

G:

Yes, it holds most of the information and will be the hub of most references. After all, the tutorials are the entities we’re doing all this for.

D:

And every TutorialEntry refers to an Author?

G:

Yes, each one refers to exactly one Author, but many TutorialEntries can refer to the same one.

D:

Therefore the relation from TutorialEntry to Author is many-to-one.

G:

Right, and it is unidirectional. That means we assume that every TutorialEntry directly references its Author, but a single Author doesn’t explicitly store a reference to all their TutorialEntries.

D:

But what if we want to show all TutorialEntries of a given Author?

G:

Then we can query for all TutorialEntries where the author property matches the given one.

D:

Ah, okay. No need to keep track of all the back references, because we can rely on the relational model below the surface.

G:

Exactly. It means less work with the bookkeeping but at the expense of performance. A query is always slower than following a reference.

D:

Hmm. [scratches head] So which is better then: unidirectional or bidirectional?

G:

I wish it were that easy. That’s an engineering decision. Making such tricky decisions is what we are paid for in the first place—besides knowing the tools and mechanics.

D:

You’re making me nervous. What if we decide wrong?

G:

They will hang us. [laughs] No, honestly, the cool thing about Grails is that you can change the design at a later stage without excessive costs. This is where the knowledge of the tools pays off. They give us leeway to defer and correct decisions.

D:

Good to know. What about that other reference between the TutorialEntries? That seems to be the parent-child relationship.

G:

All TutorialEntries have a parent TutorialEntry except the root Tutorial-Entry, which has a null parent. Many TutorialEntries can have the same parent. They are siblings, so to speak.

D:

And the relation is also unidirectional. Every TutorialEntry knows its parent but not its children? Is that a wise decision?

G:

For the moment, it should be good enough. Introducing back references from the parent to its children is an optimization issue. Grails grants us enough leeway to care about that later, when we have a better idea of what the actual access patterns are.

D:

I think I need to see some code to understand all this.

G:

All right. Let’s go over and get a first version running.

G:

Both, actually. [grabs the keyboard] But Grails gives us all support we need. Let’s first create the Author class:

grails create-domain-class

    [input] Enter domain class name:
author

D:

Ah, you entered the class name in lowercase?

G:

Yes, but that’s only because I’m a lazy typist.

D:

And Grails says it has created two classes for us: grails-app/domain/Author.groovy and grails-tests/AuthorTests.groovy.

G:

That’s a scaffolded domain class and a corresponding unit test to give us something to start with. Author.groovy looks like this. [opens the file in an editor—listing 16.1 is displayed]

D:

There’s not a lot there, really. Is that it?

G:

That’s all it takes to start with. Grails will inject id and version properties at runtime for internal purposes. It also adds a toString method for the standard display of the object, showing class name and id. We should change that to something more meaningful for our domain class.

D:

You mean we should make it return something that makes sense to a user rather than to the computer?

G:

[nods] Exactly. Also, every such class will automatically be persistent—that is, backed by the database and managed by Hibernate.

D:

Aha, then let’s create the database, the tables, the schema, and the mapping descriptor.

G:

No, no, no! That’s why I said “automatically.” That’s all done for us behind the scenes. There’s really nothing we have to do.

D:

Wow! Very impressive. But how about the name attribute that we have to add?

G:

That’s as simple as this. [edits the file to make it listing 16.2]

D:

And no mapping at all?

G:

As I said—it’s all automatic. Grails follows the “convention over configuration” paradigm, which makes all this possible.

D:

I would like to see something tangible before we proceed with the domain model. Can we look at the database?

G:

Yes, we can. We can even look at it through the web application.

D:

You’re kidding! We don’t have a web application.

G:

We don’t have a web application yet, but we will have one in a minute. See here:

grails generate-all

    [input] Enter domain class name:
author

D:

Lots more screenfuls of output, I see. And this is creating a web application?

G:

Start the server with

grails run-app

G:

and point the browser to http://localhost:8080/tutor/author. We need to add “author” to the URL because that is our domain class of interest. [browsing around, the screens in figure 16.3 are displayed]

D:

Hey, this really works! I can see the initially empty list of authors, create a new one, see it in the list, and edit and delete it. Not bad for having written only two lines of code!

G:

Yes, this is called scaffolding. It allows us to get something running quickly.

D:

Ah, you mean all these views are scaffolded, as you call it?

G:

Not only the views but also the controllers...

D:

... which call the database operations.

G:

Kind of. They work on the domain objects rather than calling the database directly. Each change to the domain object gets automatically propagated to the database.

D:

Does that mean we can have a campfire with all our SQL reference manuals being burned in a big ceremony?

G:

Certainly not. We don’t need them for the standard cases any longer, but when times get tough, you’ll be glad to have them.

D:

Right, right. Now, what’s next? Proceed with the other domain classes?

G:

Well, we could. But I’d like to show you another feature first.

D:

And that is?

G:

Functional testing.

D:

You mean we can also test the web application automatically?

G:

Yes, and it’s remarkably easy. Look here. We’ll create the webtest, then scaffold the author tests, and finally run it. Creating the webtest support is a one-liner:

grails create-webtest

G:

This fetches Canoo WebTest if necessary and installs it. The download size is pretty big. Luckily we have good network connectivity.

G:

Now scaffold a webtest for the Author class:

grails generate-webtest

    [input] Enter domain class name:
author

G:

And now we run it:

grails run-webtest

D:

[as figure 16.4 is displayed] Ah, it brings up a test report. That’s pretty. Does it work by clicking through the web application on my behalf?

G:

Yes, and we can run it after every tiny change to the code, asserting that we haven’t broken anything.

D:

That means the tests will fail if our code doesn’t compile?

G:

It will even fail if our implementation doesn’t add or delete an author properly to the database.

D:

Very impressive. That’s good-old engineering practice made easy. When we proceed with changing the application logic, do we have to adapt the tests as well?

G:

Of course—and the best practice is to adapt the test before we change any functionality. [smiles]

D:

How do I change the tests, then?

G:

See for example webtest/tests/AuthorTest.groovy. It specifies the test like in lines like these:

clickLink  (label:'New Author')
verifyText (text: 'Create Author')
clickButton(label:'Create')
verifyText (text: 'Show Author', description:'Detail page')
clickLink  (label:'List',        description:'Back to list view')

D:

That reads like a checklist of what to do for manual testing, but it does it automatically.

G:

It also is all plain Groovy, which makes it convenient to work with.

D:

I feel confident enough to proceed with the domain model.

G:

Shall I type?

D:

Please let me do it. I think I understand the pattern...

D:

We’re going to scaffold TutorialEntry, right?

G:

Yep.

D:

[starts typing]

grails create-domain-class

    [input] Enter domain class name:
tutorialEntry

D:

All fine. Now scaffolding views and controllers?

G:

We could do that, but the views are scaffolded from what’s available in the domain classes, so we should complete them first.

D:

Okay, Author is already complete. Now let’s do the TutorialEntry class. It’s stored in the domain directory, if I remember correctly. [opens the file] Now what?

G:

Add a property for every attribute that we defined in our design: title, text, author, and parentEntry.

D:

Do we need to declare property types?

G:

Yes. Grails uses the type information for building the model. Having the type information available is a big plus.

D:

Title and text are plain Strings. Is author of type Author then?

G:

Of course.

D:

And parentEntry is of type TutorialEntry. Very straightforward.

G:

[grabs the keyboard] Here we go. [edits TutorialEntry to listing 16.3]

D:

Can I scaffold the views and controllers now?

G:

Go ahead.

D:

Piece of cake. [starts typing]

grails generate-all

    [input] Enter domain class name:
tutorialEntry

D:

Now starting the server...

grails run-app

[wait-forever]:

D:

... and open the browser and create a TutorialEntry.

G:

Every TutorialEntry needs an Author, so we’d better create one first.

G:

Now head over to http://localhost:8080/tutor/tutorialEntry/create. [figure 16.5 is shown]

D:

Wow! We already have the core of the application. And it’s working. We have the full lifecycle for authors and tutorials. The views are still not what we really want, though.

G:

Yes. Scaffolding is only to get you started and provide you with something that you can build on. It’s not uncommon to progressively replace all scaffolded artifacts in the course of the project.

D:

Then let’s see what we can do about the TutorialEntry’s list and details view.

G:

We create our domain objects programmatically. Look here.[creates config/ApplicationBootStrap.groovy—listing 16.4]

D:

You create your objects with references and such, and when you say “save()” it all goes to the database?

G:

Isn’t that nice? That’s the typical Groovy style of having a smart configuration. Just imagine if this were XML like in other systems. Then we wouldn’t be able to define any amount of example data as we do in the little for loop.

D:

Well, then let’s display it. [types]

grails run-app

D:

Now see what we have in the TutorialEntry list. [web browser displays figure 16.6]

G:

I think the scaffolded list view of tutorials shows too many details. It should only show titles, like in a table of contents, but with indentations.

D:

Okay. How do we change it?

G:

It’s all here. [opens views/tutorialEntry/list.gsp]

D:

Ah, the directory structure reflects the URL of the view. Very convenient.

G:

At least for the standard views as scaffolded. There are alternatives like creating them dynamically, but for our little thing here the standard way is all we need.

D:

And this GSP is the Groovy version of JSP?

G:

Yes, only better. [grins] Look at the snippet here that renders the list of tutorials. [opens the file, showing listing 16.5]

D:

Looks familiar. I know nothing about GSP, but I can guess that this renders a table row for each TutorialEntry with table cells for every property. Not surprising. I assume we delete all cells that we don’t want to see?

G:

Yes. And don’t forget the corresponding table header cells.

D:

Done. Now restart the server and see what it looks like?

G:

No, no. We don’t need to restart the server. Just save the file and reload the browser page.

D:

Wonderful—very convenient. I like this micro-iteration development.

G:

Yes. Instant feedback is really helpful. You do a little change and verify the result without losing your concentration. This is what gets you into the flow of programming.

D:

I know what you mean. When everything seems to just fit.

G:

That reminds me—our list view doesn’t fit yet. It doesn’t show indentation.

D:

Hm, we need to indent each title as much as its nesting depth counted from root.

G:

And that’s equivalent to the number of parents it has.

D:

Ah, you mean we count the parents and indent by that number? But that’s a full-blown tree algorithm that will require a lot of work!

G:

Not necessarily. Let me try something. [grabs the keyboard—edits the file to listing 16.6].

D:

Magic, magic. I’m impressed. What’s that? A scriptlet?

G:

Yes, the same as you would do in Java for JSP but in Groovy. The depth variable is calculated in the scriptlet for every TutorialEntry before rendering and implicitly stored in the binding. Therefore, we can reuse it in the padding argument of the title table cell style.

D:

It works well, and the output looks nice, but it has a smell. I think a view should never contain logic, and this view does.

G:

I’m not so sure. We could easily refactor this code into the TutorialEntry domain class or into a tag library. On the other hand, although this scriptlet contains logic, this is only view logic. It has nothing to do with the TutorialEntry model as such nor with the flow of the application. That makes it justifiable to leave it here.

D:

But I don’t like the mix of logic here. It doesn’t look well factored. I agree it’s view logic, but it should go to a separate place.

G:

If that’s the only thing that makes you feel uneasy, then we can move it into a template. Templates are little view pieces that are reused with changing data.

D:

Like a row template used for each TutorialEntry?

G:

In fact, that is a good name. We make a new file tutorialEntry/_row.gsp and put all the <tr>-enclosed code there.

D:

The leading underscore is a naming convention?

G:

That separates it from the normal views and suggests that it doesn’t produce a full page but only a part of it.

D:

And the tutorialEntry/list.gsp refers to it by name?

G:

Yes, via the render method. The old line

<g:each var="page" in="${tutorialEntryList}">

G:

is replaced with

<g:render template="row" collection="${tutorialEntryList}" />

G:

This will pass all entries of the tutorialEntryList one after the next into the row template for partial rendering.

D:

I like that much better. It clearly shows that the extracted logic affects only one line.

G:

It also makes the view logic reusable. Any view that needs to render a TutorialEntry in this fashion can refer to the template.

D:

What other views need improvement? Ah, the detail view should present tutorial entries in a more readable format. I assume it resides in views/tutorialEntry/ show.gsp.

D:

This looks all very comprehensive. Rearranging the fields a little should be all that’s necessary.

G:

I have an idea. In addition to having our authors possibly provide HTML tags in their contribution, wouldn’t it be nice if they could use some wiki-like markup for the simple cases? We could then display the transformed markup on this page.

D:

Hm, sounds complicated.

G:

For a start, we allow some simple markup: treating newlines as breaks, two newlines as a paragraph, and support bold, underline, and italic styles.

D:

That’s still a lot of work—more than we can do in a scriptlet.

G:

Yes. That’s a job for a taglib.

D:

Hm. [shakes head] I did some taglib stuff with JSP—lots of configuration and not a lot of fun.

G:

I’ll show you Grails’ no-configuration solution. Go to the taglib dir, and create a new file WikiTagLib.groovy.

D:

And now?

G:

We implement the intended tag as a closure property with the respective name. How about “wikify”? The tag would have a text attribute with the raw text that is to be transformed to HTML.

D:

And how do we pass the result back?

G:

We add it to the out result writer. Look here. [creates taglib/WikiTagLib. groovy, listing 16.7]

D:

Pretty slick. All plain Groovy. But how do we use it?

G:

In show.gsp we replace

${tutorialEntry?.text}

G:

with

<g:wikify text="${tutorialEntry?.text}"/>

D:

That’s all logical. I guess we now have to declare our WikiTagLib in the page header and in web.xml?

G:

No, no. That’s all done automatically. Save the files, and reload the page, [David Copperfield gesture] et voilà, there it is. [figure 16.7 appears on the screen]

D:

You know what? This is really how web development should always be: simple and efficient. Why wasn’t this invented earlier?

G:

[nods] I would say: Ruby on Rails invented the idea, and it took the appearance of Groovy to make this possible on the Java platform. The availability of Hibernate and Spring was also a prerequisite. But it’s not the pure power of the Java packages that counts. The dynamic nature of Groovy is just as important.

D:

And now the idea can grow.

G:

Just like our application. Let’s use it a little to see how it feels.

G:

Yep. Finally, I’d like to go over field validation to protect the application from bad user input.

D:

I would normally complain that this is too much work, because we have to go over all the affected actions and views, but I guess you have another ace up your sleeve?

G:

Well, I haven’t—but Grails has. It allows easy declaration of constraints in your model that are automatically used for validation. Let’s take the User class, for example. The name property should never be empty, neither should it be too long or too short. And most importantly, it must be unique in the database.

D:

Looks like we have to write some tricky conditionals and database access code here.

G:

Or a simple constraints property like so that goes directly in User.groovy:

def constraints = {
    name(length: 5..15, blank: false, unique: true)
}

D:

Marvelous! And how does it work on the user interface?

G:

Let’s try to add a user that already exists and see what happens. [tries it, resulting in figure 16.9]

Figure 16.9. Validation error message when trying to create a new user with a name that already exists in the database

D:

Really slick and very intuitive. Can you tell me what kind of validations are available?

G:

There’s a fairly long list in the online docs. So far, I’ve been able to do everything I needed, even regular expression matches.

D:

That’s fine. Regular expressions should at least cover everything we need to validate on the syntactic level. But what if I want to have other error messages?

G:

Then you can adapt the file i18n/defaultErrorMessages.properties or provide your own localized message bundle. It all goes through the standard Java way of internationalization.

D:

Perfect. I’d say we are ready for take-off.

G:

So would I.

D:

Now, what do we have to do in order to deploy the application?

G:

Adapt the database configuration to match the settings of your deployment target, run the grails prod war command, and use the production server mechanics to install the generated web archive file.

D:

Where is the database configuration?

G:

It’s in conf/ProductionDataSource.groovy, just beneath the data source definitions for testing and development. Look here:

class ProductionDataSource {
   boolean pooling = true
   String dbCreate = "update"
   String url = "jdbc:hsqldb:file:prodDb"
   String driverClassName = "org.hsqldb.jdbcDriver"
   String username = "sa"
   String password = ""
}

D:

I guess we change this to our production settings. What’s the purpose of the dbCreate property?

G:

This mimics what is in Hibernate: the hibernate.hbm2ddl.auto property. We can set it to create,create-drop, or update, meaning we want the database schema to be created automatically.

D:

Will that mean that all existing data is lost?

G:

Not if we set it to update, which is the best choice for our purpose. Because we were running with the in-memory test database before, create-drop was the fastest solution.

D:

Where do we get all the information from?

G:

We’d better ask our database administrator, Martin. For production, we’ll need his help anyway, because he needs to grant us access rights and provide a username and password.

D:

And that’s all?

G:

Martin may have some further advice about the best possible driver to use.

D:

Do we need to package that driver class with Grails?

G:

If we need to package it, we can store it in the lib directory, and it will be packaged with the web archive. However, production systems typically have their drivers installed in a shared library, so we can rely on having it available. All we need to know is the class name, and we can add it to the configuration.

D:

I will head over to Martin and ask him.

G:

Meanwhile, I’ll prepare a text message for the boss, saying that the initial version of the Tutor application is up and running in production. I guess they have Internet access in the clubhouse, and he will be able to connect from there.

D:

He will be surprised.

G:

Definitely.

D:

Here we go. I owe him a beverage.

G:

[smiles] We’ll have one later.

D:

Okay, I’ve fixed up the configuration. What was next? Creating the web archive?

G:

Yes. Here it is:

grails prod war

G:

We now have the tutor.war web archive ready for deployment.

D:

I know how this goes. The server has a web interface where we can upload the file and start the application. That’s easy. Just a minute. [uploads the file] Okay. Done.

G:

Let’s do some simple click-through testing to verify it’s fine. Open the browser to http://groovy.canoo.com/tutor.

D:

Looks okay. [clicks through the application] Perfect.

G:

Gimme a high five. [clap]

D:

Okay. Let’s invite Martin and call it a day.

D:

The work with you and Grails was a ton of joy. Thanks for pointing me at it. I think we did an awesome good job this afternoon.

G:

Hm, we could have done a little better.

M:

I saw your application and used it a little. Really nice. Others need more than a week to achieve anything comparable.

G:

Thanks, but I would have liked it better if we’d worked in a more test-driven style. You know: writing unit tests and functional tests as we go along.

D:

You’re demanding too much. That’s hardly possible.

G:

With all the scaffolded tests, it’s quite easy.

M:

And you are testing from a user’s perspective?

G:

Yes. Those are the so-called webtests. They are testing the view. We did a little of that. But we can also have unit tests for our models and controllers.

D:

But we tested the views all the time, because we were constantly switching between coding and using the application.

M:

Sounds like an agile programming thing.

D:

And the models have no methods at all, so there’s no point in testing them.

G:

True; they could have had some methods, though.

D:

I agree that testing the controllers automatically would have been beneficial. They contain the beef of the application logic.

M:

Testing controllers is always tricky. You have to set up a server environment for that, because controllers rely on request parameters, session information, and such. That’s an awful lot of work.

G:

Actually, it’s simple. In Grails, all the information is in common maps that you can pass into the controller method when testing.

M:

Hm, okay. Then it should be easily possible.

D:

I was surprised so many times this afternoon that I believe everything.

G:

[laughs]

M:

You must have had some real fun today.

D:

You bet. It felt like everything was just falling in place.

G:

Well, almost. Remember how we discussed the design of the domain model? That was the crucial part.

M:

The drawings I saw in the coffee corner? They didn’t look overly complicated.

G:

But that’s where the work is: making the complex simple.

D:

Yes. I think my first attempt would have been to go for more bidirectional references. Would that have been possible at all?

G:

Of course. It’s also straightforward. The online docs show how to do it.

M:

How about database performance? I certainly don’t want you to drag down my db when your application becomes popular. [twinkles]

G:

We still have room for optimization, whether by using bidirectional references or by optimizing Hibernate usage with direct mappings. However, I expect at least 90% of our database accesses to hit the Hibernate cache anyway.

M:

Perfect. I’ll look into the database logs to see what you produce, anyway.

G:

Thanks. I would have asked you for that favor otherwise. [grins]

D:

What are we going to do on Monday? I’d like to do some more work with Grails.

G:

We’ll write some more tests first. After that, I’ll say it would make sense to hook in security.

D:

That is possible?

G:

Of course; Grails is pure J2EE, and we can use every feature of that platform: administration, operation surveillance, logging, load balancing, failover, and so forth, and also security. There is no need to reinvent the wheel just because we’re groovy.

M:

I can help you with the security setup.

G:

Great!

D:

The little wiki-like markup we implemented in the WikiTagLib made me think we’re re-inventing the wheel, though. Would it be possible to include something like the Radeox Wiki engine?

G:

Good idea! Yes, of course, that’s possible. We can use any Java library we fancy. We throw its jar file in the lib directory and rework the WikiTagLib to use that functionality!

M:

You have so many options that virtually anything is possible.

D:

Friends, [stands up and raises his glass] I’m afraid the party is over, and I have to leave now. It was an honor to work with you. I know that working with me has not always been easy. I appreciate your forbearance when overlooking my little mistakes. Thank you very much for spending your precious time with me. I hope we will soon meet again and share the joy of dynamic programming.