Summary
Recent years have seen the proliferation of Web frameworks that aim to simplify the development of complex Web applications. One such framework, Wicket, promises to rely less on external configuration files and more on Java code to speed up Web application development. A recent article introduces Wicket and compares it to other Java Web frameworks.
Advertisement
One conclusion to draw from the recent profileration of Web frameworks is that frameworks are as much about taste as they are about productivity. And, further, that taste and productivity relate: A framework that caters to a developer's taste will likely make that developer more productive, while perhaps hindering the work of another developer who does not respond well to the framework's development style.
One Web framework style tends to favor external configuration over explicit Java code. Struts, for instance, relies on one or more XML configuration files to specify the flow of a Web application. While that style works well for some developers, XML files irritate just as many, who prefer to specify Web application logic in Java code instead.
According to a recent introductory article by Guillermo Castro about the Wicket framework:
[In Wicket] all the application logic falls inside the Java classes, instead of mixing it with the pages, like JSP (true separation of concerns). The Java code is glued to the HTML page by using a special wicket:id attribute that can be assigned to almost any HTML tag, and that tells Wicket where do you want to render a component. Wicket comes with several components like Labels, Links, Lists, etc., which are uniquely defined on a webpage by setting an Id to the component, and the content which is represented by a Model.
If you're using Wicket, there's only one XML you really need to modify, web.xml, and this isn't even a Wicket requirement, but rather a servlet specification requirement (i.e. you can't make a servlet work if you don't define it in the xml).
Do you prefer external files, such as XML, over explicit configuration via Java code? What framework caters to your taste, and why?
If you use external configuration files, you can modify the configuration without recompiling the application. I haven't used Java in a while, and am not really familiar with JSP and web-based Java programming, but you also see this pattern in .NET. Wednesday, I was at the DevDays in Brussels, and the closing keynote was given by Rafal Lukawiecki of Project Botticelli, who said that the future of application development lies in parameterization instead of customization.
> If you use external configuration files, you can modify > the configuration without recompiling the application.
Thats fine for the things the deployer is likely to modify. The deployer is not likely to modify application logic, and XML is a bad way to specify it. Otherwise, we would use XML-based configuration files to assemble components in desktop Swing application -- and we don't.
The problem is that tag-markup files are not object-oriented, so it is extremely difficult to reuse any logic you put in them. JSP, JSF, Struts and ASP-based solutions cannot avoid embedding presentation logic within tag files, whether via scriptlets, custom tags or standard tag libraries. Then you're stuck trying to figure out how to generalize and assemble your mark-up files. Struts tries to gain a bit of reusability by inserty XML configuration within every interface, but the approach is clumsy and weak. Struts and JSF build upon JSP technology, which in my opinion, is a bad foundation. ASP.NET suffers from the same problem, and practially speaking, requires a high-powered IDE for building even the smallest applications.
An object-oriented programming language already has wonderful tools for abstraction and re-use of program fragments, so the solution is to take the presentation logic out of the mark-up file and put it back in programming language code where it belongs. The only question is how to do this, when the client browser understands only HTML and Javascript.
This is the problem that Wicket solves. Though Wicket allows you to use snippets of HTML to describe the rendering and placement of components, with Wicket the HTML needs not a single loop or conditional. Because components are connected via Java code, you have better opportunities for component re-use than XML configuration files could ever give you.
A Wicket programmer might use configuration files for the same purposes that a desktop Swing application programmer might use them. But for building and assembling general-purpose components, XML configuration files are just not the right tool.
> If you use external configuration files, you can modify > the configuration without recompiling the application.
Leading to programmers doing ad hoc fixes on production servers etc. Yeah, I've seen that. A very sure way to end up in a mess. If you automate you build and deployment process, it won't matter whether you need to adjust Java code or xml or whatever.
> Wednesday, I was at the DevDays in > Brussels, and the closing keynote was given by Rafal > Lukawiecki of Project Botticelli, who said that > the future of application development lies in > parameterization instead of customization.
Let's see about that in the future then :) It reminds me of my university teachers who warned me not to persue a programming career, but instead focus on analysis. 'In a few years none will need higher educated programmers anymore as it will be something almost everyone can do' (refering to 4GL). Of course, the oposite is true, and if there is one thing we can learn from the past is that 3GL languages are very suitable for a wide range of solutions. Including web applications if you ask me.
Furthermore, concerning parameterization... Someone needs to build the slots for those parameters, right? Is that 4GL again? Whatever it is, I'm sure it conflicts with the principle of YAGNI. Though otoh you may say that of any framework that exists ;)
Previous Topic
