Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.
You searched this site for "form". 326 entries found.

You can also try this same search on Google.

David Sachdev on Web Framework Proliferation

David Sachdev left the following comment in my post about the Java Web Framework Smackdown at TSSJS in Vegas:

The number of web frameworks out there is just astonishing, and in alot of ways I think that there is need for some consolidation in some way, shape or form. If you work in the Java world there is a sense of consolidation in the ORM space these days with JPA (the Java Persistence API). Sure if you are working strictly with JPA it is a bit more limiting then working directly with Hibernate, iBatis, or TopLink - but you no longer worry that you have made a critical misstep in your architecture by tying yourself do a particular ORM implementation. Similarly Spring gives you that similar "loosely coupled" feel that if Google's Guice because appealing to you, you don't feel like you've wasted all your framework foo on Spring. But web frameworks....that's another story.

I think if you had asked me a few months ago, I would have told you that the industry is promoting JSF (Java Server Faces). Everything from support in the IDEs to the availability of AJAX frameworks...and of course a flexible life cycle that allows for alternate implementations and various code to plug or be weaved in to the life cycle. And that while JSF on its own left quite a bit to be desired, the JBoss Seam project really has filled in the gaps in JSF, and in fact brought Java web development closer in agility to the Rails and Grails of the world that tout quickly built and deployed web applications.

But the thing that you continue to hear is that programming in JSF is painful. And you hear that EVERYONE used to use Struts. And that it is time to move past Struts. And given that, you have to consider Webwork and the merger of Struts2 into that framework - and their claims of rapid development. But you also have to consider Spring WebFlow and how that may help solve your JSF ills given that everyone is building off of the Spring Framework and they have been so good about keeping the framework updated and integrating the best of what is out there while innovating themselves. And then if you are looking at Spring WebFlow, you kinda have to go "Wait, but what about Spring MVC?"

