techno.blog("Dion")

Wow, Struts is a huge project:

Today, Struts is comprised of nine subprojects: Core, Taglib, Tiles, El, Faces, Scripting, Applications, Shale, and (now) Flow.

The Struts team just announced Struts Flow which brings a continuations based approach to web flows.

This is interesting stuff, and we have seen continuations popup in other communities such as Ruby, Perl, and Smalltalk.

Seaside was the first web framework that I saw with continuations, and it intrigued me from the beginning. It really does make sense to have the users ’session’ to be the core. In fact, on our projects, we put a lot of functionality there (even if it just ties into the business layers etc).

It will be interesting to see how Struts Flow gets adopted.

Take a look at an example of putting the logic in one workflow, even though web pages are being sent around to get input from the user:

function main() {

var random =  Math.round( Math.random() * 9 ) + 1;
var hint = "No hint for you!"
var guesses = 0;

while (true) {

// send guess page to user and wait for response
forwardAndWait("failure",
{ "random"  : random,
"hint"    : hint,
"guesses" : guesses} );

// process user's guess
var guess = parseInt( getRequestParams().guess );
guesses++;
if (guess) {
if (guess > random) {
hint = "Nope, lower!"
}
else if (guess < random) {
hint = "Nope, higher!"
}
else {
// correct guess
break;
}
}
}

// send success page to user
forwardAndWait("success",
{"random"  : random,
"guess"   : guess,
"guesses" : guesses} );
}

View the Announcement

The Apache Struts team is pleased to announce the adoption of its latest subproject, Struts Flow, a continuations-based approach to complex web workflows. Struts Flow originated at the struts.sf.net project and has been formally adopted now as a Struts subproject. Struts Flow is a port of Apache Cocoon's Control Flow to Struts to allow complex workflow, like multi-form wizards, to be easily implemented using continuations-capable Javascript and eventually Java.

Today, Struts is comprised of nine subprojects: Core, Taglib, Tiles, El, Faces, Scripting, Applications, Shale, and (now) Flow. Struts Flow is different from Struts Scripting/BSF as where Scripting brings any BSF-supported scripting language to Struts Actions, Struts Flow works on redefining the traditional Model 2 state-driven workflow into simplified scripts whose execution spans multiple requests. Currently, the Rhino engine, a Javascript implementation, is used to provide continuations support, but with the maturation of Jakarta Commons Javaflow - http://jakarta.apache.org/commons/sandbox/javaflow - a Java-based continuations implementation, Java will soon be supported as well.

For more information, visit the Struts Flow website at:
- http://struts.apache.org/flow

David Hannson, of Rails fame, writes a case against high-level components.

Although we have definitely seen components NOT be successful in areas such as EJB (yeah, we can buy SO many vertical components), the web tier (apart from the displaytag ;), I don’t think we should write off components in general.

There are many places where components make sense. They make sense in GUI development. Tapestry components work out great. In my experience, it depends on the contract and what you are trying to do. There are some items which you really don’t need to tweak much, and if you do, it is there for you. However, it is hard to have ONE reusable component for “new WebCommunity().start()”.

It is an art to choose what should be generized, what shouldn’t, and how to give enough hooks to allow you to tweak the component.

David Hannson, of Rails fame, writes a case against high-level components.

Although we have definitely seen components NOT be successful in areas such as EJB (yeah, we can buy SO many vertical components), the web tier (apart from the displaytag ;), I don’t think we should write off components in general.

There are many places where components make sense. They make sense in GUI development. Tapestry components work out great. In my experience, it depends on the contract and what you are trying to do. There are some items which you really don’t need to tweak much, and if you do, it is there for you. However, it is hard to have ONE reusable component for “new WebCommunity().start()”.

It is an art to choose what should be generized, what shouldn’t, and how to give enough hooks to allow you to tweak the component.

Cedric has written about his first experience with PHP.

Cedric is not a tech snob (or is he with Unit testing? jk :). Practically speaking PHP has a ton of support, and if you look at the numbers, it looks to be DWARFING the number of web sites written in either Java or .NET or …

