Web application development to me has one central problem: separation of concern between designers/page authors and the 'backend geek'. My firm belief is, that there is a very small number of people, that can do a good job in both areas.
Any of the many webapp frameworks out there has to answer three questions:
- How much has a designer to learn in order to know, what he´s doing?
- How do page-authors and coder collaborate efficiently?
- Is there a good chance for component reuse, while keeping design flexible?
The first point is critical in my current career. Designers have varying degrees of understanding templating systems, pageflow and even tools like CVS. So, one might think, the more a file looks like plain html, the more comfortable he is.
Unfortunately, this leads to minimum flexibility (down to no-chance) for the designer to change the slightest non-optical thing on the resulting web-page.
Approaches that include templating elements like loops, markup and/or expressions can give incredible flexibility to the page-author (note, that i won´t call him 'designer' here), but you obviously have to have a motivated person that wants that flexibility and buys it by learning the relevant technology. This is not as trivial as one might think. There excellent designers out there without thorough understanding for request-parameters, sessions and other fundamental concepts of webapp development.
Taking the JSTL-approach as an example then leads to another observation: The next thing the page-author is not that much interested in is component reuse. So you´ll end up having a awful lot of JSP-pages, and while your serverside is clean an shiny, the page-author has to do a lot of plumbing to turn that into a useful and reasonable website.
While custom taglibs can provide these components, it is hard to know upfront what the designer needs. Refactoring designed functionality into taglibs would be one way to go, but couples the protagonist´s work significantly.
JSF is component-based as well as standard. Chances are, that more and more page-authors will get used to them instead of just running away, screaming. Tool support is a significant showstopper here. As long as there are only eclipse/netbeans-plugins, or even raptor-like tools, you´ll barely see a design-oriented page-author working with JSF. What the need is a dreamweaver-like wysiwyg environment that works in which to design pages with JSF. The problem is the wysiwyg-part here, as JSF implementations differ, and data-providers are hard to mock inside the tool.
There is another hint, that JSF is not even targeted at these persons: The coupling between the java-space and the JSF-layer is quite tight. Seam and frameworks like that, even if the significantly reused overall plumbing, make this even tighter, and this is a significant problem concerning the second challenge:
Functionality changes with time and even at design-time. Webapp frameworks can be measured here by the slow-down they create when this happens. Taken JSP like pages, a coder can just 'script it in', which is the fastest bu ugliest way to do the trick. Remember words like refactoring, dry-principle... On the other hand, this is what JSP were primarily built for, so this is a valid approach. It is just that we have all painfully learned our lessons over the last 10 years 
JSTL makes this a little better, by giving more power to the page-author, which does not have to be a java-geek here. If he can handle that: fine; if not: you´re absolutely screwd. You´ll see any kind of copied/moved/taken out of context tags cluttering the pages because the guy cannot cope with them. This can turn page-authoring to a complete torture with fragile und fundamentally broken pages as a result.
Instead of JSTL-like scripting you could add a custom tag to provide an understood and non-generic interface to the author and at least a level of encapsulation and reusability. Problem here is, that you´d have to redeploy the application, thus stopping every other people´s work. This will take some time to get through the build-test-document-agree upon-build-test-redocument-deploy cycle. Tag-Files should address this problem, but appear quickly as the-worst-of-all-worlds option.
From my experience JSF does not change this problem. Redeployment in order to provide a new method/property on a managed bean is daily business. Long cycle, frightened page-authors (JSF-Pages are quite easy to break) and coders ending up creating JSF-pages.
Don´t get me wrong: JSF is great as a component model on the server side and Seam does a great job eliminating a further layer in the server (aka managed beans) where using the full JavaEE stack. But no matter if you use jsp- of facelets-based templating for JSF, you wont find many page-authors doing this for you.
Struts-like and other MVC based approaches do also link the java-developer and the pageauthor very tightly and chances are, that this leads to the same painful redeployment cycle.
So what about Ruby on Rails/Grails and these shiny new scripting-based approaches?
From my perspective, you can go in this direction as soon as you have decided to create (or extend, in rails/grails case) the pages yourself and only hand a css-file to the designer. Come on, i have not seen many good designers, that could handle JSP-Scriptlets. Do you think, they can cope with closures?
In very technology-oriented webapps this might be ok. Building marketing-websites is out of scope for these solutions, i think. PLEASE try to convert me here.
Flex?
Promising. Just a tooling question + how capable is a 'page'-author of creating and maintaining good actionscript-code?
Yes i am aware of flex having an eclipse plugin where you can use markup to assemble a film from components, even without coding actionscript. My belief though, is that you´ll need actionscript there in the same way, you always needed javascript in the browser. But chances are good here, that at least Flex will become relevant because some of the (i think adobe calls them) 'content-producers' have a certain knowledge of actionscript from flash.
Using webservices to call into the server and do user-interaction completely in the 'design-space' might be the ultimate goal, but i doubt it might be reachable due to discussed reasons. The Problem with flex is, that concurrent work of coders and designers is (up to now) a little clumsy. Maybe this will get better soon.
JavaFX?
Let´s not get into that this year. in order not to beat it dead before really born. By now, it looks awful.
The obvious trade-off between reuse/encapsulation and flexibilty/development speed really boils down to where you ask yourself:
- Who is going to author/design/maintain the web-pages? Are they capable of understanding the details of at least the application?
- What is the smallest/most generic component they can understand, handle and reorganize, if any?
- What level of flexibility (from modified pageflow to scripting) is needed in their hands?
- Does the timeframe allow project specific knowledge to be transferred? (custom taglibs, custom managed-beans)
So how come, this article is called 'Infected by Wicket'?
Wicket is a component based approach, that is unique (from my perspective) in the way, that it draws a very clear line between the page-author´s and the 'backend'.
This line is quite low, so it page-author gets very little power over pageflow and custom functionality. It is "just another" MVC based approach, that moves any processing completely to the server-side (so that the redeploy-cycle here remains a problem).
The beauty of it is, that there is nothing else, but java and html. NO page-flow-definitions in xml (that no page-author touches anyway), no taglibs that render the page-author´s wysiwyg-tools useless.
On the java-side, it is POJO based, spring-integratable, very intuitive to use and just elegant. Take this as an example for simple a blog-like page:
public final class GuestBook extends WebPage
{
/** Use a Vector, as it is synchronized. */
private static final List commentList = new Vector();
private final ListView commentListView;
public GuestBook()
{
add(new CommentForm("commentForm"));
add(commentListView = new ListView("comments", commentList)
{
public void populateItem(final ListItem listItem)
{
final Comment comment = (Comment)listItem.getModelObject();
listItem.add(new Label("date", comment.date.toString()));
listItem.add(new MultiLineLabel("text", comment.text));
}
});
}
public final class CommentForm extends Form
{
private final Comment comment = new Comment();
public CommentForm(final String componentName)
{
super(componentName);
add(new TextArea("text", new PropertyModel(comment, "text")));
}
public final void onSubmit()
{
final Comment newComment = new Comment();
newComment.text = comment.text;
commentList.add(0, newComment);
commentListView.modelChanged();
comment.text = "";
}
}
}
class Comment implements Serializable
{
public String text;
public Date date = new Date();
}
<html>
<body>
<form wicket:id = "commentForm">
Add your comment here:
<p>
<textarea wicket:id = "text">This is a comment</textarea>
<p>
<input type = "submit" value = "Submit"/>
</form>
<p>
<span wicket:id = "comments">
<p>
<span wicket:id = "date">1/1/2004</span><br>
<span wicket:id = "text">Comment text goes here.</span>
</p>
</span>
</body>
</html>
Taking a look at the html, you´ll realize that this kind of templating not only doesn´t interfere with wysiwyg-tools, but also lets the page-author insert his own 'preview data' into it. Yes, as any other true MVC based framework, where the C is in the java-space, you take power (as well as duties) from the page-author, and face the problem of the redeployment-cycle.
Bottom line: Clean, simple, elegant, lightweight, servlet-based etc. I think, i´m infected with this one.
