Why Struts?

Hanna Habashy

Ranch Hand

Posts: 532

posted 12 years ago

I want to hear from Struts Gurus why should a development team use struts? What is the benifiets of using struts actions? Why not building my own servlets actions? Is there another technologies like struts? Is it standarized yet? Will it vanish in the future, or it will become the standard of creating java 2EE projects? Thank you

SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle

David Yutzy

tumbleweed and gunslinger
Ranch Hand

Posts: 192

posted 12 years ago

I've been using Struts for several years now and the main reason I use Struts is to make sure that teams of developers are using the same process and framework to build applications within an enterprise. If you've been a part of "team" based projects, developers tend to have their own style or ways of doing things that don't necessarily fall in line with a "corporate" standard. Take for example how do pass information from an "action" or servlet. Do you create a bean or pass individual variables in request? How do you handle validation on a form: javascript or server-side? How does this information get to your servlet? As request variables or in a bean? These are very simplistic scenarios that any developer could implement is their own way using many difference techniques. Struts doesn't PREVENT this from happening, but provide a framework to make these (and many more) processes much easier and structured. Yes, I could go into the whole MVC structured development lecture, but the day to day benefits are much more important to me than trying to figure out how somebody did a piece of code. Wich Struts, you will have a lot less headaches knowing that your developers are at least on the same page when it comes to structure and separation of the various layers in a complex web application.

Bruno Dery

Ranch Hand

Posts: 37

posted 12 years ago

