Struts2 or JSF?

D

Donkey Hottie

I'm kind of an old dog (25 years of programming) and I know Struts 1 well,
I can think in Struts 1.

But for future, which one of Struts 2 or Java Server Faces, would be better
to learn?

I know nothing about JSF, except that my favorite editor Netbeans supports
it good. I know nothing about Struts 2, except that it is very different
from Struts 1.

My current job is maintaining and developing a Struts 1 application, and
that goes swell. We don't do Ajax, and I have a feeling that those two
newer frameworks might have Ajax built-in, and a new framework will
eventually be a reality. Maybe not in this project, but in some new.

We do things ant based and not based on any IDE, so the Netbeans support
for JSF may be irrelevant. We use XDoclet now for Struts. I guess XDoclet
does not have any support for either JSF nor Struts 2.

What to learn?

XDoclet is not mandatory, we used that mostly for Ejb 2.x, but now we have
moved to Java 5 and Ejb3, and XDoclet remains only for Struts.
 
L

Lew

I'm kind of an old dog (25 years of programming) and I know Struts 1 well,
I can think in Struts 1.

But for future, which one of Struts 2 or Java Server Faces, would be better
to learn?

I know nothing about JSF, except that my favorite editor Netbeans supports
it good. I know nothing about Struts 2, except that it is very different
from Struts 1.

My current job is maintaining and developing a Struts 1 application, and
that goes swell. We don't do Ajax, and I have a feeling that those two
newer frameworks might have Ajax built-in, and a new framework will
eventually be a reality. Maybe not in this project, but in some new.

We do things ant based and not based on any IDE, so the Netbeans support
for JSF may be irrelevant. We use XDoclet now for Struts. I guess XDoclet
does not have any support for either JSF nor Struts 2.

What to learn?

XDoclet is not mandatory, we used that mostly for Ejb 2.x, but now we have
moved to Java 5 and Ejb3, and XDoclet remains only for Struts.

Like you I'm familiar with Struts 1 but not Struts 2. Looking the
latter over, it looks much, much cleaner. I have been learning and
practicing with JSF.

Asking, "Which is better, Struts 2 or JSF?" is like asking, "Which is
better, (plain old) JavaBeans or EJBs?" Struts 2 and JSF serve
related but different purposes, and have radically different
architectures.

Struts follows a simplified MVC with a single controller. JSF uses a
controller, called a "backing bean", for each screen. Struts
basically just glues together custom-built screens with logic beans
(View and Model). JSF is a full-fledged component model, rather
similar to Swing.

My sense is that JSF is far, far more powerful, and there are some
pretty slick frameworks built atop it (Trinidad, Tobago). It also
makes good use of the relationship between Java and Javascript. JSF
also has a rather complex lifecycle with a few rather pungent
gotchas. Based on my work with it so far, I think JSF is worth the
effort.

Lately I'm having trouble combining JSF and JPA (Java Persistence API)
to retrieve images (JPGs, PNGs) from a database for display in an
image tag in the JSP. I haven't figured out what I'm doing wrong yet,
but I think I'm interfering with the JSF lifecycle. The debugger
tells me that the image content (byte array) is pumping to the
response's output stream, but nothing displays in the browser.

This might not have to do with JSF, but the complexity of JSF (at
least on this part of the learning curve) leaves me uncertain. When I
do find the answer I'll post it in this forum.

Otherwise I am very happy with JSF.
 
G

Giovanni Azua

Hi,

Please note this is my personal opinion and experience and not the absolute
truth. The discussions about which Framework is better can get very heated.

Donkey Hottie said:
I'm kind of an old dog (25 years of programming) and I know Struts 1 well,
I can think in Struts 1.
But for future, which one of Struts 2 or Java Server Faces, would be
better
to learn?
[snip]
I haven't used JSF myself but I have extensively used Struts 2 and can
strongly recommend it. I think that the evolution from EJB2 to EJB3 is
somewhat analogous to the evolution from Struts1 to Struts2:

Struts 2 improves over 1:

- POJO centric approach e.g. Actions can be POJOs i.e. +code
quality, -boilerplate, +testability
- Favors annotations and zero configuration (with a very pragmatic
development by convention) versus excessive xml e.g.
> Validation
> Conversion
> Code behind plugin
- Interceptors
- Excellent AJAX support
....
- Even integration with JSF
http://struts.apache.org/2.x/docs/jsf-plugin.html

Last time I checked and my personal impression was that JSF lost momentum
due to its complexity, well it is still used in e.g. big Swiss banks that
stick to standardized solutions and pay excessive SLA for specific
technology support. The last company I worked for ended with two main
candidates for Web Development: Struts 2 and Wicket. Struts 2 was chosen for
many reasons and turned to be very successful. A few months after the
decision was made, Struts 2 was topping the charts among the most downloaded
open source projects.

That said, the architecture of Struts 2 offers very good opportunities for
componentization and reuse. In fact I am planning to build a
perfectjpattern-struts2-plugin that will offer automatic CRUDs as a
combination of:

- Generic CRUD action mappings
- Extendible CRUD State machine action (State Pattern)
- Generic DAO custom interceptor(s)
- High-performing external paging and sorting integrated with displaytag
i.e. Built in Top N queries in Generic DAO

this would kind of compete with approaches that use code generators.

HTH,
Best regards,
Giovanni
 
J

Jacek Wojciechowski

But for future, which one of Struts 2 or Java Server Faces, would be better
to learn?

I have a one year long experience in JSF - at the beginning I liked
it, at the end - I hated it. And gave it up completely couple of
months ago.

A few most irritating things:
1. JSF component model is a kind of "reversed-MVC". It looks more like
this: 'view' gets a request and then view elements read their state
from "backing beans". Then an action might be invoked. So there is no
clean way to initialize the view (!). If you want to initialize a view
(for example reading some data from database) you'd have to do it in a
'previous' action, which will subsequently redirect to the view you
wanted to populate.
2. 'JSF actions' doesn't take arguments - you have to set some
properties of some "backing bean" to achieve it (there is also some
other workaround for that but even less convenient).
3. Doesn't work without JavaScript. Perfectly anti-RESTful. Only HTTP
POST requests. No "get-after-post" pattern.

JBoss Seam seams to handle some of these flaws.

IMHO, the best choice now is SpringMVC (with Spring WebFlow, Spring
JavaScript and Spring Faces - the last one is just using JSF view
technology 'backed' by Spring MVC mechanism) or Struts 2 (I haven't
tried it a lot but my first experiences were 100% positive).
 
A

Arne Vajhøj

Donkey said:
I'm kind of an old dog (25 years of programming) and I know Struts 1 well,
I can think in Struts 1.

But for future, which one of Struts 2 or Java Server Faces, would be better
to learn?

I know nothing about JSF, except that my favorite editor Netbeans supports
it good. I know nothing about Struts 2, except that it is very different
from Struts 1.

My current job is maintaining and developing a Struts 1 application, and
that goes swell. We don't do Ajax, and I have a feeling that those two
newer frameworks might have Ajax built-in, and a new framework will
eventually be a reality. Maybe not in this project, but in some new.

We do things ant based and not based on any IDE, so the Netbeans support
for JSF may be irrelevant. We use XDoclet now for Struts. I guess XDoclet
does not have any support for either JSF nor Struts 2.

What to learn?

XDoclet is not mandatory, we used that mostly for Ejb 2.x, but now we have
moved to Java 5 and Ejb3, and XDoclet remains only for Struts.

XDoclet has JSF support.

Both NetBeans and Eclipse has JSF support. And even though you build
with ant, then I assume you use an IDE for writing the code (the part
that XDoclet does not generate).

JSF seems to have more industry backing than Struts 2.

There are plenty of JSF implementations with AJAX.

The bottom line is that I think you will be better of going
the JSF route.

Not because it is technically superior, but because it seems
as the best investment long term.

Arne
 
A

Arne Vajhøj

Jacek said:
I have a one year long experience in JSF - at the beginning I liked
it, at the end - I hated it. And gave it up completely couple of
months ago.
3. Doesn't work without JavaScript.

