wood burning stoves 2.0*
The moose likes Struts and the fly likes Why Jakarta Struts? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Why Jakarta Struts?" Watch "Why Jakarta Struts?" New topic
Author

Why Jakarta Struts?

Balamaci Serban
Ranch Hand

Joined: Mar 16, 2005
Posts: 49
I can't understand. I just took a short looked at some books that started talking about classes of the jakarta struts but not why one would use it, and i can;t really understand why it's used. Are many of the sites doing it? Do u consider it a necesity?From what i understand there is this model-view-controler. Model and view it's the database and the screeen output. Ok so the controle is the ActionServlet. All the pages name indiferent of what url the use requests, goes through the action servlet, which in turn forwards the request to a jsp file. But why? Is the only reason that you can set some variables and load some config files, like hibernate or log4j?

Is Struts that important? I come from a PHP background and i can't really understand it's use.
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Serban,

Is Struts that important? I come from a PHP background and i can't really understand it's use.

No it's actually not that important, or at least not right now. It was very important a while ago since it wasn�t anything else available. As you�ve noticed, the controller is one key part of Struts, but it is not the vital one. The most important thing that Struts does and what make it so crucial is that it provides a way to transform the http input in a set of standard classes. Without Struts one has to write all this spaghetti code all over the place. Imagine a form that submits a lot of parameters of different types. The next thing the application should do is to get through all these parameters and convert the strings to their right types, etc. and the same for displaying the resultsets. Pretty ugly though. Besides that, in my opinion Struts is only trouble. I tried once to convince one of the clients I worked for to replace Struts with a set of custom library classes that does exactly this conversion and forget about Struts. It didn�t work though, but if I would have to choose I�d rather spend couple of weeks and develop such classes (admitting I have no other option) rather than using Struts. Fortunately today developers have options and Spring is in my opinion a much better choice.
Regards.


I think, therefore I exist -- Rene Descartes
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

We have a forum engineered specifically for Struts questions. I am moving this thread there.


GenRocket - Experts at Building Test Data
Craig Jackson
Ranch Hand

Joined: Mar 19, 2002
Posts: 405
In my opinion. Struts provides a level of abstraction, that forces you to adhere to the Model-View-Controller architecture. Struts provides with you implementations of common tools to get you started, i.e. html tags, Controller servlets, struts-config.xml and property files etc.

It also recommends you to take advantages of these different levels abtraction by using DTO(data transfer objects) or VO(value objects), custom tags(instead of using scriplets), placing business, validation or database logic in Action classes or custom JavaBeans instead of JSP pages.

I admit in my opinion, struts is not easy to learn, but I did not choose to learn struts to become a guru. I wanted to learn struts because it gave me ideas on how to design certain aspects of a Web Application or GUI. Some aspects of Struts I like and some I don't. Some aspectes of Struts I will keep with me and some aspects of Strust I won't. Struts can be frustrating, because for lack of a better word, you have to connect to dots, just to get everything working.

But some things I do like, for example if I decide to change the name or names of display items, all I have to do is modify a properties file. If I want to change an implementation of the path "/login" all I have to do is change the config file. All of these changes are done without me actually changing the JSP pages.

Just my opinion.
Jason Menard
Sheriff

Joined: Nov 09, 2000
Posts: 6450
Originally posted by Valentin Tanase:
Hi Serban,

No it's actually not that important, or at least not right now. It was very important a while ago since it wasn�t anything else available. As you�ve noticed, the controller is one key part of Struts, but it is not the vital one. The most important thing that Struts does and what make it so crucial is that it provides a way to transform the http input in a set of standard classes. Without Struts one has to write all this spaghetti code all over the place. Imagine a form that submits a lot of parameters of different types. The next thing the application should do is to get through all these parameters and convert the strings to their right types, etc. and the same for displaying the resultsets. Pretty ugly though. Besides that, in my opinion Struts is only trouble. I tried once to convince one of the clients I worked for to replace Struts with a set of custom library classes that does exactly this conversion and forget about Struts. It didn�t work though, but if I would have to choose I�d rather spend couple of weeks and develop such classes (admitting I have no other option) rather than using Struts. Fortunately today developers have options and Spring is in my opinion a much better choice.
Regards.


Have you ever used Struts extensively? I ask because it seems odd to recommend replacing an MVC framework with a "set of custom library classes" for converting data to/from the request and the model. Your client made a very wise business decision from the sounds of it.