I also think that when you look at systems such as pMachine, you can’t help but think it is compelling. The thing has plugins for everything!

Do you love the language? Do you hate bloody global (upvar upvar upvar)? Who cares… it is practical :) Of course, it depends on what kind of web site you are developing.

Brian McCallister has started on a path of comparing Rails in a way that Strut’ters would get.

He is spot on that people have made a connection between:

Rails is easy. Look at the short demo video

and:

Rails is easy, which means it must no be flexible, or scalable, or …

However, I think Rails manages to be all of these things. The hooks are there for you to get your fingers dirty, while staying in the rails world. There are also many apps which are running with high load, and no scalability problems.

I am really looking forward to talking to Mr. Trails at TSSS, to see what his experience has been shoehorning a Ruby view on a Java platform.

Brian McCallister has started on a path of comparing Rails in a way that Strut’ters would get.

He is spot on that people have made a connection between:

Rails is easy. Look at the short demo video

and:

Rails is easy, which means it must no be flexible, or scalable, or …

However, I think Rails manages to be all of these things. The hooks are there for you to get your fingers dirty, while staying in the rails world. There are also many apps which are running with high load, and no scalability problems.

I am really looking forward to talking to Mr. Trails at TSSS, to see what his experience has been shoehorning a Ruby view on a Java platform.

I was a big fan of the Rails video which showed how simple it is to get up and running with the technology.

Now there is an 11 minute Trails video, which walks through a ‘Recipe’ sample application:

Well, I got the video done. I created the Recipe application from the onLamp.com article in 10:53 seconds, and that

Rick Hightower has released the first of a series of article on JSF, named JSF for nonbelievers: Clearing the FUD about JSF, which was jumped on heavily with discussion at TheServerSide.

I think that there is some FUD surrounding JSF. I think there was a lot of HYPE surrounding it at first. I am a little schizophrenic about the entire technology. Some days I think it is good to have the standard, other days I curse at the unnecessary complexity.

Howard has written a really thought out entry himself: Tapestry, JSF and FUD.

I think he is spot on with many of his observations. I also wish that in a fantasy land, Tapestry 4.0 would be here which would consist of: Tapestry 3.1 + other items learned from JSF + other items learned from Rails + annotations. Oh, and the vendors would support it with lots of cool plugins and hype ;)

Or something.

TheServerSide communities are now running on Tapestry on the front end, and Kodo JDO for the data access.

We had known for awhile that it was ready for a change, and it was an interesting experience choosing what we wanted to port TSS over too.

There are many great web frameworks, and data solutions, but we definitely ended up happy with what we got.

The port was done in record time, in no part thanks to having Howard Lewis Ship on the team. If you are ever doing a Tapestry project, you owe it to yourself to bring him in for a bit. Not only does he obviously know Tapestry inside and out, but he is just a top class developer which great ideas!

Looking at the before and after version of TheServerSide is very interesting. Now TSS has a great, component-based version which is easy to extend. Before, it was always a fight to change / add anything.

It also doesn’t hurt that the site is faster and more stable than ever before. Kodo JDO has been top notch on that scale, and it has the solid Tangosol Coherence under the scenes as the distributed cluster technology.

Read more: How TSS Converted to Tapestry

Rolling with Ruby on Rails is a new tutorial that goes through building a sample application from start (installing all software [rails, db, etc]) to finish (a running application).

Rails is really getting a lot of attention, and could be the tipping point for Ruby itself this year.

Parting Thoughts

Ruby on Rails has taken web application development to a whole new level. You no longer need to do the parts that used to be tedious work, because Rails does them for you. Even if you have to use a legacy database that does not use the Rails naming conventions, you don’t have to give up the productivity advantages of using Rails–there is still a way to tell Rails explicitly what table and column names to use.

Now that you’ve seen firsthand how easy it can be to create a web application, why would you want to do it any other way?

Perhaps your employer has mandated a particular framework or language. You can still take a few days to prototype it in Rails, then go to your boss and say, “I’ve already finished writing our entire application in Ruby on Rails! If you prefer, we can still take the next few months to write it as we originally planned.”