Stephan Schwab - frameworks tag

Adobe Demos "Thermo" RIA Design Tool to Delighted Crowd

Wed, 03 Oct 2007 20:46:30 GMT

This sounds quite interesting:

Josh Catone in Adobe Demos "Thermo" RIA Design Tool to Delighted Crowd:

The presenters really got the MAX crowd rocking by showing off Thermo's "Convert artwork to..." feature. In a matter of a couple of clicks, a text input box on the UI went from static image to actual form field with the MXML code rendered automatically. Thermo even preserved styling of the form element from the PSD mockup.

The code view for Thermo is actually the full Flex Builder application, which means that it is a powerful development tool for programmers, as well. The idea is that developers can write underlying business logic for a Flex application while designers work on look and feel all from inside the same environment, and the process is as painless as possible for both sides.

But I have my doubts. That awfully sounds like code generation and as to the best of my knowledge that's usually a one-way street. You use a tool to generate the code and once you start making changes to the generated code you can't use the tool anymore or have to reapply the changes again.

On the other hand if that "Convert Artwork To ..." function creates a component, that would be a good solution. I might have to look into Adobe Flex a bit more to understand what's going on here. But at the very least this is an interesting idea and I'm going to see whether we can adopt it a bit and make use of it in our collaboration with a designer we've just added to our Savila development team.

Starting to love EJB3 Hibernate Annotations

Fri, 09 Mar 2007 03:24:31 GMT

As our current project allows for some experimentation and adoption of recent technologies, we spent today with EJB3 Hibernate Annotations to get away from the XML configuration one used to create with Hibernate before.

The annotations need to be placed in the same compilation unit as the entity class lives in. The result is that these POJOs now are no longer POJOs in a very tight sense. That has been criticized as polluting the codebase with ORM specific annotations. That's certainly right, but one does not replace one ORM tool for another very often and going with the EJB3 Java Persistence annotation one can replace ORM tools, as Hibernate is just one implementation of that API. So I wouldn't fear too much. After all those classes that become entity classes are meant to be stored into a database and somewhere I have to put the mapping. Doing so in Java code instead of an external XML file appears to be clearer and more appealing to a developer.

Here is something we learned today.

Let's define a persistent entity class called Issue.

@Entity
@Table(name="issue")
@NamedQueries( { @NamedQuery(name = "findIssueById", query = "from Issue i where i.id = ?") })
public class Issue implements IdentifiableObject {

  @Id @GeneratedValue
  private long id ;

[...]
}

This entity will be persisted into the table issue and you see that it has an id field. Other fields are omitted for clarity. Further we define a named query findIssueById.

In a generic DAO class using Spring's Hibernate template we create a method findById as follows.

public Object findById(String query, long id) {
  List list = getHibernateTemplate().findByNamedQuery(query, id);
  if (list.isEmpty())
    return null ;
  else
    return list.get(0) ;
}

Elsewhere in the application we can the find any entity by calling findById passing in the name of the named query and of course the query criteria id.

Issue issueRead = (Issue) repository.findById("findIssueById", someId) ;

In your Spring application context configure your session factory using the AnnotationSessionFactoryBean.

<bean id="mySessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
  <property name="dataSource" ref="myDataSource"/>
  <property name="hibernateProperties">
    <props>
      <prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
      [...]
    </props>
  </property>
  <property name="annotatedClasses">
    <list>
      <value>net.caimito.savila.Issue</value>
    </list>
  </property>
</bean>

Tapestry: first experiences

Sun, 04 Mar 2007 20:30:49 GMT

Together with Fidel, Caimito's new hire in Panama, I started to experiment with the component-based web framework Tapestry. We were inspired by Brian Sam-Bodden's book Beginning POJOs and Brian's personal recommendation of Tapestry.

There are two types of web frameworks: request-based and component-based.

