Webbit + SiteMesh = …. well, Webbit and SiteMesh
SiteMesh is now available for Webbit Server:
Tutorial here: https://github.com/joewalnes/webbit-sitemesh
Joe Walnes
Software development. And stuff.
Posts Tagged ‘ Java ’
New QDox lead – Robert Scholte
I’d like to announce the new lead for QDox, Robert Scholte.
Anyone who’s been following the project for the past year would have seen that Robert has made a tremendous number of contributions to all areas of QDox, including bug fixes, build, docs/website, releasing, user support and admin. If you follow the project further back, you’ll see that Robert has actually done more on the project in the past year than was done for the combined 6 years before that…. impressive.
I originally wrote QDox back in 2002, as a stop gap until annotations were added to the Java language. It was quickly picked up tools such as XDoclet. I always thought (and hoped) that once annotations made it into the language, it would be redundant. Yet it lived on. Unlike the JDK Annotation Processing Tool (APT), it could process source code rather than byte code in a simpler and faster manner. And it provided access to information that the JDK didn’t make available (e.g. parameter names). And it was useful where annotations still did not exist, like in JavaME. So, even in 2010, it still lives on and is used in tools such as Maven and Eclipse. But I cannot invest the time into it that I once could.
Given Robert’s commitment to the project, I can think of no better person to lead the project. He’s done an astounding job. Robert has kindly accepted this role and I’m delighted to hand it over to him.
I’d also like to use this opportunity to thank Paul Hammant, Mauro Talevi and Dennis Lundberg for their ongoing efforts on the project.
Running SiteMesh on AppEngine
Does SiteMesh work on Google AppEngine (Java preview)?
Short answer: Yes.
Longer answer: Yes. It does. So long as you check 2 things…
1. Upgrade
You need SiteMesh version 2.4.2 or greater. Earlier versions do not support AppEngine.
2. Disable static file serving
If you want decorators to be applied to static content (e.g. to .html files), the following needs to be added to WEB-INF/appengine-web.xml:
<static-files> <exclude path="**"/> </static-files>
This forces the static resources to be served by the Servlet engine, rather than a separate static web-server. Without this, the files served by the static web server will not be decorated.
Happy AppEngining.
SiteMesh 2.4 released
After a long wait, SiteMesh 2.4 has just been released.
This mostly consists of minor bug fixes and improvements.
Qt, now a viable option for Java
Today it was announced that Qt would be made available under the LGPL license. Qt is well known in the Linux community thanks to KDE, but Qt based applications run very well on Windows and OS X, as well as many embedded platforms such as WinCE and S60.
I’m a closet Qt fan, because:
- It has a clean OO programming model. Simple, extensible, yet not over the top.
- It has easy to use bindings for a wide variety languages, including C++, Java, Python, Ruby, Perl, PHP, and C#.
- It’s mature with a rich set of widgets. Including typical windowing components, a WebKit based browser, media playback, OpenGL, etc.
- The resulting apps look good, feel fast and fit in with the native platform.
- It’s very extensible/flexible.
Of course, on each of those points alone there are other frameworks that can beat Qt – it’s the combination of all of these that makes it so compelling.
Oh yeah, Java…
Jambi is the Qt binding layer for Java. It’s actually been very well thought out, allowing you to use pretty much any of the functionality in the C++ layer, with a simple Java API and set of conventions. It also includes bindings allowing Qt and Swing components to seamlessly co-exist in the same UI.
There are parts of the Qt Java API that make me cringe slightly (namely using reflection for event callbacks), but overall the benefits outweigh these – I’ll just have to get over the cringey bits and live with them.
I’ve used Swing and SWT extensively on some big (and small) projects. I’ve only dabbled with Qt, but from that I’ve been productive very quickly and built some solid UIs in little time. The reason why I’ve previously chosen not to use it on ‘real projects’ was due to licensing. Now that it’s LGPL, that changes everything.
If I were to start a new project tomorrow and needed a serious Java UI, Qt would be my first choice.
Ok, that wasn’t really a convincing argument. How about checking out:
Creative uses of Hamcrest matchers
The matcher API of Hamcrest is typically associated with assertThat() or mocks. I always knew other people would find good uses for it, but I never really knew what.
I particularly like these:
Collection processing
Håkan Råberg blogged about how Hamcrest can be used with iterators:
List<Integer> numbers = Arrays.asList(-1, 0, 1, 2);
List<Integer> positiveNumbers = detect(numbers, greaterThan(0)));
List<String> words = Arrays.asList("cheese", "lemon", "spoon");
List<String> wordsWithoutE = reject(words, containingString("e"));
Nothing rocket-sciencey about it. But simple and useful because it reduces boilerplate code and get to use the ever growing library of Hamcrest matchers.
On top of that, combining Hamcrest with a CGLib generated proxy, he has built a staticly typed query API:
List<Person> employees = ...;
List<Integer> allAges
= collect(from(employees).getAge());
List<Person> allBosses
= collect(from(employees).getDepartment().getBoss());
List<Person> allAccountants
= select(from(employees).getDepartment().getName(),
containingString("Accounts"));
This is nice alternative to a string based query language as you get your IDE completions, refactoring, compile time checking etc, without the noise of boilerplate code.
Web testing
Robert Chatley has taken some of the concepts of his LiFT framework and reimplemented them using Hamcrest and WebDriver for performing web testing.
public void testHasLotsOfLinks() {
goTo("http://some/url");
assertPresenceOf(greaterThan(15), links());
assertPresenceOf(atLeast(1), link().with(text(containingString("Sign in"))));
clickOn(link().with(text(containingString("Sign in"))));
assertPresenceOf(exactly(1), title().with(text(equalTo("Sign in page"))));
}
Now initially this seems a bit wordy and strange. Robert has designed this as a literate API. If you adjust the syntax highlighting of your API and make the Java keywords and syntax less visible, you get this:
goTo "http://some/url" assertPresenceOf greaterThan 15 links assertPresenceOf atLeast 1 link with text containingString "Sign in" clickOn link with text containingString "Sign in" assertPresenceOf exactly 1 title with text equalTo "Sign in page"
The motivation here is that the API usage is self documenting and could be useful to non-programmers. The flip-side to this is that it’s actually quite hard to write APIs like this and the usage can take quite a bit of getting used to.
Robert also introduced a Finder interface (the link() and title() methods return Finder implementations). This allows you to factor out your own UI specific components:
assertPresenceOf(atLeast(1), signInLink());
clickOn(signInLink());
assertPresenceOf(exactly(1),
blogLink().with(urlParameter("name", containingString("joe"))));
This is the bit I really like.
Allowing abstractions of components and matching rules to be combined in many different ways, so tests can check exactly what they need to, resulting in reduced less brittle tests that are easier to maintain.
Other uses
As I hear of other uses I’m listing them on the Hamcrest wiki.
When it goes bad
Of course, like any technology, it’s easy to get carried away.
Here’s an example of Hamcrest gone bad:
assertThat(myNumber, anyOf(equalTo(0), allOf(greaterThan(5), lessThan(10))));
I’m not a LISP programmer, so I find that really hard to understand. Just because we have an assertTHAT() method, we don’t have to use it all the time. In this case it’s much simpler to use plain old assertTRUE():
assertTrue("myNumber should be 0 or between 5 and 10",
myNumber == 0 || (myNumber > 5 && myNumber < 10));
Even though the non-Matcher version is longer (it could be shortened by leaving out the message and using a shorter variable name, but that would make it harder to understand), I find it much easier to understand.
But, what if you actually needed to use a matcher (e.g. for the web testing or collection processing examples above)?
One approach is you could use higher level matcher that are composed of other matchers:
matcher = anyOf(equalTo(0), allOf(greaterThan(5), lessThan(10))) // simplifies to matcher = anyOf(equalTo(0), between(5, 10))
Complete tangent: An alternative to between(5, 10) is between(5).and(10). The latter makes for more literate code, but is harder to implement – again a design tradeoff.
Another approach is to create a one-off anonymous matcher implementation:
matcher = new CustomMatcher() {
public boolean matchesSafely(Integer n) {
return n == 0 || (n > 5 && n < 10);
}
}
What are you doing with Hamcrest?
Updates:
- JUnit 4.4 now comes with Hamcrest and assertThat().
QDox is back – 1.6 released
QDox history
QDox is a fast JavaDoc/Java parser built in 2002. It was originally intended as a stop gap until Java supported annotations by allowing tools to easily get access to JavaDoc attributes. Essentially it provided nothing more than a stripped down version of the JavaDoc Doclet tool, with performance suitable for using in continual build cycles (what would take JavaDoc over ten minutes to process would typically take QDox less than ten seconds). It served its purpose well.
The death of QDox
Then came along Java 5 and I stopped actively working on QDox. The first reason was that with the new annotations support, QDox wasn’t necessary. The other reason was that it would take a lot of effort to update the parser to support Java 5 syntax (not just for annotations, but generics, enums, etc).
And so QDox went quiet. The dev team lost interest and the releases stopped.
QDox is reborn
It turned out, I was wrong. Even with Java supporting annotations, QDox in a Java 5 world has some benefits:
- Some Java 5 projects still want to use JavaDoc attributes (as well as annotations). Maybe for legacy reasons.
- QDox acts on source code, rather than byte code. This can be useful in chicken and egg situations where you need to generate source from existing source, but you can’t compile until you’ve generated the code.
- QDox exposes information that isn’t exposed by reflection, such as names of parameters or JavaDoc comments, which are useful for building tools to help visualize code.
So, by popular demand, I’m resurrecting the project. Yay.
1.6 released
This new release is a stop-gap release. Highlights include:
- Switched to Apache 2.0 license.
- Parser can now deal with Java 5 source code (annotations, generics, enums, var args, etc).
- Numerous bugfixes.
This should be enough for existing projects to carry on using it with Java 5 code.
The next release will focus on making Java 5 specific features available in the API. Stay tuned.
Java and .NET RESTful interoperability with XStream
My ex-colleagues Paul Hammant and Ian Cartwright have written an article on their experiences of building SOA applications using RESTful services in .NET and Java that could interoperate over web services and message queues. XStream made this possible.
Buzzwordtastic.
OSCon: SiteMesh, SiteMesh, SiteMesh, SiteMesh
Just got back from the O’Reilly Open Source Convention in Portland. Fantastic conference – met lots of really interesting people (and the odd nutter).
It was a good conference for SiteMesh. It opened my eyes to two things:
# SiteMesh rocks. People who have tried SiteMesh, love it and don’t turn back. Their preferred choice for web framework changes, but SiteMesh remains constant.
# Our marketing sucks. Despite it being around for 5 years, most of the Java web app community have never felt the need to try it.
I was there to present a session on SiteMesh but a lot of other speakers beat me to it. It kept slipping into other sessions…
h4. Using AppFuse for Test driven Web Development, Matt Raible (details)
Matt gave an overview of the technology stack used in his AppFuse application. Despite having 5 versions of his app that use different frameworks (Struts, WebWork, Tapestry, Spring MVC and JavaServer Faces), all used SiteMesh. Good!
h4. Integrate: Building a Site from Open Source Gems, Erik Hatcher (details)
Erik walked us through the open source products he used to build his Lucene Book website and what customizations he made. The focus, of course, was Lucene and I learned a lot of great tricks about Lucene that hadn’t occurred to me before – such as using “sounds like” queries with soundex and indexing images by colors. I continue to love Lucene.
A great point that Erik mentioned was the need to become intimate with the projects you use. If you truely want to make the most of your frameworks, understand how they work, join the community and extend them.
Erik chose Tapestry to build the site but he also had Blojsom and some static content, so SiteMesh was useful to integrate these and he created some custom code to build SiteMesh decorators with Tapestry.
He pointed out that despite submitting this useful Tapestry integration to the SiteMesh project, nothing had made it into the SiteMesh release. Feeling embarressed, I committed his changes immediately, inadvertently breaking the build and providing great ammunition for Eric Pugh’s session on the importance of continuous integration.
h4. WebWork vs Spring MVC Smackdown, Matthew Porter and Matt Raible (details)
The basic plot was this… Matthew Porter was arguing why Spring MVC sucks and WebWork rocks. Matt Raible was arguing why Spring MVC rocks and WebWork sucks. The only thing they both agreed on was SiteMesh rocked. A fairly heated and passionate debate – great fun to watch. I would have opted for more violence though.
Matthew Porter got the final laugh when he pointed out that he compared the Spring MVC and WebWork versions of Matt Raible’s AppFuse framework and the Spring MVC version had about 25% (I think) more code, not including comments.
(more)
h4. The Evolution of Web Application Architectures, Craig McClanahan (details)
This was an interesting session where Craig compared the approaches taken by Struts, WebWork, Spring MVC, Tapestry and JavaServer Faces. He had done detailed research and, despite his heavy involvement with Struts and JSF, gave a very fair and objective view of the pros and cons of each.
This work could be useful for people evaluating which frameworks to choose and possibly could be overlayed with a guide based on values. The bottom line is there’s no single ‘ultimate’ web framework and depending on your needs and values you should choose the most suitable. I think it would be beneficial to all to have a guide indicating which values each of these frameworks are suited/not-suited for.
So, my question is this: Which values are more important to you when choosing a web framework and in which priority?
These are some example values that spring to mind: commercial support, testability (unit and functional), popularity, extensibility/customization, integration with other frameworks, rich widget support, REST friendlyness, simplicity vs magicness, AJAX friendlyness, learning curve, configuration, etc.
Anyhoo, SiteMesh was probably mentioned enough times to attract another load of people to the SiteMesh session.
I’m really glad these people mentioned SiteMesh and said such kind words about it – it resulted in a lot of interest and a full house for the SiteMesh session. I hope to get these presentations online shortly and write a bit more about how Subversion, Microsoft Word and SiteMesh can be combined to create a rich Content Management System.
h2. Improving SiteMesh’s marketing
The fact still remains that SiteMesh has terrible marketing. I’d love some ideas of how to spread the word more and encourage more people to try it but I honestly have no idea what to do. Any suggestions?
Recent Posts
Me, Elsewhere
- An error has occurred; the feed is probably down. Try again later.
Joe Walnes 