Taking a little time to reflect

Eitan Suez — Wed, 07 Mar 2007 12:35:00 -0600

I have been working at implementing the codebase that I call a framework that I named jmatter for quite some time. Looking back, I realize that I have on very few occasions actually expressed (or attempted to express) what I have constructed. Most of the time, you may say that I was not completely conscious of it.

UI

Part of JMatter is a user interface for business applications that I wrote in Java Swing. With respect to the UI, the fundamental design boils down to:

essentially designing an ooui, a ui that mirrors the underlying business object model
mvc: views are listeners on model objects and as the model objects change, the views reflect the change

Persistence

Another aspect of JMatter deals with persistence. I wanted transparent persistence. Most of the work is delegated to Hibernate. Some of the conveniences I developed included the automatic construction of mapping files from the objects. This effort has in a sense been nullified by the fact that JPA does this too, and perhaps they do it better because a combination of reflection and interpreting of annotations is translated to the underlying metamodel that Hibernate uses at runtime. The xml mapping files are but a marshalled version of this information.

Core

On to the heart of JMatter. I realize now that I have never really written down what this heart is. In a sense it's a metaobject protocol for Java. JMatter contains a number of classes that model types (ComplexType), instances (EObject), fields (Field), and methods (Command / EOCommand). Java of course has a reflective API. But by writing my own, one that lives on top of the language, I was now in a position to, in a sense, define my own language. If I wanted to give commands special features, I could write them in. Take for example the notion in JMatter that a command can be designated as "sensitive." Another, that a field can be marked "Required" which has implications in terms of the behaviour of CRUD operations. Another is the fact that these types themselves are all EObjects which means they can be persisted and manipulated directly from the UI. Though at the time of writing, they cannot be created (yet).

I ended up defining all kinds of rules and conventions for constructing business applications. And this system can in time adapt to all kinds of situations. Now that JMatter is open source, it has a diverse and growing community, with diverse needs. JMatter has changed over the last few months to address not only bugs, but desires for this system to meet these users' needs.

We still have many items on the drawing board, much of it has to do with providing implementations for cross-cutting concerns that are not yet addressed. Implementing reporting: defining, saving, editing, and running reports that produce PDFs for example, all directly from the UI. Finishing Authorization. I'm proud of the fact that the basic design I have is very simple and clean. But this work is not yet complete. Scheduling features could use a number of improvements. Still, much is already in place, and the user interfaces of JMatter applications, both in terms of their richness and simplicity, is something that I am proud of.

Many things go into making a project or a product successful. Trusting the community. Managing the project with responsibility. Communicating with the community. Integrating patches. Providing good documentation. Perseverence and keeping the momentum going. Today we have more tools at our disposal than ever to keep the momentum going, from blogs to mailing lists, subversion repositories, great tools for producing documentation, content management systems and much more.

JMatter Blog: Taking a little time to reflect

Taking a little time to reflect

UI

Persistence

Core