Discussions

The Apache Struts team has announced the new sub-project of Struts named Shale. Shale is a JavaServer Faces based framework that will likely become Struts 2.0. Struts Classic has not died, and it will be interesting to see how much care it gets.

Please help clear this up for me. Is JSF an actual library/package or just a specification which Shale plans on implementing?Or, alternatively - should I read up on general JSF stuff before I go and start checking out Shale?

JSF's primary concern is in user interface components and doesn't provide much for controller features. This is where frameworks like Struts (Shale) steps in. Shale will be able to concentrate on controller behavior, leaving presentation concerns up to JSF implementations (Sun's JSF-RI and Apache MyFaces-- take your pick).

Nope it is a user interface framework that can work in conjunction with JSP.

JSF's primary concern is in user interface components and doesn't provide much for controller features. This is where frameworks like Struts (Shale) steps in. Shale will be able to concentrate on controller behavior, leaving presentation concerns up to JSF implementations (Sun's JSF-RI and Apache MyFaces-- take your pick).Jacob (JSR 252 EG)

What? JSF provides a event handling mechanism that is both more sophisticated and more user friendly than the primitive "controller logic" that we have seen in systems like Struts.By all means, something like JSF should have replaced Struts for good. It is only the slowness of the JCP that has left us with inferior tools compared to the .NET camp. Oh well, there is always Tapestry :-)

Nope it is a user interface framework that can work in conjunction with JSP.

Of course, I never said it only works with JSP-- just trying to answer Joe's question within the realm of his understanding of Struts as a web framework.

If you were to parallel technologies such as Swing, AWT, or SWT to JSF, they all provide similar intentions or functionality (events, rendering, etc). From a controller standpoint, Struts provides a stronger feature-set in managing workflows and exception handling (features that current Struts developers are used to, which although JSF can handle, it doesn't intrinsically emphasize).

Please help clear this up for me. Is JSF an actual library/package or just a specification which Shale plans on implementing?

JavaServer Faces is a specification, just like Servlet, JSP, JSTL, and so on. There can be several implementations -- two that are widely referred to are the Reference Implementation (RI) from Sun, which was delivered along with the original spec (and is available, including source, at java.net), and MyFaces, an open source implementation in Apache's incubator that is striving to create a compatible implementation (but they haven't completed that task yet).

Shale does not intend to implement JSF -- it intends to provide value added framework capabilities around an existing JSF implementation (and it works with either the RI or MyFaces, for example). This makes sense when you understand that JSF is focused on the view tier, while Shale (as is also the case with Struts 1.x) is more concerned about the controller tier. JSF's APIs provide numerous extension points designed to allow this kind of add-on, and Shale is leveraging them.

Or, alternatively - should I read up on general JSF stuff before I go and start checking out Shale?

So in order to use on framework (JSF) we need another one (Shale)? Why it could not be a part of JSF? or MyFaces? Marina

IMHO, that's the beauty of JSF. JSF works with plain Java Objects-- so you don't have to extend Actions or ActionForms. This means that other frameworks such as WebWork, Struts, etc can integrate with JSF's presentation capabilities.

This *also* means that you can roll your own controller capabilities that are specific to your application without concerning yourself with things such as navigation handling, state managemennt, validation, and conversions as JSF already includes those capabilities.

Ideally, JSF is capable enough that you don't need a full framework to implement your application's concerns. For those development groups who are looking for a pre-packaged, standard controller framework with all the bells and whistles, Shale will probably be the tool of choice.

I guess not one of the 3 posts above read what the announcement said. Struts added a project, that's all. It be like saying... there is now a new tag lib.

Struts(classic) 1.3 is majority a new re-write based on CoR, another simple but powerfull technology(again, developer by Carig M.). It should allow Struts to catch up to some advantages of competing frameworks. There was some debate about who should host Shale, MyFaces or Struts; but it realy does not matter. Struts development is fine, I think at the fastest pace ever. You can look at Dice and see help wanted % of Struts vs XYZ. When ever another framework ships, they say: We are better than Struts. So ... one could argue Struts is the standard. But you don't have to use #1, you should use what you think is best.When one 1.3 ships, you can decide if you like Struts, or alternatives.

I still don't understand why Apache did a name change? It seems to be that they want Shale to be totally different from Struts (even though from reading artcles they don't want to admit it). It's almost similar to these stores we have in Brooklyn: one day they open as "Habib's Market" and next month it's "Mula's Market" and then...you get the idea. When someone changes the name they want to be totally different from the previous.But back to Struts, don't we have here a birth of a similar formula: Struts + JSF = TapestryJust a thought....