Given its age, you might quickly dismiss Spring MVC until you realize that Grails is build upon it. Grails, that web platform that every java developer is either working with, or intends to work with soon. (Come on, you all have made the Ruby/Rails, Groovy/Grails, JRuby decision in favor of G2, right? I mean all the flexibility of what is out there in the Java world on top of the JVM, with a language that doesn't suck the life outta you....) And then you have to wonder that if you build upon Spring MVC as well as using Groovy and Grails where appropriate, might you be able to make that killer app in half the time.

But wait, you didn't think your choices were nearly that simple did you? There is this wonderful software company out in Mountain View that we need to pay attention too. In Google We Trust, right? And even if you don't worship at the Temple of the G (TOTG) like Sprout, you don't want to ignore them. And, if you've looked at the Google Web Toolkit (GWT) and weren't at least slightly impressed, I would be surprised. And if you are looking at the GWT, you can't totally ignore Yahoo's YUI - maybe with some of the what Prototype, Scriptaculous, or DoJo offer you. And then someone will come over and point out Echo2 to you, and well you have to admit, their demo looks nice. And well, there is Adobe Flex, and OpenLaszlo - I mean after all isn't Web 2.0 all about Rich Internet Applications. And surely you've heard that the performance of Swing is so much better these days and the "power of the modern Java applet"

So at the end of it all, you've got yourself alot of R&D to do, and just as you thing you've got a good grasp for the offerings out there, new and improved versions are out. And don't worry, someone else is also busy working on a new and greater web framework that you have to consider.

Wow - that's quite a mouthful David. Well written!

P.S. The Early Bird Deadline for TSSJS is today.

Posted in Java at Feb 22 2008, 02:47:44 PM MST 6 Comments

WebORB: Have you ever heard of it?

A colleague sent me an e-mail today and asked me if I'd ever heard of WebORB today. Since I hadn't, I figured I'd write this post and see if any of you have heard of it? If so, what is it and what does it do? It it similar to Appcelerator, but server-side only? Or is it more like Granite DS?

[Read More]

Posted in The Web at Feb 13 2008, 01:42:38 PM MST 12 Comments

Leasons learned from using Seam

Yesterday, I noticed the Seam Developers released a new seamframework.org site. It's great to see a web framework team eating their own dog food. Of course, if all open source framework developers were paid full-time to work on their respective project, we'd likely see more of this.

My favorite part of the new site is the Forums, which has an Atom Feed you can use to monitor topics posted. This morning, I noticed a topic from Daniel Hinojosa titled ANN: amazinggates.com is alive with Seam & lessons learned. In this topic, Daniel lists a number of lessons he learned from working with Seam.

We deployed our web site at amazinggates using JBoss Seam. I would lie if I said it was it easy, but the reason I had some issues is that I didn't believe a lot of documentation.

  • I had refused to use Facelets, instead I used JSP. All I can say to newbies is don't do it. You owe to yourself to drop JSP like a bad habit.
  • I had refused to use Seam Managed Persistence and ended with LIES.
  • I had refused to use Seam-Gen, and used my own folder structure. I still use my folder structure, but only after I used Seam-Gen and learned what I had to do to make my integration tests work.
  • I had used 2.0 when it was still in CR and Beta releases. Although that is neither my fault or the Seam's fault, the greatest result was that I learned tremendously what Seam had to offer, and I was able to provide JBoss with some bugs, and help users in the forum.
  • It took 8 hours to learn that Seam's AJAX4JSF solution was the best solution on the planet.
  • I used faces-config for page navigation. Ok, and that was just stupid.
  • I didn't know what components.xml was for the longest time. I'm really going to take part of the blame on this one. I read the documentation and even after reading it I still had no idea what components.xml was for. I realized that if the documentation said that components.xml maps components to names the way it does in Spring XML configuration. I wouldn't have spent that much time.
  • I had refused to use Renderer.render for email, because I didn't believe that the view should be the place for the rendering. So I was going to use a StringTemplate solution. That was dumb, it took a while for me to realize that generating emails in the view was the BEST place to do so.
  • Integration testing was a bitch. That wasn't my fault, or Seam's fault. It really was the Microcontainer's fault, and I hope that that ends up better in the long run. I heard through the grapevine that really no one is working on the EJB Microcontainer and it is still stuck in Alpha. Redhat needs to invest some people into it. It really is THAT important.

So, all in all, I love the new website, and I love what JBoss Seam has to offer. I am excited with what it has to offer, and I will still continue to build my business around it. Good work to the team that made JBoss Seam possible.

The one thing I noticed about Daniel's "Amazing Gates" site is it seems extremely fast. Do you think this is because of Seam or did he follow the rules for high performance websites?

Posted in Java at Feb 13 2008, 12:19:27 PM MST 3 Comments

The New Javalobby Sucks?

I didn't say it, Jesse Sightler did. Even though he didn't say "it sucks" explicitly, that's what I read in his post:

Is it just me, or has the new Javalobby proven to be a significant step backwards? The old site was a Slashdot style discussion system with a pace very appropriate to the pace of news flowing from the Java community. The light emphasis on announcements was welcome, and useful while at the same time not being overstated.

The new site feels a lot like TheServerSide.Com from a few years ago. They've gone to a system where the frontpage is updated frequently (many times per day) and the content there is seldom interesting enough to attract any significant discussion. Unfortunately, this means that the overwhelming number of articles on the frontpage appear dry and uninteresting. I don't think I've really read anything there since the switch to the new format.

For the sake of the site, I do hope they figure out their mistake here. There is no shame in turning this into worsethanfailurethedailywtf all over again (hopefully you get that reference).

I like the new site because I visit it more than the old one. Of course, that could be a direct result of me posting there. If I could change one thing, I'd like to see a java.blogs-style aggregator of all zones (then I'd turn off the .NET and Kids Code Zones).

Do you agree with Jesse? Should Javalobby change back to the old-way of using forums?

I believe the reason for the change was because DZone has become so much more popular than Javalobby. I think they're hoping to capitalize on that brand name and extend it to other communities. Look at the following graph from Alexa for proof. More traffic = more $$ from advertisers.

Posted in Java at Feb 12 2008, 11:26:50 AM MST 18 Comments

Building a Better Maven with Ant

It looks like the Ant folks are thinking of building a better Maven.

I see many developers adopt Maven because they want a build system able to provide common features with no effort. Most of them don't want to spend much time writing an Ant script, or have seen or heard that maintaining Ant build scripts is troublesome. So they choose to use Maven only because it's easy to use for common use cases: install, write a simple pom of a few lines or generate it using an archetype, and you're ready to compile, test and package your new project following the Maven standard structure. They also get dependency management for free, and with only a few more effort they have multi module builds, and some nice features like code analysis, coverage, and a set of report gathered in a web site. That's really nice and that's what I like about Maven.