I would say Struts does a very good job at handling all the usual things you will encounter to build your web application, mostly in the controller layer. For the presentation itself it doesnt provide much, which wasnt it's intent anyways. It simply helps you build a very structured application, and to avoid coupling everything together. I have noticed one interesting thing, we didnt needed to code any servlets using struts, but rather call our business logic from Strut's actions. The interesting thing is that we noticed after a while that we can test all the business logic without even requiring any web code, and can use neat things like debuggers to help us in that. If you put too much logic in your jsp's, you'll have lots of fun debugging small things afterward (fun is being sarcastic here ). I would even recommend using a template engine like Velocity (we didnt, I'm not the one who did the presentation layer, but I wish I would ), it's much less messy than jsp and you can edit your html much easier like that.

Ken Robinson

Ranch Hand

Posts: 101

posted 12 years ago

I am 'anti-struts', so I'll offer my opinion. With what is available in the J2EE standard now, I believe STRUTS provides little that you do not have. When you consider that the 'meat' of your logic is in the Action subclasses you must provide, the fact that you map an Action to a URL and the Request/Response is passed into the Action, you have something just like a Servlet's doPost method. You will hear some of the advantages are that is helps with standards, provides a quick way to get a form beans, 'forces' MVC compliance and allows for pages to be 'tiled'. As stated in so many words above, any standard you develop can be broken in STRUTS as easy as a standard outside of STRUTS. Like J2EE, STRUTS provides classes to aid in the development of web apps but does not force any standard. I can have my Actions call an EJB, a business object of just put the code in an Action as easily as I can do these things in a Servlet. Form Beans are 'neat', but I choose not to use them. Basically, STRUTS will, for each and every request, map the HttpRequestParameter names to setXXX methods in a bean. Matching parameters and conversion is cut down a bit, but the cost of mapping for each request and runtime reflection must be considered. Personally, I either create the bean via an 'Adapter' class the requires a java.util.Map (not web specific) or just use the parameters as is, parsing those that need parsing. Either way, if you get a String in, the String is already created. If you need anything other than a String, parsing occurs and a new Object is created to hold the result. It's a question of what do you want the result to look like, and that's a question of personal/company preference. You will hear that STRUTS provides a good MVC environment, but STRUTS is actually modelled after the Front Controller Pattern. There is nothing to prevent you from putting display code in an Action, and there is nothing to prevent you from putting business logic in a JSP. MVC cannot be enforced from STRUTS anymore than it can be from base J2EE classes. That is a coding standard and enforcement policy. Look at the method signature in the Action class. It's the same as doPost/doGet with a FormBean and ActionMapping. ActionMappings are very basic mappings to JSP pages that require your Action class to return a String to indicate status. Do you do this anywhere else in the Java world of programming? Simply having parameters that are initialized during startup of a servlet gives you the same thing by allowing you to call RequestDispatcher yourself. This is slightly more effecient and only takes two more lines of code and a few minutes. Declare a var for each possible outcome (String of URL or RequestDispatcher object, your choice), init that var in the init() method via the use of <init-param> entries in web.xml (can an Action even have init params?) for each outcome (do NOT hardcode URLs), and instead of sending a String as a return value, just call the RequestDispatcher (directly or by getting it from the String). STRUTS has some nice JSP tags, but JSTL provides much of the same thing in an industry standard interface. I've been doing J2EE/Web apps for years and STRUTS came along after I had become 'set in my ways'. I think it is mainly a different look and feel to the same programming model available with the current J2EE classes. It has a large following (probably most popular 'framework'), however I choose to stick with the base J2EE classes. If you have to use a certain pattern, consider that via web.xml, the web server itself parses the URL and forwards to the correct servlet, giving you much of the same Front Controller/MVC functionality most people desire. The main difference is it is not hyped as such. This is my opinion that I've developed after years of J2EE development and an evaluation of STRUTS. I hope it helps you make your decision.

Eric Sexton

Ranch Hand

Posts: 133

posted 12 years ago

Hmmm... I don't agree that just because you can stray from the purpose of a framework, that invalidates it in any way. But I digress. After building Struts apps for the past several months now and building the "type" of web apps that we build at my company, I think that Struts is a great framework, especially with tiles and the validator. I still think it comes down to taste. If Struts sounds like it would help you and your team, then do it. If not, don't. I'll tell you what though, for my app that I'm currently working on, Struts is going to provide a lot of ease with future tweaks and changes to the site. I like that.

Hanna Habashy

Ranch Hand

Posts: 532

posted 12 years ago

Thank you all for your responds. I really appreciate every word of it. I am a little worry that Struts frame work will vanish in few years or so. If it happens, it will be hard in the future to find a junior programmer to modify the code and enhances it, as it will requirs the knowledege of Struts frame work. If my spaculation is true, wouldn't be better to stick with J2EE standerds, and relay on our own frameword. Thanks again

SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle

Ken Robinson

Ranch Hand

Posts: 101

posted 12 years ago

We've seen JSTL come along to standardize many of the Tags also available in STRUTS, and we've also seen Java Server Faces introduced, which is 'STURTS like'. I believe worrying about the level of support for STRUTS in a year or two is a valid concern. More than that, I'd be worried about the next 'buzz'. As soon as something 'newer and better' comes along, there will be a big movement to it (there always is). J2EE is THE standard. There are no STRUTS web servers, only J2EE web servers. This is the purpose of STRUTS' ActionServlet, to 'wire' STRUTS into the industry supported J2EE standard.

Eric, how does STRUTS allow for 'a lot of ease with future tweaks'? Do you agree that the vast majority of code needs to be written regardless of the approach, it's the organization and placement of that code that usually differs?

Eric Sexton

Ranch Hand

Posts: 133

posted 12 years ago

According to Sun and Craig McClanahan(struts author) the future of Struts lies in a struts/JSF hybrid. I've read a bit about this and I hope to find more details on that at JavaOne next year. It is true that J2EE is the standard. You can ALWAYS rely on that. (let's pray now) I don't think you need to be too concerned about your stuff being obsolete or being too difficult for the noobs. The meat and potatos of your app should be able to be reusable and not totally wrapped up in the framwork anyhow. If you are too intertwined with the framwork it's just not good. All the hardcore code of ours is abstracted out. We can plug it into another framwork without too much pain if we choose. I agree with Ken that the code still needs to be written. Very true. Good Java design fundamentals are going to be your greatest concern in my opinion. The framwork is secondary. Design well grasshopper. As for future changes being easy, I was referring to how Tiles allows us to change the layout and design of site fast! We can make the look of the site look completely different in no time at all and it's soooooo easy. I really am a fan on how Struts lays everything out. I will say that my opinion is shaped from not being in Kens position. I haven't been developing J2EE apps for years before getting involved with Struts. I've only had 2 years experience with J2EE and so I'm relatively new to it. Struts just fits nicely for me. With software development the future is never certain, and that's for certain.... wait errr uh nevermind.