No name change. They are 2 diferent things:Struts everyone knows, use w/ JSTL, Velocity, XSLT, etc; like before. Now it has a CoR.Or ...Shale, you can use w/JSF, DHTML XML-RPC and some of the above.WebWorks, you can use w/....You get the idea. What may be confusing people is that Sturts (a top level ASF project) you can download 2 different MVC frameworks.Why not? May the best one win more market share and produciton popularity.

It seems to be that they want Shale to be totally different from Struts

Yup, 2 diferent things w/ 2 diferent code base.

Sort of like why don't the call an Airplane a Car. They both travel, but they are diferent and have 2 names.

I already asked this in the different thread, and was not answered, so I will ask again: why Craig thinks that input->controller->model->view->output sequence is less developer-friendly than a "single Java class, implicitly associated in a 1:1 relationship", combining the "tightly coupled processing actions"? Am I mistaken, or this will impose using of one solid module for both input and output? So, if I need to change only input or only output, I would have to create a new module? Is this good for code reuse? Current Struts approach, where "the setup logic and processing logic end up in two different Actions" (which, by the way, is not advertised as a standard practice on Apache web-site) is far more flexible and allows to separate input from the output and to create truly stateless views.

The only fact that MS went Page Controller route does not mean this is the proper way to do things. MS is adding built-in Front Controller pattern to asp.net 2.0, this is the feature that Struts has from the beginning. Yes, Struts is tightly related to http classes, and its testing maybe not as easy as it could be, but let us not throw out the baby with the water. The basic concept of Struts of having the Controller to accept input, and the possibility to respond with different Views, is its best asset.

MS had to convert VB programmers which are used to drop the control on the form and to link the onChange event with some business code. This is great for prototyping, but after 20-30 windows this becomes an unmanageable mess. Luckily, Java community does not have VB legacy.

I already asked this in the different thread, and was not answered, so I will ask again: why Craig thinks that input->controller->model->view->output sequence is less developer-friendly than a "single Java class, implicitly associated in a 1:1 relationship", combining the "tightly coupled processing actions"? Am I mistaken, or this will impose using of one solid module for both input and output? So, if I need to change only input or only output, I would have to create a new module? Is this good for code reuse? Current Struts approach, where "the setup logic and processing logic end up in two different Actions" (which, by the way, is not advertised as a standard practice on Apache web-site) is far more flexible and allows to separate input from the output and to create truly stateless views.

Four years of following the Struts user mailing list (many MANY thousands of postings) indicates that the complexity of getting all of these moving parts coordinated is the single hardest part of learning how to build a Struts based application. Like any good open source developer, I'm listening to where the users of my framework have pain, and I'm going to do things to make life better.

Concepts like a "stateless view" only matter to someone who understands what you are talking about. Most of the world doesn't have a clue -- but their needs are just as legitimate as the needs of people who like O-O and code reuse and all of that sort of stuff.

Note that you are not going to hear any bashing from me about frameworks that cater to professional software developers who understand deep design patterns. If that is your gig, stick with Struts 1.x or WebWorks or whatever. But there are orders of magnitude more people in the world that don't get it, and ignoring them is not what I am interested in.

The only fact that MS went Page Controller route does not mean this is the proper way to do things. MS is adding built-in Front Controller pattern to asp.net 2.0, this is the feature that Struts has from the beginning. Yes, Struts is tightly related to http classes, and its testing maybe not as easy as it could be, but let us not throw out the baby with the water. The basic concept of Struts of having the Controller to accept input, and the possibility to respond with different Views, is its best asset.MS had to convert VB programmers which are used to drop the control on the form and to link the onChange event with some business code. This is great for prototyping, but after 20-30 windows this becomes an unmanageable mess. Luckily, Java community does not have VB legacy.