But Maven suffers from a lack of flexibility and robustness IMHO. And later the same people who first adopted Maven because of its perceived ease of use become frustrated when they need to tweek the system to their own needs or don't understand how the release plugin work. Then some of them go back to Ant, first having to go through a sometimes painful road to describe their whole build system in xml, especially if they aren't Ant experts. Others try to use new build tools like raven, buildr or others.

I really like Ant, and think it is a very good basis for robust and flexible build systems. People with enough knowledge of Ant can write very good build systems, testable, maintainable and adaptable. But you need to get your hands dirty, and you need to get a good knowledge of some of the mechanisms which can make an Ant based build system manageable: import, scripts and scriptdef, macrodef, presetdef, and so on. [Read More]

What do you think - is this a good idea?

I agree that Maven has its warts, but I don't think it's that bad. I've also heard that Maven has been successfully implemented at large companyies like eBay, Intuit and E*Trade[1]. Is the "Maven sucks" meme largely something that exists in the blogosphere, but not in the real world?

I think the biggest benefit of Maven is dependency management. I think it makes your code more modular and easier to build. Rather than having a monolithic source-code tree that depends on itself being built in a certain order, you can have individual modules that pull dependencies from a central location. This can be done with Maven's Ant Tasks as well. I don't see a problem with building a better Maven with Ant, but to try and build a better Central Repository sounds like a nightmare to me. The current repository has been improved for years and is much better than it was a couple years ago. That being said, I would love to see somebody build a more accurate Central Repository. Ideally, it'd be done sometime next week. ;-)

[1] I could be wrong about these companies. If you're a developer at one of these companies, please confirm or deny. Any comments on Maven's success at these companies would be great as well.

Update: Speaking of Maven, there's an interesting comment on a Javalobby post I wrote:

With all the critical remarks the Maven project is receiving, wouldn't it be time for some Maven project lead to step up and explain the team's position? Or is it completely deaf to the sentiments? How many builds have to fail, how much more headaches are needed before others start their own version of Maven and do it the right way (like Don [Brown])?

Seems like an excellent question to me. Guys?

Posted in Java at Feb 11 2008, 02:07:12 PM MST 18 Comments

Maven 2 Archetypes get a much needed improvement

Yesterday, a new version of the Maven Archetype Plugin was released. This release incorporates many of the improvements that were developed in a different project - code named "Archetype NG". The two major improvements are 1) you only have to use "mvn archetype:create" now and 2) you can create archetypes from existing projects.

I haven't tried #2, but #1 seems to work pretty well (especially since AppFuse archetypes are the first 9 ;-)).

[Read More]

Posted in Java at Feb 09 2008, 03:20:00 PM MST 15 Comments

Ext JS Tag Library

James Carr in Making extJS More Accessible to Java Developers:

With my recent interest in extjs, I was playing with the idea of making a Struts2/WebWork component library or a tag library to handle a lot of the boilerplate extjs code (i.e. creating layouts and such) but, luckily, discovered someone beat me to the punch!

I randomly came across ExtTLD this morning while sifting through my rss feeds, and I must say I am rather impressed. Although I consider myself a pretty good javascript developer, there seems to be a lot of java developers who aren?t that hot at javascript... which is why whenever I attend any java related conference there is always several sessions touting "javascript free ajax!" frameworks like GWT, Ajax4JSF, or IceFaces. Although I've always been skeptical of such frameworks, I do see their benefits... especially for the java developer who excels at serverside JEE development but generally sucks when it comes to adding javascript behavior to the presentation layer.

I can definitely see how Ajax-with-IDE-code-completion would appeal to many developers. However, I do have to agree with James:

So far it looks good, but I haven't had a chance to play with it yet. Basically, I'll have to see if it passes my "good javascript generator framework" test. I?m a pretty staunch advocate of unobtrusive javascript, and generally hate any presentation layer framework that seeks to dump several hundred (or thousand) lines of javascript inline in the html document.

For development shops that have UI-only developers for the front-end and Java developers for the controller/validation part of an application, frameworks that generate JavaScript usually don't make sense.

ExtTLD's license:

ExtTLD is published under GPL 3.0 license however restricts use by companies participating in animal abuse, such as animal testing laboratories etc.

Posted in Java at Jan 22 2008, 10:01:27 AM MST 5 Comments

A Positive Wicket Experience

Julian Sinai recently released the first version of his company's product based on Wicket. In A Year of Wicket, he describes the experience (emphasis mine).

