Dan Haywood

Finally… after 5 (count them) release candidates, and a pretty steep learning curve, last week we finally released the first release of Apache Isis out of the ASF incubator.

Apache Isis is a full-stack open source application development framework, designed to let you rapidly develop domain-driven business enterprise applications using the naked objects pattern. It’s built with Maven and has a quickstart archetype to get you going quickly:
Read the rest of this entry →

Hmm, it’s high time I did another post, so this one’s just to mention that I’m going to be attending the Apache Code Retreat this weekend, looking forward to meeting face-to-face some of the other Apache Isis committers for the first time. The retreat also includes an open-to-all unconference on the Saturday.

Also hoping to get a little guidance on how to put out a release formally. It’s high time that we released a first version of Isis from the incubator. I’ve been working steadily on the codebase and supporting documentation, as well as an archetype to get you started quickly. Next step is to get a release into the central Maven repo so that it’s easily accessible by all.

I’ll let you know how I get on.

Really should have blogged this a while back… our proposal to donate Naked Objects framework and my sister projects to the Apache Software Foundation has been accepted.

We now have Mark Struberg as our champion, with Mark and also Benson Margulies, Siegfried Goeschl, James W. Carman and Vincent Massol as our nominated mentors. Special thanks too for Mohammad Nour El-Din for his early support of our proposal and help since.

Current status: we’re uploading the codebases into Subversion, which should be done by the end of this week (the naked objects code is loaded, but my sister projects are still to go).

In the meantime we’ve been figuring out how we want to restructure some of the existing code, bearing in mind our objective to use JSR-299 in the future and trying to make the architecture of the framework easy to understand for a contributors. You can see the results of our current thinking on the Isis wiki.

And, if you’re interested in monitoring our progress or getting involved, then our mailing list is a good place to subscribe.

Over the last few months we’ve been seriously considering donating both the original Naked Objects framework as well as my sister projects to the Apache Software Foundation, sounding out various people and gauging interest. Today we formally announced a proposal for a new project to be accepted into the Apache incubator. The name we’re proposing for this combined project is Apache Isis.

The rationale is to develop Isis into a standards-based framework for building domain-driven apps, appealing both to its user community (who just want to use it “out-of-the-box”) and to its contributor community (who want to quickly understand how it works and what is required to extend it). Ultimately it’s about securing the future of the framework to allow more people to realize the benefits of domain-driven applications when developed using the naked objects pattern.

You can read the full proposal at: http://wiki.apache.org/incubator/IsisProposal. If you like what you see, then why not get involved. And if you don’t, tell us why so we can address it.

Over the last few months I’ve been plugging away at another sister project for Naked Objects, this time a new web-based viewer built using the Apache Wicket web framework. I reckon it’s now in a fit enough state to be tried out more widely, and hopefully find some contributors with better web UI skills than I do!

But what does it do? Well, Wicket Objects is a way of rapidly developing web apps simply by writing the domain objects. Fundamentally it consists of a set of Wicket IModel’s that wrap the NO metamodel, and a bunch of Wicket Components that can render those IModel’s. Given that there’s no UI code to write to get a fully-functional webapp, this means you can develop good code, very quickly. Then, when you do need to start to customize the app, you can just use the Wicket API against the aforementioned IModel’s.

Here’s a screenshot of Wicket Objects in action with its standard form for an entity:

I’ve put together a new Maven website, plus some docs, and I’ve uploaded a snapshot into the sister projects snapshot repo. So, to try it out with a small test app, just do the following:

svn co https://wicketobjects.svn.sourceforge.net/svnroot/wicketobjects/trunk/testapp/claims .
mvn clean install
cd webapp
mvn jetty:run

To logon, use sven/pass.

One of the objectives of Wicket Objects is to be customizable. But I didn’t want to invent some new proprietary API for developers to have to understand. Hence choosing Wicket; I basically use its API for building Components as my customization API.

That also makes it easy to reuse 3rd party Wicket components to create customized views. For example, we can customize Wicket Objects so that Locatable objects are displayed in a google maps mashup; behind the scenes this uses the gmap2 Component on WicketStuff:

So, please give it a try. And if you like what you see and either already know or want to learn Wicket, why not help me take it up to a 1.0 release?

I was at the SPA conference last week, ostensibly to do a little talk on Naked Objects, but mostly to mix and talk with some cleverer people than me to pick up some new ideas.

In a break I was asked whether Naked Objects supported Groovy. To which my answer was: “well, no, but it’s been on our list to look into ages, and it really oughtn’t be hard if we ever got round to it”.

Anyway, so I’ve got around to it, meaning there’s now a new sister project that’ll let you write your domain objects in Groovy, to run on Naked Objects. Read the rest of this entry →

You might (but then again might not) have noticed a couple of new (permanent) pages at the top of this blog.

• The first lists a number of project ideas for extending Naked Objects, of various sizes. As well as being indicative of the flexibility of the NO framework, I’m also hoping that they’ll inspire anyone looking for an interesting project to work with. In particular, if you’re a IT/CompSci student looking for a subject for your thesis, then check them out.
• Second, and related, I’ve also put up a page that lists a set of user stories / features that make up a reasonably comprehensive viewer for Naked Objects. Naked Objects itself already as the DnD viewer and the HTML viewer, and the next version will include the Scimpi web viewer too. Meanwhile in the sister projects my Restful Objects is a viewer of sorts, and I’ve been working on a new one based on Wicket (more below). Anyway, take a look-see; if you fancy writing a viewer in Android or JavaFX, it’ll give an indication of the work required.

And finally, onto Wicket. I was able to rattle off that list of stories because I’ve spent my last couple of months of spare time and odd days working on a generic OOUI viewer based on Apache Wicket. This basically picks up on the stuff I covered in chapter 15 in my book where I demonstrate the principle.

Anyway, so we now have a new sister project, called (you can probably guess) Wicket Objects. It’s not quite finished but is getting pretty close, and I’m gonna be demonstrating it at the SPA conference in London in a week or two. I have to say that I love how this little project has turned out: Wicket Objects leverages Wicket for the UI, has Naked Objects do the back-end stuff. As a developer you get a Wicket-based UI for your domain objects for free, which you can then extend using your Wicket knowledge as need be.

I’m gonna be blogging more about Wicket Objects as I tidy it up and get its documentation together; in the meantime there’s some basic notes on its wiki at Sourceforge.

A topic that comes around now and again on the DDD newsgroup is how to provide access to a domain service (or a repository) to an entity. This service might be very generic, e.g. a NotificationService so that the entity can raise a domain event. Or, it might be quite specific, e.g. an EmailService so that an entity (e.g. Communication) can physically send itself out as an email.
So, let’s look at four different techniques by which the entity can gain access to the service. I’ll use the email example throughout.
Read the rest of this entry →

Last time round we simplified an entity inheritance hierarchy, moving the polymorphism into anonymous subclasses of a Java 5 enum. Which is great, but if there’s a lot of business logic that’s been factored out in this way, it can make the enum itself somewhat unmanageable. Moreover, we can’t easily extend or modify its behaviour without opening up the enum class, modifying it and recompiling.

To get round these problems we can further refactor our solution by pushing the polymorphic behaviour into a strategy class, and have the enum look up that strategy somehow in order to delegate to it.
Read the rest of this entry →