It sounds like your main point of contention is taking an extra step to move data from the string based http request or a an ActionFrom to a model of varying data types and vice versa. This is why I questioned your experience with the framework. This problem is trivial with the use of the BeanUtils library, which Struts itself uses for this kind of task. There is a good argument to be made against Spring's approach of populating the model directly from user input, although each to his own. In any event, if you have used Struts, it sounds like you are the victim of having worked on some poorly architected web app, which really isn't anything you can pin on a framework, Struts or otherwise.
[ July 18, 2005: Message edited by: Jason Menard ]
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Jason,

  • It�s hard for me to convince a dedicated soul that the object of his affection is maybe different than what s/he sees and feels. The problem with Struts is just that it is more trouble than it�s worth. I got the chance to work for a company that used a jsp, struts and ejbs architecture for each and every project they built. For small projects that only display several pages, I couldn�t really feel the benefit of Struts. We don�t dynamically change the application flow at run time and I cannot see the big advantage of maintaining the struts-config file, developing action classes, etc. For large projects it was even worse. First of all the same struts-config file was growing enormous and it was a big headache to maintain it. Latter on it was broke up in small files, but it still was difficult to figure out the application flow. Finally someone got the bright idea: let�s use XDoclet and generate the damn file. But it was already too late and people got tired of that project. And this is one point I�d like to make: there are plenty of books on Struts but none of them could really explain well how to use the damn thing.
  • The second thing I dislike about struts was the testing stuff. If one wants to do thing rights than s/he would like using tool like jcoverage make sure that s/he has almost 100% successful test coverage. Try that with Struts action classes and tell me that you still love Struts after that :-)
  • The third thing I dislike about Struts is the fact that it is really nice to use it if everything is develop and wired perfectly. But if for some reason something goes wrong then it will take long and frustrating hours to debug and figure out the problem.
  • The fourth thing I dislike about Struts is that it lacks good documentation. I got a really awful time trying to understand the validation part for example. I had a very simple business validation rule that I need to implement and because of the damn silly documentation they wrote I spent another long and frustrating hours trying to have it working.
  • But what I dislike most about Struts is the fact that people like you still believe it is a great product :-) J2EE guys should take a look at .NET and learn what friendly tools are.
  • Etc, etc, etc.

  • Please don�t take it personally they are just tools and nothing else. Is good we make a pretty decent living out of them and that should matter most :-)
    Regards.
    Jack Wiesenthaler
    Ranch Hand

    Joined: Jul 26, 2001
    Posts: 75
    May I offer a rebuttal to your arguments I have been using Struts for a while and absolutely love it.

    First off, if the struts-config file is getting too unwieldy then there are tools to manage it, Sruts Console is one, JDeveloper 10g has excellent visual support for struts-config, WSAD has something similar. You don't have to manually code the XML yourself, I surely don't...LOL!

    You're right, for small projects you may not NEED Struts or application of an MVC design pattern but what about scalability? Most projects are enhanced and features are added over time. At what point will you realize that you should've started with a good foundation to begin with?

    Regarding debugging, I have never found it easier to debug Struts apps. Separation of tiers means debugging is that much easier as problems are localized. Try debugging an old school app where the developer has a ton of embedded Java code within the HTML.. it's a pain!

    Regarding documentation, I have found the docs from Apache quite good. It may not be perfect but I've seen far worse. It is not to the level of MSDN (I am a longtime C++/Win32 developer also) but you must realize this is open source free software, given that perspective I find it pretty solid.

    Cheers mate,
    Kevin
    Valentin Tanase
    Ranch Hand

    Joined: Feb 17, 2005
    Posts: 704
    Hi Kevin,

    And thank you for your reply.
    I understand you love Struts and this is something that I can certainly understand, since we are all so different. But you see I really have to disagree with couple of points you made and scalability would be the first one of them. Now from how much I understand about scalability it doesn’t have much to do with Struts. I thought is something about the application capability to support a large number of concurrent users, without degrading the performances, but I might be wrong. However if that’s the case, then using Struts is not going to help much. Thinks like clustering plays a much more important role here. On the other hand if you mean kind of decoupling the layers in a web app, then you right, Struts does indeed to do that. But the question is how does it do it? You have the presentation layer, where Struts is coming with plenty of custom tags, then you have the action classes and you have the glue in between: the struts config file and of course plenty of other things in between: validations, internationalization, etc. Quite a lot of stuff isn’t it? Now I’d like you to look closer at the presentation layer and just for the argument sake compare that with the JSTL tags or even standard JSP tags. Don’t these look much simpler, although very flexible and powerful still? Do you find it nice to duplicate almost every standard html tag, having those struts:htm in place? Couldn’t you imagine something better in the presentation tier? Something simpler, more flexible and why not maybe little bit more original? As for the action classes they look pretty nice though and I really liked them for a while. Sure people often tend to abuse them, codding a lot of business logic in there, but this could be avoided through good designing. The problem starts when writing test cases for them. What options one has here? Either writing the infamous cactus test cases, or to mock the test data using tools like jmock. Either way one will hardly achieve a higher jcoverage rate and for sure will spend a lot of time trying to have the tests working. This of course for peoples that like to do things right. As for the others they can still find Struts very convenient. Regarding other out of the box Struts capabilities, what shall I say? Internationalization sounds great in theory, but nobody really needs it in practice. Validation ... for Christ sake the documentation is horrible.
    Another point you made it’s about debugging. I don’t find fair to compare this with and old school application. Not all non-Struts applications use spagetti code like that in the presentation tier. I know it sounds convenient for you, but my point is about debugging the server-side layers that Struts introduces. That’s another pain and what is more frustrating is that there are always problems with Struts applications. It seems that no matter how skillful one is, or how many Struts experience one has, changing Struts applications will result in getting Struts error. The reason is more than obvious to me: Struts is a complex, monolithic and cumbersome framework. I noticed this in practice too many times, for different projects and different people in order to believe otherwise.
    The last thing I’d like to mention is about the fact that many people use to think like you: well this is just an open source and it’s definitely worth for the money. Well again this is no argument whether the Struts is a solid product or not and I should ignore it. On the other hand I feel like I should mention that this is rather a dangerous way of thinking. Please don’t excuse a product’s quality only because it’s free and also don’t intend to supra evaluate it just because of the same reason. Does Struts have any value? Yes it surely has, but you know what: in my opinion it is far of being perfect or even a good product and for sure I know that the time will prove whether I’m right or wrong. Till then I rather like seeking other options.
    Regards.
    Jason Menard
    Sheriff

    Joined: Nov 09, 2000
    Posts: 6450
    It�s hard for me to convince a dedicated soul that the object of his affection is maybe different than what s/he sees and feels.

    By making a statement such as the above you are turning this discussion personal and intimating that I am not able to make objective professional decisions because of some mythical attachment to a particular framework. I have been using Struts successfully in several production systems since 2000. Before that I used either home brew MVC frameworks or just straight Servlets and/or JSP. Before that I was writing web applications in Perl. Struts is not the future, but it is the now. If you had read this post of mine, you would maybe have some kind of idea on where I feel web app frameworks are heading, and that I'm not attached to Struts in particular, rather I'm attached to using the best tool for the job.

    First of all the same struts-config file was growing enormous and it was a big headache to maintain it.

    Can't say I've ever had any problems with it, but then again xml config files don't bother me. You can't escape this by using most other frameworks as they all have their share of xml config files to maintain. Use XDoclet if it bothers you. You are right though in that it is not easy to determine app flow by looking at the struts-config file. Of course, that file was never meant to be a document for illustrating application flow.

    The second thing I dislike about struts was the testing stuff.

    It all comes down to how well you architect your application. If you maintain proper separation of responsibilities and design with testing in mind, unit testing your action classes with straight JUnit shouldn't be a problem. For integration testing though you would want to use cactus. Read this thread to get an idea of what a properly architected application is, using Struts and designed with testability in mind. The same holds for using any framework. If your app isn't well designed with testability in mind, you're going to have problems. Some frameworks, such as Spring, force you to use things like dependancy injection which makes testing easier. But just because a framework doesn't mandate such techniques doesn't mean you shouldn't be using them anyway to improve testability.

    Also, testing in-container processes is not easy regardless of the framework being used. A proper design will go a long way to mitigating this and minimizing your dependancy on in-container testing. You should be able to design such that just about all of your unit testing can be done out of container, and you only need to do in-container testing for integration tests. When it comes down to it though, you're going to have to use something like Cactus at some point for integration testing.

    But if for some reason something goes wrong then it will take long and frustrating hours to debug and figure out the problem.

    I've never had this problem where I could point at the framework as an excuse for difficulty in debugging. Again, a proper design and a complete suite of unit tests should minimize this. Problems that only occur in the container and don't show up in unit tests, assuming you've tried rigorously to duplicate the problem using out-of-container unit tests, are difficult to debug no matter what framework you are using, and Struts is not any different.

    The fourth thing I dislike about Struts is that it lacks good documentation.

    This isn't a complain one hears about Struts all that often. The documentation is generally considered pretty good. That doesn't mean its perfect, but it's better than most open source projects in my experience.

    I had a very simple business validation rule that I need to implement and because of the damn silly documentation they wrote I spent another long and frustrating hours trying to have it working.

    This goes back to what I have been trying to drive home about design. Business rules should not be validated in the control layer. Only user input, which is not the same thing as business rules, should be validated at this layer. Business rules need to be validated in the business layer, something you're probably not going to use Struts validation for (although you may use Commons Validator which Struts validation is based on).

    But what I dislike most about Struts is the fact that people like you still believe it is a great product :-) J2EE guys should take a look at .NET and learn what friendly tools are.

    Struts isn't a tool, it's an MVC framework. I think what you are claiming is so wonder ful about .NET is its IDE and tool set, which from what I understand do a better job at enabling drag-and-drop development, shielding the developer from having to understand much of what he is doing.

    Couldn�t you imagine something better in the presentation tier?

    So then use Velocity or JSF in the presentation tier. Struts integrates with them both. There's also nothing stopping you from using straight JSTL and JSP without using the Struts tags. The purpose of Struts is to provide the control framework. It also provides presentation, but the presentation part of the Struts framework is optional.

    The problem starts when writing test cases for them.

    Not really a problem. Again, it comes down to design. Mock objects are a wonderful thing.

    That�s another pain and what is more frustrating is that there are always problems with Struts applications. It seems that no matter how skillful one is, or how many Struts experience one has, changing Struts applications will result in getting Struts error.

    That may be your experience, but it's not mine. I've been using Struts for several years and do not frequently run into this problem as you describe it.

    Struts is the de facto standard for MVC web app frameworks. Is it perfect? Not at all. But it's going to be with us for some time now. I hear Tapestry is outstanding, but for some reason hasn't caught on to the point where managers are comfortable in going with it over Struts. As I mentioned in another thread, I suspect that within a couple of years we will be seeing web apps constructed using JSF in the presentation tier, Shale as the control layer, Spring providing the overall application framework (minus the MVC component), and an ORM framework such as Hibernate or EJB3 used for persistence.
    Valentin Tanase
    Ranch Hand

    Joined: Feb 17, 2005
    Posts: 704
    Hi Jason,

    By making a statement such as the above you are turning this discussion personal and intimating that I am not able to make objective professional decisions because of some mythical attachment to a particular framework.

    Far of me any such assumptions and I didn�t mean or intend to be rude in any ways. It was merely a joke and I do apologize if it offended or hurt your fillings in any ways. Not that I want to flatter you, but I really admire the way you write. Your writing is 100 times more qualitative than the framework you�re writing about :-) Half joke and half serious, but in my opinion this is one of the very serious reasons that made lot of products more successful than they really deserve to be. Strut is no exception and neither is (in my opinion) Apache SOAP or EJB for example. I did not say that Struts has no value whatsoever and personally I would be more than satisfied to develop such a framework myself, let�s say for personal use. However when we speak about commercial, professional and mission critical software I would really expect much, much more and looking from this perspective Struts is an underrated and under expectation piece of software. Just for the argument sake pick a professional deliverable software (not necessarily a framework) and make a comparison with Struts, from an user expectation standpoint. Think about Oracle for example, Visual Basic, Eclipse, etc. These in my opinion meet or exceed user expectations. Struts is far, far away from such expectation. The fact that it is free open source is not an excuse and this is another reason for its increasing popularity. Ironically this in my opinion is another reason that made things looking so badly today. If people would pay money for it they would obviously expect more and they would be willing to criticize and demand more. The free open source world sets an unfair competition with the non-free software vendors and therefore sometimes they could get away with their underrated software. It�s a shame that we often use more open source software than any particular vendor at all and it's even worse that sometimes there isn't anything to chose from. Aren�t the big guys capable of providing anything better? It�s hard to believe that this happens only because Mr. Jason Menard is a great speaker and he could make Spring looking glamorous :-) At the same time the big guys played a crucial role in defaming and almost bankrupting their own technologies and there is no surprise that "dazzling" technologies like J2EE needs to be refactored for the third time in only few years. You see now, in my opinion Struts is not just a framework; it is one little small and underrated wheel that contributed to all this mess :-)
    Regards.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Why Jakarta Struts?
     
    Similar Threads
    EMF + UML 2 Tools [model to java code]
    More on MVC
    Topic: Struts and MVC. Question: how usually are working you?
    Is my MVC design under RMI reasonable?
    Frameworks are Model 2?