Sure does.
Perfectly anti-RESTful.

JSF is for human-app. REST is for app-app. Not really
a problem.

Arne
 
A

Arved Sandstrom

[ SNIP ]
Lately I'm having trouble combining JSF and JPA (Java Persistence API)
to retrieve images (JPGs, PNGs) from a database for display in an
image tag in the JSP. I haven't figured out what I'm doing wrong yet,
but I think I'm interfering with the JSF lifecycle. The debugger
tells me that the image content (byte array) is pumping to the
response's output stream, but nothing displays in the browser.
[ SNIP ]

********************

Have you tried the image servlet approach?
http://balusc.blogspot.com/2007/04/imageservlet.html#ImageServletServingFromDatabase
Still using JSF - JSP or Facelets - but no use of JPA. I haven't had to do
this myself but if I had the requirement to pull images from a DB and use
them in h:graphicImage I think this is the way I would go.

JSF is easy to misuse if one doesn't understand the lifecycle. I've made all
the mistakes myself. Usual symptoms are multiple calls to backing bean
methods (including redundant database hits if one hasn't implemented lazy
loading), wondering why values aren't what they should be when something is
marked as immediate="true", being baffled by the failure of c:if acting on
h:dataTable "var" values etc etc.

My most brutal JSF-JPA problem to date (I haven't quite solved it yet) is
due to Toplink wanting to flush updated objects to the DB before doing a
ReadQuery (i.e. a SELECT), and nothing deliberate in the code has actually
updated any of the objects in question. What's really ironic is that the
only fields which actually get updated are
lastUpdated{DateTime,User,Service} fields that are *only* changed by a
@PreUpdate method. JSF is not the culprit, per se - it was the misuse of it
(lack of lazy loading) that caused a second useless SELECT which then
triggered masses of unexpected UPDATEs. The real quandary is figuring out
why Toplink thinks these objects need to be updated...right now I'm delving
into the unit of work change sets to see if I can figure out what's going
on.

AHS
 
A

Arved Sandstrom

Jacek Wojciechowski said:
I have a one year long experience in JSF - at the beginning I liked
it, at the end - I hated it. And gave it up completely couple of
months ago.

A few most irritating things:
1. JSF component model is a kind of "reversed-MVC". It looks more like
this: 'view' gets a request and then view elements read their state
from "backing beans". Then an action might be invoked. So there is no
clean way to initialize the view (!). If you want to initialize a view
(for example reading some data from database) you'd have to do it in a
'previous' action, which will subsequently redirect to the view you
wanted to populate.

You certainly can initialize a view on the first call. I'm not sure why
you'd consider the ways in which it can be done "unclean".

In any case views are not getting requests. If the request maps to the
FacesServlet _that_ is what is getting the request. If it happens that the
request is actually an instruction to invoke a backing bean method, the JSF
phases are merely ensuring that proper form values are submitted for the
method to use. The action methods (in combination with business logic in the
session EJB layer) implement the controller "intelligence", so to speak...to
draw an analogy, the FacesServlet (along with the other core classes like
navigation handlers and resolvers ) are to the managed bean action methods
like an XSLT servlet is to stylesheets. However, there is nothing "reversed"
about it.
2. 'JSF actions' doesn't take arguments - you have to set some
properties of some "backing bean" to achieve it (there is also some
other workaround for that but even less convenient).

That's the point, though - the form element values _are_ the arguments.
3. Doesn't work without JavaScript. Perfectly anti-RESTful. Only HTTP
POST requests. No "get-after-post" pattern.

Doesn't work without JavaScript? How so? Granted, JSF pages with certain
types of functionality will likely use JavaScript, but then so will web
applications using REST.

As for REST, well, I just hope all these people who demand it - and
denigrate JSF for not having it - actually understand what it is, and have a
good reason for needing it. It seems to me like too many folks equate REST
with being able to bookmark pages...
JBoss Seam seams to handle some of these flaws.

IMHO, the best choice now is SpringMVC (with Spring WebFlow, Spring
JavaScript and Spring Faces - the last one is just using JSF view
technology 'backed' by Spring MVC mechanism) or Struts 2 (I haven't
tried it a lot but my first experiences were 100% positive).

I don't think there are any "best" choices. A number of frameworks (or
combinations thereof) all work. You pick one and get on with the job. Just
my opinion. I happen to use mostly JSF right now because most of my firm's
clients use it, but if another client used Spring I'd make the application
work with that.

