To Hans: Difference between Struts and JSF

[Nicholas Cheung]

Hi Hans,

As there are "never end" argues between the difference between Struts and JSF, and other frameworks, could you give a brief explanation about JSF and the major difference between JSF and Struts?

Thanks.

Nick

[Pradeep bhatt]

Some old threads

https://coderanch.com/t/46101/Struts/struts-vs-JSF

https://coderanch.com/t/45849/Struts/Struts-vs-Java-Server-Faces

https://coderanch.com/t/47484/Struts/Mr-Neil-Ford-Struts-vs

https://coderanch.com/t/47795/Struts/Opinions-Struts-vs-JavaServer-Faces

https://coderanch.com/t/284419/JSP/java/JSF-Replacement-Struts

https://coderanch.com/t/284502/JSP/java/Combine-JSF-other-Frameworks

https://coderanch.com/t/284428/JSP/java/Struts-vs-JSF


https://coderanch.com/t/284466/JSP/java/does-JSF-compare-Struts-Mr

[Nicholas Cheung]

But still, no conclusions can be drawn in fact.

I hope Hans can solve this *long-lasting* issue for us.

Nick

[Pradeep bhatt]

Originally posted by Nicholas Cheung:
But still, no conclusions can be drawn in fact.

I hope Hans can solve this *long-lasting* issue for us.

Nick

There are some things which cannot be solved.

[Hans Bergsten]

Originally posted by Nicholas Cheung:
Hi Hans,

As there are "never end" argues between the difference between Struts and JSF, and other frameworks, could you give a brief explanation about JSF and the major difference between JSF and Struts?

Thanks.

Nick

Looking through all the other threads dealing with this question, I see that most of the points have already been mentioned but let's see if I can give you a more conclusive answer.

I describe this in more detail in the book, but my take on this is that Struts and JSF are focused on different parts of the application. They also overlap in some areas, however, which is probably the cause for this endless discussion.

I refer to Struts as an "application framework". It's main goal in life is to hand off the processing of a request to code registered for the task indicated by the URI, and then hand off the response generation to another piece of code registered under a name returned by the request processing piece of code. Struts doesn't care much about how the request is processed or how the response is generated. Typically JSP is used to generate the response, and if so, there are tag libraries that can help, but you can use any template technology you like, e.g., Velocity.

I refer to JSF as a "UI framework." It's focus is on user interface components, which are bound directly to business logic properties holding their values. A request is processed through these components with the help of other well-defined objects attached to the component. For instance, an input component reads its value from the request, converts it to the business logic data type by calling an attached converter, validates it by calling an attached validator, and if everything is okay, sets the business logic property bound to the component to the new value. A command component looks for a marker in the request that tells it if it triggered this request, and if so, queues an event. An event listener bound to the command component handles the event when all components have processed their input, typically by calling business logic code, and may return an "outcome" mapped to a "view ID" to tell JSF to use a different set of components to render the response. The response is generated by the components, or more commonly, by an attached renderer.

So JSF hides a lot of the HTTP details and let you develop application code that's focused on the business objective rather that fiddling around with details that add no value to the application. More importantly, a JSF
component handles both output and input. For instance, an date input component can let the user input the date by selecting a year, a month and a day from three separate selection lists. Because it knows this, it can correctly read the three input values, merge them and convert the value to a java.util.Date object and update the business logic with this Date object. Struts, on the other hand, may provide a JSP tag that generates the three selection elements, but your application code must know about it and get all three values from the request.

The overlap is in validation and navigation. JSF provides just the basics for component level validation out-of-the box, while Struts offers a more sophisticated validation mechanism. I don't think the functional differences in navigation are so big, rather different because of differences between the framework. The important point, though, is that you can plug in custom validation and navigation support in JSF if the defaults aren't good enough for your application.

So, that leaves us with the big question: which should I use? My standard answer is that for an existing Struts application, if you want to migrate to JSF for the user interface, it may be a good idea to do it piece by piece with the help of the Struts-JSF integration library if the application is big and complex. If it's small, it's pretty straight forward to migrate all of it to JSF in one shot.