Ken Robinson

Ranch Hand

Posts: 101

posted 12 years ago

Well put Eric. I have to admit that Tiles become popular just after my last real evaluation of STRUTS and I do not know exactly how they work and what they can do. I don't know if you are familiar with JSTL's <c:import> tag. I was wondering if there was a comparison. The <c:import> tag allows other JSPs or URLs to be included in a parent or enclosing JSP. 'Pieces' of a page can be placed in any order in any number of pages with one 'source' template. Is this pretty much what Tiles are? J2EE and STRUTS would both be much better off if they had one core team instead of two seperate efforts. They both have functionality inspired by other's inovation.

Andre Mermegas

Ranch Hand

Posts: 158

posted 12 years ago

Well here is a side thought, if you are worried about the minimal performance implications of using reflection with form beans how do you look at the performance hit from using a more heavyweight servlet based solution as compared to POJO struts actions where this is only 1 servlet per application?

...especially with tiles and the validator. I just had to point out that the validator framework that is used with struts can be used without struts. It is simply a Jakarta Apache Commons Project by itself.

Originally posted by Kenneth Robinson: More than that, I'd be worried about the next 'buzz'. As soon as something 'newer and better' comes along, there will be a big movement to it (there always is).

This is something I worry about as well, and I can't agree more with there being a 'big movement'. I am a sucker for 'buzz' technologies simply because I feel like I have to know a little bit about everything. What really concerns be is the talk I have been hearing about the next version of STRUTS. There really was a significant difference, IMO, between 1.0 and 1.1. And I have read (can't remember where) that there is going to be an even greater change between 1.1 and the next version. I like STRUTS in the sense that it can make web development faster, but I fear it is a 'buzz' technology, regardless of how many coorporations are adopting it these days. Just had to add my 2 cents, though they might be worthless since I appreantly am riding the fence on the STRUTS issue.

Originally posted by Andre Mermegas: Well here is a side thought, if you are worried about the minimal performance implications of using reflection with form beans how do you look at the performance hit from using a more heavyweight servlet based solution as compared to POJO struts actions where this is only 1 servlet per application?

I would say that it is the same either way. An Action is an Object and a Servlet is an Object. The server is still processing both. And neither Action nor Servlet should have major work done in them. Both should call other Objects to do the work and just deal with the Request and Response. Actions find forwards in an "extra" xml file and Servlets typically have the forwards hard coded in unless used as an init-param for the servlet as mentioned before. Personally, I think the debate should be does STRUTS make Web App development easier/faster and more maintanable. Performace won't have much to do with the differences between using STRUTS or not. Oh, and another point, using Form Beans is not limited to STRUTS either just as the Validator framework is not tied to STRUTS. STRUTS uses several Jakarta Commons API's and Form Beans can be used outside of STRUTS pretty easily if you choose to.

Rick Hightower

Author
Ranch Hand

Posts: 350

posted 12 years ago

Random thoughts on this topic: I think Struts has become the de facto standard. The horse has already left the barn. Most IDEs support it. For a while, five of the top ten best-selling Java books on Amazon were on Struts. You can write non-MVC code with Struts just as you can write non-OO code with Java. "Nothing is foolproof because fools are darn ingenious" My main argument for Struts is why reinvent the wheel. Struts seems to embrace not replace J2EE web application development. Reading the J2EE blueprint is like reading the design document for Struts. I believe there are some alternatives to Struts that are worth looking into like WebWork/XWork.

Struts is fairly light weight. You can mix and match other techniques. There are a lot of Struts plugins. Hmmmm.....