Request-based frameworks like, Struts, WebWorks (now Struts 2), SpringMVC and others expose the HTTP request/response cycle directly and only map that to actions or controllers where you code something to do the work. These frameworks expect you to code the action and provide the view with some other technology. Common view technologies are JSP, Velocity, FreeMarker and others. These view technologies combine HTML tags from a template with values that are injected by the framework and carry your output information.

Component-based frameworks don't expose the HTTP request/response cycle and they don't use a separate view technology. Instead they let you create your application in Java without thinking too much about the web. Sun's JSF (Java Server Faces), Apache MyFaces (an implementation of JSF) and Tapestry are component-based frameworks.

Everything is a component

With Tapestry everything is a component starting with the web page itself. Instead of a lot of XML files Tapestry 4.1 comes with annotation support. Add an extension to support Acegi Security and you can use the following code to create a secured page accessible by authenticated users with the role ROLE_USER only. The HTML comes from a file SomePage.html.

@org.acegisecurity.annotation.Secured("ROLE_USER")
public abstract class SomePage extends BasePage {
}

Links

If you want to link to SomePage, you write:

<a href="#" jwcid="@PageLink" page="SomePage">Some page</a>

Form handling

Let's say you want to code a page with a search form. You create an HTML template called Find.html (formatting details omitted for clarity):

<form jwcid="form@Form" listener="listener:doSumit">
<input jwcid="search@TextField"	value="ognl:idNumber"/>
<input type="submit" jwcid="@Submit" value="ognl:messages.getMessage('submit')"/>
</form>

Tapestry makes use of the fact that web browsers ignore tags and attributes they don't know. jwcid is used to refer to a component and the other non-HTML attributes are passed on to the component referred to by jwcid. This template creates a form with an text input field and a submit button. Further you can see Tapestry's support for internationalization. ognl:messages.getMessage('submit') reads the value for the submit key from a Java resource bundle. So you can create properties files Find.properties (default), Find_es.properties and Find_de.properties to support English (en) and Spanish (es) specifically and leave everything to the values in the default file Find.properties. Quite easy - isn't it?

Next is the code for the Find page:

@org.acegisecurity.annotation.Secured("ROLE_USER")
public abstract class Find extends BasePage implements PageBeginRenderListener {

	public abstract void setIdNumber(String idNumber);
	public abstract String getIdNumber();

	@InjectPage("EditUserStory")
	public abstract EditUserStory getEditUserStory();

	@InjectPage("UserStoryDoNotExist")
	public abstract UserStoryDoNotExist getUserStoryDoNotExist();

	@InjectObject("spring:repository")
	public abstract FileBasedIssueRepository getFileBasedIssueRepository();

[...]
	public IPage doSubmit() {
		if (getIdNumber() != null) {
			Long id = Long.parseLong(getIdNumber());
			UserStory userStory = getFileBasedIssueRepository().find(id);

			if (userStory != null) {
				EditUserStory editUserStory = getEditUserStory();
				editUserStory.setUserStory(userStory);
				return editUserStory;
			}
		}
		return getUserStoryDoNotExist();
	}
}

The @InjectPage annotation lets the Find class know about other pages. With @InjectObject you can inject into your class references to HiveMind services. Tapestry 4.x uses HiveMind and IoC container. With @InjectObject("spring:repository") we inject a Spring bean called repository. So you can see there is an easy way to combine Tapestry and Spring although Tapestry doesn't use Spring.

Further down in the doSubmit method the return value represents the page Tapestry should show to the user. To us as Java developers this is just a page object and has nothing to do with any kind of HTTP redirect. That's nice, because we can stay within the world we know.

Learning curve

One might expect that Tapestry's learning curve is high. But to my surprise it isn't. Fidel had never worked on a web application, but has worked on Swing applications before. It took him 3 days to set up his work environment (Eclipse, Maven), read about Tapestry, check out the samples from Tapestry's tutorial. After that warmup he got productive and created a useable application with business logic and even some nice design in CSS within a week.

So in my conclusion Tapestry is a very productive framework. Of course there is more to explore. On the 3rd day we started to explore how to create custom components and in that area is most of the stuff to learn more about.

