Wille Faler’s Buzzword Bingo

I know it’s not very nice to highlight-, poke fun at- or ridicule other peoples mistakes, but this one was so bad, I couldn’t help myself.. A colleague of mine came across this piece of code earlier today (somewhat obscured to protect the not-so-innocent):

try {
    Class clazz = Class.forName(”com.someorg.Foo”);
    Object o = clazz.newInstance();
    Method setBar = clazz.getMethod(”setBar”, new Class[] {int.class});
    setBar.invoke(o, new Object[] { baz });
    return o;
} catch (Exception e) {
    e.printStackTrace();
}

..it is wrong on so many levels, I don’t even know where to begin. Every line is a glaring mistake.
Whatever is wrong with:

Foo foo = new Foo();
foo.setBar(baz);


The original code at the top instantiates a specific class, invokes a specific method through reflection, all of it hardcoded, why oh why would anyone ever want to do that? (Note: I haven’t even mentioned that the Exception just gets swallowed into oblivion, maybe or maybe not visible in some log somewhere..).

I will be holding a presentation/introduction to Wicket RAD at the next London Wicket User Group meet-up on the 6th of August at 6:30pm. The meet-up is held at Google UK’s head office, which is very close to Victoria Station in central London.

There will also be a couple of other interesting presentations, and the events are usually very enjoyable, and for those who want to, there are usually beers in a close by pub afterwards.

Details and a registration form for the LWUG event can be found here.

Read more on the Wicket RAD wiki about this release.

There is also a new, simple “getting started” guide on the Wiki. More documentation to come..

This should be getting closer to a more API stable core for a future “1.0″ release, there is still some cleaning up and refactoring to be done in the core API’s, but for someone using the bean annotation driven generation, this should not have much, if any impact from this version on (we hope).

Just a short update for anyone who may be following this blog to see what is going on with Wicket RAD:

I am expecting to make a release probably sometime before next sunday (it could even be this weekend, if I have the time). This will be quite a major update compared to the previous version, and pretty close to the level of functionality that could potentially go into a “1.0″ release. It will however not be called “1.0″ quite yet, although it is stable and very well tested, as there may still be some refactoring and API changes coming in (to me, “1.0″ is a milestone where you bolt yourself down to having a certain level of API stability and backwards compatibility for future versions).

However, I will probably not make too much noise around the upcoming release outside of this blog just yet, as I plan to spend a lot of time up until August doing documentation - creating a website, improving Javadocs, creating reference manuals, quick start guides and samples. I believe it is essential for an open source project to be easy to get into for it to gain wider adoption.

Recently, I’ve been entertaining the thought of using Maven as a potential deployment environment.

Sure, Maven is a build tool first and foremost, and it also has its fair share of quirks and idiosyncracies, but not anymore so than just about any J2EE/JEE server, and you’ll certainly get less bloat.
The combination of running something such as an embedded Jetty server via Maven, with the nice dependency- and version management of Maven certainly is appealing, it definitely makes for an environment that is bloat free, runs exactly the software it should run and minimizes the risk of having some obscure dependency conflict in the server cock things up for you. The fact that you can tailor your “server” just about anyway you want easily and programmatically is just the icing on the cake.

The thing you might loose if you are of an “enterprisy” bent might be the management and monitoring capabilities of something like Websphere or Weblogic, but then again, in my experience this is usually mostly hot air: people talk a lot about using those capabilities in the early phases of projects, but end up using almost none of it once it comes around to running the resulting application in a production environment. And if you really need it, there’s nothing to say you can’t do it easily yourself, with more fine-grained and context appropriate control.

I’m quite encouraged by the feedback I have received for Wicket RAD - the little RAD web framework (built on top of Wicket and JPA) that I have been working on recently.

I have had quite a few e-mails about it, and to date, it has been downloaded 944 times(and counting..) in the ten days since the first release, which is way beyond anything I expected in such a short space of time. A lot of that traffic has obviously been driven from the mention on TheServerSide.

I had an interesting Skype talk with a couple of guys today (names not mentioned, as I don’t know if they want to be mentioned, and haven’t asked for their permission), where a few quite good ideas where given to me, with more to come.

I think that one idea put forward by the guys was particularly good, and idea which I myself have toyed with over the last couple of days, is the idea to make Component generation metadata agnostic - in other words make the annotation- and bean-driven approach currently used just one of several possibilities.
Other future possibilities could be being able to generate forms with validation and other components straight from the metadata of an SQL database table or a CMS repository.

I already have a few ideas about how to go about this, that won’t change or impede the ease-of-use of the annotation-driven bean approach, and won’t convolute the code. I have already implemented a first stab at this for property-validation, where annotations are still used for metadata, but the retrieval of IValidators for the generated form is not dependent on this being the source. Anyone wishing to get early access to this can obviously have a look in the SVN repository (or simply browse SVN with a browser).

I think considering that the annotation driven bean form generation is already semi-mature, the metadata agnosticism will be the thrust of the effort in the short term, with a new release hopefully being made in the next week or two (time and neglected girlfriend permitting).

Underlying reason/motivation of Wicket RAD
Wicket RAD came out of the realization that around 90% (made up statistic, but probably accurate) of all Java Web Applications are more or less composed of functionality to Create, Read (display), Update and Delete (”CRUD”) data that resides in a database. The process of shovling this data back and forth from the web pages to the database usually consist of the following steps for programmers:

• Bind form components (such as textfields) to the properties of a Java object (a “bean”). It is very rare that forms are backed by either more or fewer than one single bean
• In turn bind validations/validators to said form components so that the inputs are validated before they are bound to the bean
• Take the submitted bean and send it to a backend “Service”
• Write said backend Service so that it can do CRUD operations on said bean
• Navigate to next page, rinse and repeat

Hardly rocket science, nor very advanced stuff, but very repetitive and sometimes error-prone (code duplication, massive amounts of similar markup with minor inconsistencies etc is not unusual). A disproportionate amount of time is usually spent on this compared to higher hanging fruit.

So if the bean object itself is the central piece of this process, while all the other steps are more or less repetitive, why don’t we just cut out the bulk of the repetitiveness? Why don’t we just annotate the bean itself with metadata telling it how it is mapped to a database, and how it’s properties map to a form (how they should be displayed and validated)?
This is where Wicket RAD comes in, it does away with the repetitiveness of this process and deals with the heavy lifting for you.

Philosophy & Goals: “Less is more!”
The overarching philosophy of Wicket RAD is “less is more!”, you should not have to write 500 lines of boilerplate code and markup to do something in your webapp if it can be done in 50 lines of code.

Put in other words, the main goal of Wicket RAD is to supercharge developer productivity by letting developers do more with less code when developing web applications (something which Wicket alone already achieves, but Wicket RAD builds further on that).
Wicket RAD will provide a set of Wicket Components and JPA utilities aimed at doing the heavy lifting and legwork for the developer, freeing the developers to do what is important in his/her specific project, rather than write repetitive boilerplate code.

We have been doing webapps for going on twenty years, so by know it should be quick and simple for anyone with a little Java knowledge!

Design principles
In practical terms, we try to achieve the goals of Wicket RAD through the following design principles:

• Do not repeat yourself: If a certain type of problem can be solved with a single solution, only solve it once
• Simplicity & focus: Make the simplest, most compact solution possible. Each class/interface in Wicket RAD should have a tightly defined, specific purpose.
• Flexibility and modularity through composition: Don’t want to use the “full stack” solution, but only the frontend Components or backend functionality? Be my guest, it should always work. Want a different type of layout for your BeanEditPanel that is not available by default? Just compose the smaller components that a BeanEditPanel consists of in different ways. You should be able to take everything as is, or pick and choose what you want and build the exact thing you need.
• Testability: For Wicket RAD to give developers confidence and empower them to do more with less code, it is imperative that Wicket RAD is properly tested, and can be regression-tested in no time. Therefore it is an aim to have good test coverage of all code, and accept no major contributions unless they come with a satisfactory suite of unit-tests (useful contributions are more than welcome, just make sure it comes with tests).

I know these principles will be self evident to most of you, but I still feel it is important to note them, because sometimes it is easy to loose sight of the forrest because of all the trees.

Obviously, I reserve the right to edit/change parts of these goals/principles/motivations in the future, if and when I can be even more focused and specific (”Less is more” even in this case).

A last minute note for anyone interested: there will be a London Wicket group meetup tomorrow evening at 6:30pm at Google UK’s head office near Victoria Station. Full details and registration info can be found here.

Among other things, I will hold a short presentation on using the Open Session in View pattern in Wicket to ease development of applications that use a database. The presentation material and sample code I will use will most likely turn up on the main London Wicket website some time after tomorrow evening.

Wicket RAD now has a Nabble Forum.

Over the past month and a bit, I have spent some time in my spare time distilling some of the most effective practices and lessons learned from a year of using Wicket into an open source framework, which I have (not so) imaginatively named “Wicket RAD”, among other things, it contains the following things:

• Open Session In View pattern implementation using Wicket and JPA: Simplifies creating database-driven web applications with Wicket by making transaction- and connection management transparent to the developer, and making lazy-loading simple as there is always a persistence context open and available.
• Annotation driven bean form generator Components: allows you to quickly generate forms without writing any markup by simply annotating Serializable java beans with appropriate input- and validation annotations such as @TextField, @CheckBox, @DropDownChoice etc, (and @Required, @Length(min=4, max=10) etc for validations).
• Components bringing together the two things mentioned above: Just drop your JPA- and bean form annotated bean into a DefaultCreateBeanForm to generate a form and persist the bean on submit, or a DefaultUpdateBeanForm to update. Creating forms and Creating, Reading, Updating and Deleting data in web applications has never been easier!

The project home page can be found here.

The 0.2 release files, including Javadocs and a somewhat hastily written user guide with a few code samples can be found here.

Any feedback/questions can be sent to the Wicket RAD Nabble forum.

The project is mavenized and should build nicely with Maven 2, if you simply follow the instructions in the provided README.txt file. The project is released under a commercial friendly Apache open source license.
I’m hoping to improve the documentation and code samples considerably over the summer, time permitting, as I do realize it is somewhat scarce on the ground.
The current version is 0.2, which means that API stability is not guaranteed, however, apart from making it easy to cleanly implement a larger variety of layouts, I wouldn’t expect the external API’s themselves to change much in the future.

Also, some credit where credit is due:

• DataBinder - haven’t used it, but I’ve read up on it’s concepts, and seems to do a similar thing to Wicket RAD’s OSIV implementation, but for Hibernate.
• London Wicket - My original idea for the bean editor was a continuation of material from the beaneditor presentation.
• Wicket - of course.. Brilliant, brilliant framework that made me enjoy web development again.

(On a final note, I hope the Wicket guys don’t mind my unimaginative name for this open source project. If there are any objections, do let me know and I’ll try to think of something better.)

UPDATE

Bumped up the version from 0.1 to 0.2 to reflect a quick update release fixing some minor bugs, making the build simpler and providing a sample application.