While it is indeed possible for Struts apps to generate different views from the same input, that is NOT what 99% of the world actually does with it -- they generate apps that have static paths through the control flow, and are therefore tempted to bend the basic Struts architecture by chaining Actions. Shale makes that sort of application SUBSTANTIALLY easier to build. All the logic associated with pulling data from the model is in the same class as the logic to push the results back to the model (which is particularly useful in the not-uncommon case where you keep refining the same view over and over again). However, the physical representation of that view (what HTML gets generated, etc.) is still separated from the event handlers needed to interact with the model tier.

Note also that Shale does not forsake the "every request flows through the controller" model -- that's handled by a Filter that lets you customize the overall architecture to your heart's content. Indeed, I was able to add support for the server side of applications that need remoting support (such as clients that use XmlHttpRequest) without impacting the flow for server side trips that invoke user interface actions. You're free to do the same sorts of decoupling of input processing and producing the subsequent response that you can do with classic Struts, if that is what you want.

Finally, even if your "unmanageable mess" assertion were true (something I am not prepared to stipulate), the very large majority of the applications that have ever been built with Struts are smaller than that, so it would be pretty much irrelevant to most Struts users.

Craig

PS: It is a fallacy to assume that there is a "proper way to do things" that is universally applicable. Different strokes for different folks -- or, more prosaically, different technologies for different requirements.

PS: It is a fallacy to assume that there is a "proper way to do things" that is universally applicable. Different strokes for different folks -- or, more prosaically, different technologies for different requirements.

Or, the quote I have above my monitor, "Philosophical purity leads to pragmatism"

Struts was the best approach to web design when it came out, others (just like in web design) have since built off those ideas and figured out what works and what doesn't for them. WebWork does a better job handling logic/flows at the server side and Tapestry has a great interface component model. Each framework, as far as I know, is an all in one solution that developers 'lock' their whole web application into.

As a reflection of programming practices, I'm sure you will start to see more projects that only concern themselves with a small subset of responsibilities (SRP). JSF is one of those projects as it works to standardize itself within one responsibility. Other frameworks, like Shale, could only concern themselves with the responsibilities of a controller.

In addition, this seperation allows developers of varying degrees of knowledge to concentrate on specific parts of the application, using the best tools possible. For JSF, it might be any vendor suite (IBM, BEA) or Sun's Creator to quickly build UI's. While the more advanced programmer can sit in their favorite IDE and hack out their own, best of breed controller or go with something like Shale. Lastly, progressive web standards allows a web designer to use CSS to decorate standard component models produced by JSF vendors.

I do agree that developers have learned a lot about what works and what doesn't since Struts first hit us. In no way should we argue against any framework and just feel lucky that as Java programmers, we have lots of choice.

It is a fallacy to assume that there is a "proper way to do things" that is universally applicable. Different strokes for different folks -- or, more prosaically, different technologies for different requirements.

In no way should we argue against any framework and just feel lucky that as Java programmers, we have lots of choice.

Well, I would agree with "choice is good" thing. But seems that I prefer to use hammer for everything ;)

MSDN on Page Controller: "The key constraint of Page Controller is that you create one controller for each Web page. This works well for applications with a static set of pages and a simple navigation path. Some more complex applications require dynamic configuration of pages and navigation maps between them."

MSDN on Front Controller: "The Page Controller solution describes a single object per logical page. This solution breaks down when you need to control or coordinate processing across multiple pages. ... Because Page Controller is implemented with a single object per logical page, it is difficult to consistently apply a particular action across all the pages in a Web application. ... The association of the URL to the particular controller object can be constraining for Web applications."

Basically, Front Controller allows to do everything Page Controller does, and more. Yes, with added complexity. I like unversal solutions, but maybe it is just me.

Concepts like a "stateless view" only matter to someone who understands what you are talking about. Most of the world doesn't have a clue...

It's true, we Struts hackers haven't got a clue about stateless view. I mean I have a page, AddUser.do, if the user hits refresh afterwards, then IE shows a retry/cancel dialog before form resubmission. If the user agrees to it, then my Struts action throws an SQL exception. Can JSF's stateless view make browser refreshing safe by inherently avoiding duplicate form submission?