There are a lot of good points here and I tend to agree with most of the opinions. One thing that seems to not get a lot of mention is something that has been mentioned here already. An Action is basically the same as a Servlet. It is no more 'heavy', 'low level' or 'easy to code' that a servlet. Initially, when the Form Populator and Validator where not available as their own API (via Jakarta Commons), it was a 'plus' that STRUTS had. As mentioned, and like the TAGLIBS, they have either been broken out into their own API or are a seperate standard. I've said this in other threads before, I think STRUTS had some new functionality, but all of that has now been standardized and made available seperatly. Lastly, to hear that STRUTS makes web development easier and faster is just wrong in my opinion. You still have to understand the same concepts, plan for the same scenarios and do the same exact work. As stated before, it's just the tool to implement the design. If you take an honest look at what is actually done by the developer, it's all the same work. Wrap it in any 'framework' you want, it's all the same. STRUTS is just a buzzword. What could be done in J2EE/Blueprints can be done as easy in STRUTS, can be done as easy in JSF, can be done as easy in (fill in the buzzword of 2005 here). Same stuff, new day. As for IDE support, IDEs will support whatever they think will sell their product. Since they are all basically the same, if they think they can get an extra 2% of the market by supporting 'Jimbo's backwoods framework', they'll do it and promote it like the second coming. It's their job to give their customer base what is the latest buzz. They will most likely support JSF once it gains popularity. Simply because an IDE supports something does not make it the best way to go.

Rick Hightower

Author
Ranch Hand

Posts: 350

posted 12 years ago

Lastly, to hear that STRUTS makes web development easier and faster is just wrong in my opinion.

I've done projects without it and with it. It does make things easier. Form handling and error reporting. Add Tiles and the Validator framework + XDoclet and it gets even easier.

You still have to understand the same concepts, plan for the same scenarios and do the same exact work.

Nope some things are easer like form handling, error reporting, exception handling, etc.

As stated before, it's just the tool to implement the design. If you take an honest look at what is actually done by the developer, it's all the same work. Wrap it in any 'framework' you want, it's all the same.

I agree that Struts is a light weight framework and you still need to know the underlying concepts. But I don't agree that it buys you nothing.

Form handling, error reporting and tiles. Forms are about the most basic concept around. Tell me how a very basic concept is made so much easier by using the STRUTS model. Error reporting again is something that I am not too familiar with how it's done in STRUTS, but again it is something that has been a requirement long before web apps and it will be long after. Maybe this is nice if you don't have an idea of how to do this. However, if you are someone who is not sure how to handle errors, you probably should not be the person selecting the 'framework' for your project. Tiles are very much like the JSTL import tag. It's not a concept unique to STRUTS, STURTS is just the only API to call it 'Tiles'. The current system I am working on has several screens that will be common to many applications (select a state or a user). The functionality for those will be writtin as a series of EJBs with several Servlets/JSPs. The JSPs will be partial pages to allow the 'meat' of the page to always behave the same and get the data from the same location, however the surrounding or parent page is free to contain the parent app's look and feel. JSTLs import tag is going to allow us to do this.

There are ALWAYS more ways to do the same thing. STRUTS is not special, it's not unique. J2EE 'blueprints' and other 'frameworks' are not special or unique either. They all provide 98% of the same stuff, regardless of what it is called or what the interface looks like. In the end, it's the same functionality. As stated by Eric above, it's not really about the framework when it comes down to it, it's just a small tool in the overall picture.

Rick Hightower

Author
Ranch Hand

Posts: 350

posted 12 years ago

Form handling, error reporting and tiles. Forms are about the most basic concept around. Tell me how a very basic concept is made so much easier by using the STRUTS model.

Master detail, and validation are part of the framework. Why reinvent the wheel?

Error reporting again is something that I am not too familiar with how it's done in STRUTS (why comment on something you are not familiar with?), but again it is something that has been a requirement long before web apps and it will be long after. Maybe this is nice if you don't have an idea of how to do this. (been there done that, why do it again, its part of the framework)

Why reinvent the wheel?

However, if you are someone who is not sure how to handle errors, you probably should not be the person selecting the 'framework' for your project.

BTW Generally I feel personal attacks in a technical discussion implies a lack of professional ethics. This seems to be a common argument with some. Basically, it seems you are saying "if you don't agree with me you are stupid". If you think I am stupid then why respond at all.

Tiles are very much like the JSTL import tag. It's not a concept unique to STRUTS, STURTS is just the only API to call it 'Tiles'. The current system I am working on has several screens that will be common to many applications (select a state or a user).

Wow! Tiles is a much deeper rabbit hole than JSTL imports. You can do things with tiles that have no parrallel in anything I have seen: Definitions that extend definitions, Defaults, Building Visual components with JSP, and more.