AHS
 
L

Lew

Lew wrote ...
[ SNIP ]
Lately I'm having trouble combining JSF and JPA (Java Persistence API)
to retrieve images (JPGs, PNGs) from a database for display in an
image tag in the JSP. I haven't figured out what I'm doing wrong yet,
but I think I'm interfering with the JSF lifecycle. The debugger
tells me that the image content (byte array) is pumping to the
response's output stream, but nothing displays in the browser.
[ SNIP ]

Arved said:

I had an image servlet but it lacked the 'response.reset()'. Thanks.

My servlet had worked with a straight JSP / JDBC approach so it was quite the
mystery.
 
A

Avishek

Hello All,

I too 've worked on Struts 1, have a basic understanding of JSF &
currently developing an appilication on Struts2.


I wd support Struts2.
Reasons:
- Single Controller based framework.
- Easy Spring integration.
- Easy Hibernate integration.
- AJAX support.
- Many changes can be made on the fly without restarting a web
container.
- Annotations based structure.
- Java 5 annotations as an alternative to XML and Java properties
configuration.
- All framework classes are based on interfaces and core interfaces
are independent from HTTP.
- Overheads of class instantiations into the memory removed.
- No more need to extend Action class but Actions are simple POJOs.
- ActionForward, ActionMapping, HTTPRequest, HTTPResponse not
required.
- Interceptors.
- Inbuilt support for Validations & Tiles framework(in struts 1 we
need to have plugins).
- Cleaner code.
- Quicker development.

Whereas I believe JSF has more complex architechtural flow.

regards,
AvishekA
 
D

David Segall

Jacek Wojciechowski said:
I have a one year long experience in JSF - at the beginning I liked
it, at the end - I hated it.
Only HTTP POST requests.
Not being able to process GET requests seemed like an extraordinarily
serious omission and I took days to find out how to do it. I added a
note to my web site in the hope that it would save someone else the
time <http://www.profectus.com.au/ee_getdata.html>. It's trivial if
you use Netbeans and doable if you don't.
 
D

Donkey Hottie

I don't think there are any "best" choices. A number of frameworks (or
combinations thereof) all work. You pick one and get on with the job.
Just my opinion. I happen to use mostly JSF right now because most of
my firm's clients use it, but if another client used Spring I'd make
the application work with that.

So you are omnipotent, good for ya ;)

I started 25 years ago with Cobol, Pascal and C. I find HTML annoying.. All
these frameworks around html are a nuicanse to a programmer ;)
 
D

Donkey Hottie

XDoclet has JSF support.

Both NetBeans and Eclipse has JSF support. And even though you build
with ant, then I assume you use an IDE for writing the code (the part
that XDoclet does not generate).

JSF seems to have more industry backing than Struts 2.

There are plenty of JSF implementations with AJAX.

The bottom line is that I think you will be better of going
the JSF route.

Not because it is technically superior, but because it seems
as the best investment long term.

Arne

Thanks for your kind response, Arne!

Yes we use both Netbeans and Eclipse for editing, but the actual project
codebase does not know it. Everyone has their own "projects" in their own
IDE and they are not shared.

Ant is the common way to build it.
 
A

Arved Sandstrom

Donkey Hottie said:
So you are omnipotent, good for ya ;)

Well, not omnipotent. :) Let's face it, in a lot of environments the
clients have already invested in hardware and application servers and
databases, and not infrequently they seem to know better than the software
developers do what languages and frameworks should be used, so you just suck
it up and program in whatever they want.

It's certainly impossible for me, at any given time, to be equally
proficient at JSF and Spring and Struts and ASP.NET etc etc. Right now I
happen to be best at JSF.
I started 25 years ago with Cobol, Pascal and C. I find HTML annoying..
All
these frameworks around html are a nuicanse to a programmer ;)