It's true, we Struts hackers haven't got a clue about stateless view. I mean I have a page, AddUser.do, if the user hits refresh afterwards, then IE shows a retry/cancel dialog before form resubmission. If the user agrees to it, then my Struts action throws an SQL exception. Can JSF's stateless view make browser refreshing safe by inherently avoiding duplicate form submission?

Using JSF's robust navigation capabilities, you can provide a redirect after post (there were 2 articles on theserverside.com on the topic). I know that JSF and Shale will probably come up with solution on inheritently protecting actions from double posts (as Struts had with tokens).

Using JSF's robust navigation capabilities, you can provide a redirect after post (there were 2 articles on theserverside.com on the topic). I know that JSF and Shale will probably come up with solution on inheritently protecting actions from double posts (as Struts had with tokens).

As for stateless view being a best practice, redirects seem easily configured in both Struts and JSF. But at the cost of worst possible latency and throughput. Maybe there's a better, more WAN friendly way of making the view stateless? Or is redirection essential, for more than just updating the browser's address bar?

Speaking of updating the address bar, I'd prefer not to do it during the pages of a token transaction, since browser bookmarking into the middle of a transaction's page sequence would be silly. During navigation along the page sequence of a transaction, it might be nice if there were no redirection and the address bar never changed. Hopefully JSF can round-trip a CGI form without altering the address bar?

A browser should seldom be given a page who's URL won't work if bookmarked or emailed. Redirected stateless view is a big step toward reusable URLs. But I think not redirecting during a transaction is also needed to have all reusable URLs. So maybe redirection isn't the best way to make a stateless view?

As for stateless view being a best practice, redirects seem easily configured in both Struts and JSF. But at the cost of worst possible latency and throughput.

Assembly language program is faster than Java. So what? This fraction of second that you care about will save you on page refresh and will provide robust and pleasant user experience. Isn't the whole thing about a user after all?

Maybe there's a better, more WAN friendly way of making the view stateless? Or is redirection essential, for more than just updating the browser's address bar?

Address bar is just the icing in the solution of a bigger problem.

Speaking of updating the address bar, I'd prefer not to do it during the pages of a token transaction, since browser bookmarking into the middle of a transaction's page sequence would be silly.

Why? You have views which show an object or part of an object using object ID. If you bookmark the URL, you will remember the "show product with ID..." view. If later a user would navigate to this URL, then if product is available it will be shown, if product was discarded during initial entry or removed, the user will see a "Product not found" error. Absolutely legit for me. Can you provide an example which does not work with this approach?

During navigation along the page sequence of a transaction, it might be nice if there were no redirection and the address bar never changed. Hopefully JSF can round-trip a CGI form without altering the address bar?

Browser simply displays the address of a resource received in response. What are you talking about is showing result without redirect. You already have that ;) The point is, that if you want to refresh the result, you need to tell server where to get it from. The only address that is available is the one in the address bar, which is logically is not the address of the resource you want to see, it is the address of the module processing the input! Here comes the POSTDATA dialog.

A browser should seldom be given a page who's URL won't work if bookmarked or emailed. Redirected stateless view is a big step toward reusable URLs.

Right.

But I think not redirecting during a transaction is also needed to have all reusable URLs.

Did not get that.

So maybe redirection isn't the best way to make a stateless view?

If we are talking about a pure and simple view, which only displays the information, then redirection is the only way. Without it you send your input data again to the server and you process it again, and you fight with double submits, and you use some weird things like tokens. This is not a view, this is the whole input/processing/output sequence done again. And do not forget users cursing you for clicking "OK" on POSTDATA dialog each time they navigate back and forth. Here is your latency and loss of throughput and loss of credibility. Redirection: lose a little, gain more ;)

Today's most popular post on JavaBlogs is Dion's "XmlHttpRequest and company enable componentization". He suggests an alternative way of compositional page tiling by using DHTML for client side dynamic inclusion.

He describes its appeal: "Now, with XHR, each component can talk back to the server if it needs too, and the rest of the page stays put."

