Web application generation with Woko

Ever wanted to quickly protype a CRUD web application with Java? If so, Woko might be what your're looking for.

Well, I was looking for something like that and one of the Stripes guys (thanks Kai!) pointed Woko out to me. It's 95% of what I was hoping for.
I'm currently evaluating Woko for an adventure tours agency. The goal is to scaffold a simplistic application, based on a simple domain object model. What we want is:

• Generated GUI for editing simple properties like names, dates, numbers


• Transparent persistence


• "Convention-first, Extension-when-necessary" development


• Quick: demo must run out-of-the-box


• No sophisticated security/authorization/authentication, as it will be an intranet-solution with a low number of users.

Woko does a quite nice job in that direction.

Woko generates the user interface for viewing and editing entities dynamically. As we all know, this is fine for simple objects. But when it comes to real-world domain models with complex types and relations between objects, it gets a bit nastier. However, Woko follows the way to have the main use cases being default, and only if someone requires something more, he can overwrite the default behaviour. This is done using facets (see JFacets), additional classes which describe the way how e.g. properties are being viewed and edited.

My first steps with Woko were:

1. Watch the screencast, then install and get the woko-template running as-is.


2. Play around in the existing Library-example: adding new books, authors, deleting, editing properties, searching


3. Write some new POJOs and annotate them with JPA. I just copied most of the existing annotations from the demo classes to my own classes.


4. Run "mvn cargo:start" again and try out my changes: creating objects of my new classes, edit them etc.


5. Reading some parts of the Woko documentation


6. Implement a simple command facet: I added a Customer class and a Tour class. Then I wanted to have a "Make Reservation" operation on that customer, so he can book a Tour.
   

Implementing a command facet:

I added a new Class which implementes ICommandFacet. (I removed all getters/setters/logging etc. and some other non-interesting stuff)

@FacetKey(name = "makeReservation",
          targetObjectType = Customer.class)

public class MakeReservationCommand
          implements ICommandFacet {

 @NotNull Tour tour;
 @NotNull Date startDate;
 
 public Resolution execute(ActionBeanContext actionBeanContext) {
  Customer customer = (Customer) getTargetObject();

  Reservation reservation = new Reservation();
  reservation.setCustomer(customer);
  reservation.setTour(tour);
  reservation.setTourStartDate(startDate);
  
  getPersistenceUtil().save(reservation);
  return Util.redirectToView(reservation);
 }

}

The important stuff, top down:

• The FacetKey annotation specifies on which objects the operation can be performed and how the operation is named


• The operation will be automatically* shown as link when you edit a Customer. Clicking the link will bring you to a form where you can enter the required information to execute the operation. In this case, this is a Tour instance and a start date. Woko automatically generates a date picker for the Date property. To show a selection box for the Tour, it took me a while, but I think the Woko developers will make that easier in the upcoming release.


• When the user entered all information into the form and clicks submit, the execute() method is called and all properties are validated. I can now simply instantiate my Reservation object, set all the properties into it and persist it to the database.


• The last line will bring the user to the page to see the newly created reservation. Note that you simply specify the object instance to view (reservation), and not some JSP URL.

That's it for today. Thanks for reading


*Well, it's not really automatically. Commands are not shown by default and must be activated by implementing a command facet which returns a list of Strings with the names of the commands to show. Actually, this makes it very easy to show different operations per role of the logged in user. E.g. a user sees other commands than an administrator.

• Comments (2)
• Trackbacks (0)