I've been working with Wicket for almost a year. We've just released our first product that uses Wicket for the user interface, and so it seems like a good time to take stock. Unfortunately, it's not a public site, it's an installable enterprise product, so I can't show it to you. If you don't want to read further, here's the executive summary: Wicket rocks!

I was hired as the GUI Architect for this project. I came to it with many years of GUI experience, mostly using Swing, but without a lot of web development experience.

Because of my Java and Swing background, I was drawn to Wicket. It maps fairly closely to the Swing model of development. So does GWT, but when I evaluated it, it seemed so different from other J2EE frameworks that I felt it was a step too far. No HTML, and no WAR files, for example. This made my colleagues nervous, who were used to Struts and PHP. Me too, as a matter of fact.

I had done some pretty serious prototyping for another project with Tapestry, and there were certain things I liked, like runtime bytecode generation. But the learning curve was pretty steep. At one point I needed to create a custom component, and to do so I needed to learn about engine services and other arcane things that I felt made the process too hard. By contrast, custom components are Wicket's bread and butter, and they are very easy to build.

I also took a close look at JSF. It seemed overly complex to me, and not much of a departure from the Struts era. It came across as a technology designed by committee, with the combination of several complementary libraries required to get the job done, and there are still too many configuration files.

So we decided to use Wicket.

...

One of Wicket's advantages is the strict separation of design from behavior, that is, HTML from code. While we did not have a web designer on the team who built the HTML (the developers did this), and therefore didn't get any mileage from the separation in that sense, we definitely gained from having all the behavior in Java code, because it gave us all the power of refactoring, compile-time error checking, and maximum reusability. [Read More]

I really like how Julian talks about reasons they didn't choose other frameworks. Beyond that, I think it's important to note that Wicket was a perfect fit for someone with heavy Java and Swing experience. I still think Wicket is a little verbose for Web developers that program in Java (me), but it's unlikely there's very many of those. Building a form in Java seems so much more cumbersome than building it with HTML - but that's probably just me.

Posted in Java at Jan 18 2008, 12:37:18 PM MST 7 Comments

FreeMarker vs. JSP 2

I've been doing quite a bit of prototyping with Spring MVC and Struts 2 with both JSP and FreeMarker in the last few months. I'm trying to migrate a proprietary servlet-based framework with a proprietary JSP compiler to something that's open source. There's a couple of important features that the proprietary view framework has:

  1. It's expression language allows methods to be called with arguments.
  2. Templates can be loaded from a JAR on a remote server.
  3. XML in variables is escaped by default.

For #1, I've found this to be impossible with JSP EL or JSTL. I've created JSP functions that allow argument passing, but they don't allow overloading of functions. FreeMarker solves #1.

For #2, JSPs again fail because the templates have to be on the file system or in a WAR. FreeMarker solves this problem as well.

For #3, neither JSP or FreeMarker solve this problem. I realize it can be fixed in FreeMarker by hacking the code - I've done the same with Tomcat and solved it for JSP as well.

So based on the requirements in this project, FreeMarker is the clear winner. Here's some problems that I see with using it:

  • No XML escaping of expressions by default
  • No compile-time checking of expressions
  • IDE support is limited to Eclipse (meaning very little in the way of code-completion)

FreeMarker users - are there other problems you've experienced when using FreeMarker in your applications?

Posted in Java at Jan 17 2008, 12:37:12 PM MST 12 Comments

Java Web Framework Smackdown at TSSJS in Vegas

This year's TSSJS is starting to look like an excellent conference. I'm particularly excited to be moderating the following Expert Panel.

Java Web Framework Smackdown: Struts 2, Spring MVC, Grails, Seam/JSF and Wicket
The leading advocates of today's popular Web frameworks will duel under the Vegas Lights. Come and learn when to use your favorite framework and to see if it can live up to its hype.

We're talking about productivity, scalability and maintainability of Java-based Web applications. The emerging trend is that simplicity is better and productivity matters. Furthermore, if maintainability is the most costly part of any application -- how do these frameworks perform?

Attend if you're a Java Web developer, or if you simply like good entertainment. A working knowledge of the popular Java Web framework options will make this session more fun. If you haven't worked with any framework, come and learn who has the best spokesman.

The Venetian I plan on bringing the boxing bell from OSCON 2005 to make this session one of the best in the show. I'll be coming up with a list of questions for these experts in the next couple of months. In the meantime, if you have any suggestions, please let me know.

With a venue like The Venetian, why wouldn't you go? ;-)

Posted in Java at Jan 11 2008, 12:06:24 PM MST 19 Comments