Is JSF ready for these HTTP requests that don't update the browser address bar?

I'm glad Dion saw the relevance to portals. It's unclear to me why the Java Portlet Specification chose server side inclusion instead of HTML frames? Is XmlHttpRequest the best portlet mechanism? Can JSF or Struts work with client side inclusion (XmlHttpRequest or frames)? I see that XmlHttpRequest is supported by IE, Mozilla, and Safari. That's universal reach. But XmlHttpRequest is just for practice until DOM Level 3 Load-and-Save is implemented.

Does the address bar have to show every CGI request? Wouldn't avoiding whole-page replacements make DHTML feel more like Swing? Fewer page URLs shown surely means safer bookmarks. During a token transaction, URLs could be hidden entirely, so avoiding the danger of bookmarking into a transaction.

Concepts like a "stateless view" only matter to someone who understands what you are talking about. Most of the world doesn't have a clue...

It's true, we Struts hackers haven't got a clue about stateless view. I mean I have a page, AddUser.do, if the user hits refresh afterwards, then IE shows a retry/cancel dialog before form resubmission. If the user agrees to it, then my Struts action throws an SQL exception. Can JSF's stateless view make browser refreshing safe by inherently avoiding duplicate form submission?

I like that. Introducing Shale, Craig describes a (seemingly standard) approach for Struts 1.x programming, where "the setup logic and processing logic end up in two different Actions". I would appreciate a link to a page somewhere on Apache website which promotes this techique. I had to reinvent this wheel myself with the help of other resources including Ted Husted's tips.

Brian, browsers dislpay this retry/cancel dialog if a resource was loaded using POST request. For the browser, resource is the result page which you want to refresh, and the POST is the standard request type to submit a page. You can change requst type from POST to GET in the <form type="..." < attribute. This way browser will silently resubmit the form, and you would have to fight with resubmitted data. The choice which seems better to me, is to use redirection to the result page, which will be loaded using a separate GET. This way a browser won't display dialog because it simply loads a result page, not submits form data and receives a result page.

JSF allows to load result page using redirect, and what is the best thing, you do not have to do anything. The intermediate data is stored on the server for you in between requests. This works seamlessly, I tried it recently, you just need to add a <redirect> element to the config file. You can achieve the same effect in Struts Classic, but with some additional effort.

MS had to convert VB programmers which are used to drop the control on the form and to link the onChange event with some business code. This is great for prototyping, but after 20-30 windows this becomes an unmanageable mess. Luckily, Java community does not have VB legacy.

Off-topic here, but whenever I read comments like the above I find it very depressing. If you compare something like Tapestry with ASP.NET, it's remarkable how similar they are, yet they were conceived and developed entirely independently. A case of two sets of clever people (one person, in the case of Tapestry) coming up with almost exactly same solution to a problem (the simplification of web user interface development).<br>Whenever someone complains about a framework being too easy for serious use, it rings alarm bells with me.

development).<br>Whenever someone complains about a framework being too easy for serious use, it rings alarm bells with me.

Too much of one up manship in Java world.

These frameworks are all the rage these days but think about a poor new programmer who has to learn1. Java2. http3. html4. strut5. JSF6. etc etcadded to that new releases of api's and all this in the name of making things easier. You must be dreaming. I think things were better when we wrote our own simple frameworks using the core API. Struts is not that clever after all.

Too much of one up manship in Java world.These frameworksare all the rage these days but think about a poor new programmer whohas to learn1. Java2. http3. html4. strut5. JSF6. etc etcadded to thatnew releases of api's and all this in the name of making thingseasier. You must be dreaming. I think things were better when we wroteour own simple frameworks using the core API. Struts is not that cleverafter all.

I don't think it's oneupsmanship really, but it sometimes smells likeit. Like any other human endeavor that takes time to evolve, we standon the shoulders of what came before.

You do bring up a good point regarding the profusion of IT ideas, whichof course is nothing new. The increasing rapidity with which the ideasprofuse brings up a meta question: how do people keep up? I suspecteach individual's answer to this question is a closely kept personaltrade secret, but I thought I'd ask anyway.