But first you need to ask yourself if migrating is the right thing to do. For a complex user interface, the answer is probably "yes" (at least if you're still making user interface changes now and then). For an application with a simple user interface (e.g., mostly simple dynamic output rather than a lot of complex input), or an application that's rarely changed, the answer is probably "no".

For a new application, JSF would be my first choice if the user interface is complex, or plain JSP or some other template technology if the user interface is simple. If there are Struts features you can't live without, or don't want to implement as JSF plug-ins, I would take a look at the Struts-JSF integration library and consider using both.

I hope this helped a bit.

[Nicholas Cheung]

Hi Hans,

Thanks for the detail explanation.

In addition,

JSF provides just the basics for component level validation out-of-the box, while Struts offers a more sophisticated validation mechanism

Does JSF support the validate.xml method as the way that Struts supports? If so, we can still use regular expression to check whether the data input is valid, and confirm to certain formats.

Nick

[Hans Bergsten]

Originally posted by Nicholas Cheung:
Hi Hans,

Thanks for the detail explanation.

In addition,

Does JSF support the validate.xml method as the way that Struts supports? If so, we can still use regular expression to check whether the data input is valid, and confirm to certain formats.

Nick

The JSF specification doesn't define a regular expression validator, but it's easy to create a custom validator for this. I wouldn't be surprised if there's an open source custom validator for this already. If not, one will likely appear soon.

[bas duijzings]

hmm, the beginning of this thread did bring a smile on my face. (thank nicholas)

To contribute the following:
If you can integrate struts and jsf, then why not use the struts validator ?
Maybe i missed the answer, but what could be the problem ?

[Hans Bergsten]

Originally posted by bas duijzings:
If you can integrate struts and jsf, then why not use the struts validator ?
Maybe i missed the answer, but what could be the problem ?

Sure, if you use the Struts-JSF integration package, you can use the Struts validation for this. But if you want to use just JSF, it should be fairly easy to just make a custom JSF validator with the same functionality.

[Mcgill Smith]

Can JSF components be used in a Tapestry environment or vice-versa?




Thanks in advance.

[Hans Bergsten]

Originally posted by Mcgill Smith:
Can JSF components be used in a Tapestry environment or vice-versa?

Thanks in advance.

Today, no. I don't know enough about Tapestry's architecture to tell for sure if it would be possible to add support for JSF components. Even if it can be done in theory, it may turn out that Tapestry-specific custom renderers are needed for the integration, making it less interesting in practice. It's, however, something I hope to find the time to study.

Unless a lot of Tapestry components start to pop-up all over the place, I think it's less likely that JSF will add support for Tapestry components. And again, I don't if it's even possible to do in practice.

[bas duijzings]

so it is not as there is a "never end" argument between the difference between Struts and JSF,
but it is more a choice between JSP and tapestry

[bas duijzings]

sorry typo: my earlier reply should be
jsf and tapestry instead of jsp and tapestry

[Howard Lewis Ship]

Originally posted by Hans Bergsten:
[QB]

Today, no. I don't know enough about Tapestry's architecture to tell for sure if it would be possible to add support for JSF components. Even if it can be done in theory, it may turn out that Tapestry-specific custom renderers are needed for the integration, making it less interesting in practice. It's, however, something I hope to find the time to study.

[QB]

I really racked my brain on this subject a ways back; I wanted to be able to use JSPs instead of HTML templates and wanted JSPs to be able to reference Tapestry components. It gets down to the rendering methods; in Tapestry components run their own rendering: there's just a render() method.

In JSP/JSF, the container manages rendering: there's a whole series of methods to invoke to render the start tag, the end tag, the body, to continue rendering or not (used with looping types of tags), and so forth. This mismatch causes a lot of impedance between the two models! I literally started looking at ways to break up the rendering of components into a more JSP-like model, and kept finding 95% solutions that couldn't be extended to 100%. Then the JSF RI came out and I decided it would be smarter to make Tapestry better than to chase phantoms

[Hans Bergsten]

Originally posted by Howard Lewis Ship:


I really racked my brain on this subject a ways back; I wanted to be able to use JSPs instead of HTML templates and wanted JSPs to be able to reference Tapestry components. It gets down to the rendering methods; in Tapestry components run their own rendering: there's just a render() method.

In JSP/JSF, the container manages rendering: there's a whole series of methods to invoke to render the start tag, the end tag, the body, to continue rendering or not (used with looping types of tags), and so forth. This mismatch causes a lot of impedance between the two models! I literally started looking at ways to break up the rendering of components into a more JSP-like model, and kept finding 95% solutions that couldn't be extended to 100%. Then the JSF RI came out and I decided it would be smarter to make Tapestry better than to chase phantoms

Hi Howard, thanks for the insight.

I agree that there's a big impedance mismatch between JSP and Tapestry, and it's probably not worth the trouble to try to get them to play nice.

But JSF components for Tapestry may be possible. I'm not sure how up-to-date you are with JSF, but the interesting thing is that the JSF API is totally independent of JSP, and JSF components (just like Tapestry components) render themselves (it's three methods for a JSF component rather than one for a Tapestry component, but none of the "call these methods until you get this return value" business as you see in JSP). That said, there may be other areas that still make it hard to do in practice.