Checking a bean's health

Tue, 30 Jan 2007 05:22:53 GMT

Sometimes the little details get overlooked. While I'm working on my book about Acegi Security I read a lot of its source code and that's always a refreshing learning experience. In fact I'd like to recommend anyone to take advantage of open source and take it literally: read the source. It educates and stimulates.

What did I find? Nothing big, but still something I had overlooked in a past project when I wanted to make sure that beans that were vital to the system have been properly initialized. In Spring there is the InitializingBean interface, which defines the afterPropertiesSet() method. Spring will call this method on all beans implementing this interface after it has set the bean's properties.

Now you can use Spring's Assert class to perform checks and have an exception thrown, if something is wrong. It's all built-in and free.

Most common mistake: start Swing applications off the right thread

Wed, 24 Jan 2007 18:04:45 GMT

While reading Improve Application Performance With SwingWorker in Java SE 6 from the Sun Developer Network I found that I made the most common mistake in Swing programming myself as well.

All Java programs start with an initial thread out of the main() method. A lot of people - including myself - will create the application main window as a JFrame there in main() and show the UI. That's wrong!

The correct way is to use the Event Dispatch Thread (EDT) for all user interface related stuff. So creating the application main window outside of the EDT is wrong, because it might lead to thread synchronization problems later. The right way to do it is to use the invokeLater() method from SwingUtilities:

public class MainFrame extends javax.swing.JFrame {
 
  public static void main(String[] args) {
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        new MainFrame().setVisible(true);
      }
    });
  }
}

Doing so has another advantage. The call to invokeLater() returns immediately allowing your application to perform other initialization tasks without delay. If a wait is required, one can use invokeAndWait() instead.

[TSE] Meeting Requirements through Acceptance and Stress Testing

Sun, 10 Dec 2006 13:57:45 GMT

My fellow German developer Eberhard Wolff is speaking this morning about acceptance and stress testing to meet requirements.

As an introduction he's wrapping up what Spring provides in the org.springframework.test package.

Acceptance Tests

Now we are getting into Acceptance Tests. You use them to find errors in the implementation of business requirements or use cases. One can see them as formalized requirements. Unfortunately many times they are done manually and after the whole system has been developed. Fit/FitNesse is a tool for acceptance tests. The customer and the developer should write the acceptance tests together - so does XP say. Fit/FitNesse uses HTML as input format. Test data and expected results are provided as HTML tables. You need to write a simple class as a wrapper for business logic, which can be injected using @Configurable. This class is then used to pass data into the test and check the results.

Eberhard is working on a general Fit Exporter for Spring. It's currently Alpha code.

The SpringActionFixture can be used to test actions that are usually performed in a GUI. You specify input data and actions - e.g. press add button - and then look for results. In the HTML input file you use the expression "press" to call a method. So the UI stuff is left out, but the method that normally be called by the UI is now being called by FitNesse.

One question from the audience is whether you can run Fit/Fitnesse as part of a Maven build. As it's a command line tool that should be no problem.

Fit uses HTML files as input. Fitnesse uses Wiki pages. Triggered by a question from the audience Eberhard opinions that probably Word documents that get exported to HTML are the best solution to get business people to provide test data and rules.

Performance Tests

JMeter is a good tool to performance test web based applications. JMeter creates a large number of requests, but how do you measure the performance in the whole system. You want to measure each part of the system. Using a regular profiler for Java would not be sufficient for the purpose of performance tests, because it only focuses on the Java code itself. JAMon is a monitoring framework, which offers a Spring interceptor. For web application you configure a filter in web.xml. The JAMon filter measures HTTP request/response. JAMon profiles method calls using AOP. JAMon can be used as well to profile other parts of the system by simply declaring other AOP aspects, e.g. you could use it to profile SQL queries.

One could use JAMon even in production as the overhead is very little. It can use exiting Pointcuts and Spring AOP proxies.