I have my hands full just trying to develop JSF 1.2, but theideas keep coming. My process is just to block out time once or twice aweek and hit TSS, Java.net, and Slashdot. Go into just enough depth toget the gist, and move on. However, even with that light treatment,things are getting hard to handle.

Too much of one up manship in Java world.These frameworks are all the rage these days but think about a poor new programmer who has to learn1. Java2. http3. html4. strut5. JSF6. etc etc

added to that new releases of api's and all this in the name of making things easier. You must be dreaming. I think things were better when we wrote our own simple frameworks using the core API. Struts is not that clever after all.

No, I'm not a Microsoft developer, i am J2EE dev. but i think things are getting out of hand now. One of the reasons i was drawn to Java was that it seemed like a good core api and a good language. but what is going on now? Open source overdose. It's a shame that Sun didn't sell java then they would have some money to develop it properly instead of creating comittees that are 5 years behind everyone else.

MS had to convert VB programmers which are used to drop the control on the form and to link the onChange event with some business code. This is great for prototyping, but after 20-30 windows this becomes an unmanageable mess. Luckily, Java community does not have VB legacy.

Funny, but all Strut apps that I have seen have the same "unmanageable mess" issue (granted, I have not seen all Struts apps in existence :) ). Yes, they may be more flexible, but at a high price. The problem with ASP.Net is that it still holds to the page paradigm. And that it has no servlet equivalent.

With JSF, things are views with things responding to events. At first glance, it looks like things are less spread out than with Struts.

The problem with ASP.Net is that it still holds to the page paradigm. And that it has no servlet equivalent.

MSDN on Struts: "The Struts architecture is essentially derived from a combination of the Front Controller and Intercepting Filter patterns. The Struts framework provides a single controller that governs the application events, while filters catch and process incoming and outgoing events to ensure that each of the MVC components receive exactly the information they need."

MSDN on ASP.NET: "ASP.NET implements MVC using the Page Controller pattern. In contrast to the Struts implementation, which allows complete application-level control, the Page Controller pattern applies the controller at the level of individual pages. ... Very complex and large applications usually require more flexibility in page-to-page and page-to-process navigation. To provide this flexibility, the ASP.NET controller mechanism can be improved in two different ways: either by centralizing the Page Controller, or by implementing the Front Controller pattern on ASP.NET."

Afaik, ASP.NET 2.0 will have built-in support for Front Controller. Which Struts already have. Craig McClanahan ensures the public that Struts Classic won't die. At least while there are "volunteers who prefer to leverage their existing investment in Struts Classic."

Once I watched a documentary about Japan and their crafts. There was this one guy who was a carpenter. He went to another guy who made a proper plane for him. In order to make this plane, he went in the mountains looking for the perfect stone to sharpen the blade. He spent quite a while before he found it. Then he made a plane and gave it to the first guy, who then made a thinnest a smoothest slice. They used old proven tools and techniques and perfected their crafts to the max. Programmers usually do not do that ;)

What exactly? Could you drop a link, please? Are you talking about this: "Pure OO systems are simultaneously more complex to build and easier to maintain than hybrid procedural/OO systems. ... Nonetheless, most Java shops don’t do anything like pure OO. In fact, many Java programmers don’t understand even the basic principles of OO design and programming. Moreover, many off-the-shelf tools encourage a procedural approach (Apache’s Struts open-source framework comes to mind). If you’re working this way, you won’t get most of the real benefits of OO, however."

It just depends on what to consider an object. Some prefer to think in page-oriented way, that page with underlying logic and data is an object. I prefer to consider only server data and code as part of an object. I regard a web page as a detachable faceplate on a cell phone.

As Rod Johnson (Spring) says Struts is request-driven web MVC and JSF (Shale) is page-centric RAD (rapid development with tools as in VB). JSF is built for tools and for people that are code-challenged. Combining them is a mere market ploy signaling that the Struts community has probably inadvertently, under the leadership of its author and the author of a new family, conceded its future to other web MVC solutions (Spring, etc).

The core Struts people for some reason vehemently deny this in rude terms, but the truth is obvious. Struts probably is dead.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.