Like I said earlier, I think it would be cool if it can be done, so maybe we can explore this a bit off line (or on the Tapestry list, if you prefer to do it in public).

[frisode jonge]

come on guys, two authors together !! that must be synergy !!

[Lasse Koskela]

I really don't know whether there will be synergy, but I am sure that you guys should put your heads together--if at all possible--to see whether there is...

[sanjay kumar]

Hi All,

Please check out this link http://www.samlsecurity.com/jsf.html
Author compares JSF with Struts and Webwork


Sanjay

[Nicholas Cheung]

Hi Hans,

but the interesting thing is that the JSF API is totally independent of JSP

Could this be possible? as if we display JSF components in JSPs? Should there be at least a little dependency?

Nick

[Hans Bergsten]

Originally posted by Nicholas Cheung:
Hi Hans,



Could this be possible? as if we display JSF components in JSPs? Should there be at least a little dependency?

Nick

The JSF API is independent of JSP (with exception for the javax.faces.webapp package). The JSP tag libraries are, of course, dependent on JSP, but you don't have to use JSP pages to create JSF components.

With a custom ViewHandler, you can create JSF components (arranged in JSF views) any way you like, e.g., with pure Java (similar to Swing) or with XML "view specification files" bound to pure HTML templates (similar to Tapestry). The rest of JSF works just as when you use JSP to create the views. I describe ViewHandlers for both these alternatives in the book.

[Kiran Kumar P]

The basic difference as Hans mentioned is struts is a "application framework" and JSF is a "UI Framework"

In a web application framework like Struts, the interfaces are more kind of "Generic".Struts can recognize only
only one event - "HTTP REQUEST".

In a UI framework, there are many events like "Button clicked","Combo selected" etc.And there are listeners
for each of this event, which will perform different actions based on the event.

[gautham kasinath]

Well, I see that the discussion is mostly on the comparison of Struts and JSF, for which Hans clearly mentioned the difference.
What I would like to know is how does JSF compare with Velocity.
I am relatively new to JSF and I understand it uses mostly a Command pattern, which is listener driven for Events generation and consumption.
The pattern interests me, but I would like to know how exactly it works??]

Thanks!!
Lupo

[Dave Knipp]

Hi,

It sounds like JSF will more than anything compliment Struts nicely, but are there any downsides to using struts directly with JSF? Does the struts-JSF intergration library include tags that will help you communicate between the JSF components and the forms/actions?? Also do you find that the struts validator is always better than using your own custom validator in JSF or is JSF the way to go??

Thanks,
Dave