There are ALWAYS more ways to do the same thing. STRUTS is not special, it's not unique. J2EE 'blueprints' and other 'frameworks' are not special or unique either. They all provide 98% of the same stuff, regardless of what it is called or what the interface looks like. In the end, it's the same functionality. As stated by Eric above, it's not really about the framework when it comes down to it, it's just a small tool in the overall picture.

I agree. There are some healthy alternatives to Struts. However, Struts has value--a lot of value.

Ken, Tiles is a deep rabbit hole. The Tiles framework makes creating reusable pages and visual components easier. Developers can build Web applications by assembling reusable tiles. You can use tiles as templates or as visual components. In some respects, the tile layout is like a display function. First you pass tile layout parameters to use. The parameters can be simple strings, beans, or tiles. The parameters become attributes to the tile and get stored in the tile's tile scope. For its part, the tile scope resembles page scope, and is less general than request scope. The tile scope lets the tile's user pass arguments (called attributes) to the tile. Definitions let you define default parameters for tiles. Definitions can be defined in JSP or XML. Definitions can extend other definitions similarly to how a class can extend another class. Moreover, definitions can override parts of the definition it is extending. The Tiles framework includes its own RequestProcessor to handle tile layouts as ActionForwards. Thus you can forward to a tile definition instead of a JSP if you install the Tiles plug-in. If you are using Struts but not Tiles, then you are not fully benefiting from Struts and likely repeat yourself unnecessarily. The Tiles framework makes creating reusable site layouts and visual components feasible.

The Tiles framework and architecture How to build and use a tile layout as a site template How to use tile definitions both in XML and JSP How to move objects in and out of tile scope How to work with attributes lists How to nest tiles How to build and use tile layouts as small visual components How to subclass a definition How to create a controller for a tile How to use a tile as an ActionForward

BTW Generally I feel personal attacks in a technical discussion implies a lack of professional ethics. This seems to be a common argument with some. Basically, it seems you are saying "if you don't agree with me you are stupid". If you think I am stupid then why respond at all.

My comment was in no way a personal attack. All I meant to say was that if there where someone who did not understand the concept, that person should probably not be the one making a group or company decision. You have provided many good points and agruements to support your views and am obviously in the position to make those decisions. Regardless of how my views may seem, I enjoy dicussions like this as they do sometimes bring up many things I was not aware of (like Tiles). If I offended you, I apoligize.

Ken Robinson

Ranch Hand

Posts: 101

posted 12 years ago

Tiles sounds like it does have a bit more than the JSTL import. I'll try to make time to look into it. It does appear that it is tied into STRUTS. If I decide I like Tiles, is it possible to use them outisde of STRUTS without using STRUTS for anything else?

Rick Hightower

Author
Ranch Hand

Posts: 350

posted 12 years ago

You can use Tiles outside of the Struts framework. (As well as the validator framework....) It is nicely integrated with Struts.

Okay. It just seemed like it. No harm. No foul. What are your thoughts on WebWork? I've checked it out and like it.

I tried to work with WebWork2 and I really liked the way it is structured. However, I had a problem getting their Taglibs to work correctly. I think I will wait for 2 to go Final and out of Beta then take a look at it again. However, it's still just another Framework,

Ken Robinson

Ranch Hand

Posts: 101

posted 12 years ago

Originally posted by Rick Hightower:

What are your thoughts on WebWork? I've checked it out and like it.

I'm almost set in my ways. I'm very confortable with Servlets and do not check out every framework that comes along. I've been working with straight Servlets before the .war file standard was around, so if I checked out every framework that has come around since then I'd still be evaluating frameworks. I haven't learned everything about Tiles that I should know yet, but what I've seen so far looks very good, especially since it can be used without STURTS being required. The fact that it can be standalone is a plus in my opinion. The app we are just about ready to start on will make very heavy use of JSP includes, so Tiles may be a very good tool for us to use. You have most likely convinced me of that already. Tiles look to be a great example of adding functionality that does not exist where most of what I've seen in many frameworks is either already around (just with a different look) or a very basic function that has been presented in a different way (ActionForms, ActionMappings). Hopefully Tiles are exactly what I want AND they eventually become an official standard, not just a popular defacto standard. I'd hate to have to do it one way on this project, an other on my next and yet an other after that.