Every so often I work on a pet project in C or C++ or OCaml or J or Erlang
(I don't purport to be a whiz at the latter three) just so I can get away
from web applications. I just don't get the same satisfaction out of
programming in Java or C# for web apps as I do using other languages for
technically more challenging tasks.

AHS
 
J

Jacek Wojciechowski

You certainly can initialize a view on the first call. I'm not sure why
you'd consider the ways in which it can be done "unclean".

Can you please point in what ways I can initialize the view is such
simple case: we have 5 views from which we can navigate to details of
some order (identified with id); we have also some other places from
which we can navigate there according to some condition. And we've got
50 such situations in the system. In what way would you initialize
such views? Special bean/method convention (this is what I would call
"unclean" - who will guarantee that this initializing method will be
in fact invoked? and if the view is composed of many elements
separately initialized)?
In any case views are not getting requests. If the request maps to the
FacesServlet _that_ is what is getting the request.

Technically yes - that's how servlet container sees that. But not
according to the life cycle of the JSF view.
Doesn't work without JavaScript? How so?

Well, I can remember that all this 'action' tags where using
JavaScript. It's kind of surprising to me that it can be avoided. How?
It seems to me like too many folks equate REST
with being able to bookmark pages...

For me this is "last but not least" thing about REST. Imagine testing
some functionality in which you have to navigate through 20 views to
test that functionality (please don't reply that 'Selenium' etc. is
for that).

I don't think there are any "best" choices.

There are some best choices according to some defined requirements.
 
A

Arved Sandstrom

Jacek Wojciechowski said:
Can you please point in what ways I can initialize the view is such
simple case: we have 5 views from which we can navigate to details of
some order (identified with id); we have also some other places from
which we can navigate there according to some condition. And we've got
50 such situations in the system. In what way would you initialize
such views? Special bean/method convention (this is what I would call
"unclean" - who will guarantee that this initializing method will be
in fact invoked? and if the view is composed of many elements
separately initialized)?

One usual way of arriving at a new view (new in the sense of different - it
may be genuinely new) is to use h:commandLink. One f:param to the
h:commandLink would have your order ID, for example. If you set up managed
properties on the target managed bean then the order ID maps to a
getter/setter, and is available to the action method called by the
h:commandLink. h:commandLink is exactly the equivalent of doing a form
submit to that managed bean. The outcome of the action method called by the
link obviously determines the new view, which in turn can access any managed
beans in scope to populate its fields.

If you create a debug phase listener for the purposes of printing out the
start and end of phases you can satisfy yourself that in this scenario all 6
phases are gone through for the target view, as opposed to the 2 that you'd
get if it was an initial view.
Technically yes - that's how servlet container sees that. But not
according to the life cycle of the JSF view.

Often it looks like that, yes. But in the case of h:commandLink, for
example, you don't reference a target page at all. It's only at the end of
lifecycle phase 5, INVOKE_APPLICATION, that you even know the view ID of the
page that is going to be rendered next.
Well, I can remember that all this 'action' tags where using
JavaScript. It's kind of surprising to me that it can be avoided. How?

h:commandLink needs it; most everything else does not. A lot can depend on
your view technology - for example, if I use MyFaces with facelets I get a
whole bunch of JavaScript. Doesn't mean it's all necessary.
For me this is "last but not least" thing about REST. Imagine testing
some functionality in which you have to navigate through 20 views to
test that functionality (please don't reply that 'Selenium' etc. is
for that).

I figure the best way to test use cases in a web app is human testers. Just
my humble opinion.
There are some best choices according to some defined requirements.

Perhaps. All I know is that if some client comes to me with user
requirements for a web app, technically either ASP.NET MVC or J2EE 5 is
going to work, to address it first at the highest level. In my opinion the
main driver in selecting an implementation technology for web apps is the
familiarity of your programmers with them. So considering only Java
frameworks I'd probably go with Struts 2 or Spring or JSF based on what the
majority knows best, not because I believe any one of them is going to be
technologically much better than the others.

AHS
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top