Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

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.

RE: WebWork joins Struts

From the struts-dev mailing list:

Between the Clarity hubbub and the Java Web Alignment brouhaha, it came up that WebWork would like to merge with another framework. Ted and Don followed up with the two core WebWork developers, Patrick Lightbody and Jason Carreira. As it turns out, they are very interested in merging WebWork with Struts. An archive of our discussions is available as a Quick Topic thread.

As some of you know, the underlying idea behind Ti was to use WebWork as the core of Struts Action Framework 2.x. Conceptually, WebWork and Struts 1.x are very similar. We've often said, without embarrassment, that WebWork does many things better than Struts 1.x. Meanwhile, WebWork has the ability to provide a layer of almost full backwards-compatibility for Struts 1.x, and we have already demonstrated we can integrate Beehive's (very cool) Page Flow with WebWork.

Patrick Lightbody:

Yes, it's true. The WebWork development team (Jason and I) have been working with the Struts development team (Don Brown and Ted Husted) and have come to the conclusion that the best thing for Java community would be to merge WebWork in to Struts.

Read Ted's email here, but the gist of it is this: WebWork is a great technology, and Struts is a great community. It's a perfect match and bringing the two together will only be better for WebWork and Struts users alike. The only down side for me is that I'll be working less with OpenSymphony, but I believe that is a small price for all the great benefits that come from this merger.
...
With this renewed energy, larger development team, and larger community, the combined efforts of Struts and WebWork will surely make the Struts platform the easiest, fastest, and most powerful Java web framework available. We hope that all the WebWork users and developers are as excited about this as we are and are ready to take WebWork to the next level.

IMO, this is good for both Struts and WebWork. WebWork gets the additional marketing it needs, and Struts users get a kick-ass framework to develop with. If you're a Struts user and haven't tried WebWork, prepare to be impressed. I was and still am.

I plan to upgrade AppFuse and Equinox to WebWork 2.2 as soon as its released. Hopefully I'll be able to migrate both the Struts and WebWork versions to SAF 2.0 w/in a few months.

Posted in Java at Nov 27 2005, 04:18:55 PM MST 4 Comments
Comments:

[Trackback]

?Struts??????????????[PROPOSAL] Merger with WebWork, WebWork???Struts Ti?Action?????

Struts Ti b...

Posted by mornlee's blog on November 27, 2005 at 08:54 PM MST #

[Trackback] You can read it everywhere, even on TheServerSide: WebWork merging with Struts IMO this move was overdue. Struts technology side could be highly enhanced by WebWorks technology and WebWork is almost useless with the current momentum and userbase. So th...

Posted by Karsten Voges (Weblog) on November 28, 2005 at 06:36 AM MST #

Hi Matt, </br></br> What does it mean to Struts+WebWork Vs. JSF ?? Do you think, the later will be sidetracked with the former??</br></br> any comments!!</br></br> pats

Posted by pats on December 05, 2005 at 09:39 AM MST #

Pats - there are basically two types of web frameworks in Java: request-based and component-based. The two don't compete a whole lot b/c development teams often decide one way vs. the other. I've used both request-based and component based - but mostly on smallish projects. I've heard component-based is a better solution on larger projects - but there's also <em>many</em> more success stories of request-based on smaller projects.

One of the nicest things about WebWork is it's very similar to a component-based framework, but implemented as a request-based framework. You can do page-backing beans (like JSF and Tapestry have) with the <ww:action> tag.

Posted by Matt Raible on December 29, 2005 at 06:44 PM MST #

Post a Comment:
  • HTML Syntax: Allowed