For example, for something used in a hospital I would imagine that there are a lot of security and regulatory requirements; have you considered how those might affect your choice of framework? Or is this merely something for school, not to be used for real?
Nilesh Sanyal wrote:Sir, the J2EE project on Hospital Management System will be submitted for my collage for completing major project of MCA(Master of Computer Application). So from that perspective which framework should I choose between JSF / Struts?
I believe we've already given you an answer: If it was up to us - neither. However, since you seem to have been given the choice between horse and steam power, I'd choose the one that you're most familiar with.
Failing that - and since you don't seem disposed to provide any further information - flip a coin.
If you can step outside that box, I'd recommend SpringMVC over either of those as more widely used in the industry and more likely to be useful.
But ultimately, rendering UI on the server to send to the client is on the wane at this point. Anyone who wants to be up-to-date with what's sought in the industry would study up on client-side MVC frameworks.
... and by "be able to do" I mean technically, not the business side.
When it's time to round up the cows, the ultimate reason for most applications is to accomplish a business solution. So any framework that cannot support that isn't worth considering. JSF and Struts have no business-specific functionality, but they are general enough that business-specific functions are not exceptionally difficult within them.
I published an "Introduction to Struts" article in JavaPro magazine in 2001. JSF will probably celebrate its 10th birthday this year (this is what passes for "archaic" in this field). Scan the want ads and you'll see plenty of positions available for both skills.
These days I favor JSF, as it is a pretty pure implementation of the Model/View/Controller paradigm and it's intended to allow applications to be built mostly out of XML View Templates and POJO Models. Which leaves the possibility that if a better platform came along later, conversion wouldn't require a total redesign. Struts is based on a less-pure MVC called "Model 2", but it may provide better performance than JSF when a lot of concurrent users are active. No one has ever published any stats that I've seen. JSF is simpler to use than Struts as it automatically populates form data and automatically does data validation to the extent that not only will it report data errors, it won't even accept forms with invalid data for processing. So, in short, it really shines for apps whose primary function is data entry. JSF also requires fewer source files to generate a webpage. That was an intentional design goal, as some of the designers of JSF had originally worked on Struts and didn't like all the "busy work" it required.
So you can tell which of the 2 platforms I tend to prefer.
There are, of course other options. Stuff like Spring Web, Wicket and Cocoon (if you're into XML-heavy apps). Or, if you want to be really trendy, one of the scripting platforms, beloved of managers because you can get pretty web pages up in a hurry (making them secure, reliable and performant is another matter).
One thing I do like about both Struts and JSF, however is that they're non-exclusive platforms. Once upon a time, if you picked a platform, every function in the app had to be based on that platform. Struts and JSF aren't that greedy. JSF, as I've said, is best employed for data entry forms (and tabular displays). If you need your app to spit out a PDF or Excel spreadsheet, you can do that with a traditional servlet or JSP and pass data between them and JSF or Struts via stock J2EE session objects. If you need web services, you can jack something like Apache CXF in. And so forth.