Discussions

News: Java 5 extension framework for Struts released

  1. Java 5 extension framework for Struts released (68 messages)

    Strecks, a set of open source extensions to the Struts framework aimed at Java 5 users, has been released. Strecks (which stands for "Struts Extensions") is built on the existing Struts 1.2.x code base.

    Read Phil Zoio's article on Strecks, titled "Building on Struts for Java 5 Users".

    Strecks contains a range of features aimed to streamline the Struts programming model. Some key features include:
    • POJO action beans with no framework dependencies
    • action vs. controller separation. Request processing logic is encapsulated into Action controllers, simplifying action implementations
    • annotation-based dependency injection (typed request parameters, session attributes, Spring beans, and others)
    • annotation-based form validators (XML and code-free)
    • annotation-based data binding from form properties to domain model
    • annotations for additional per-field control over type conversion
    • simplified mechanisms to support navigation and redirecting after posts
    • pluggable navigation using annotations
    • pre- and post-action interceptors, with access to dependency resolved action beans as well as full runtime context
    For a more complete list, see http://strecks.sourceforge.net/features.php.

    Strecks 1.0-alpha-1 is available for download from http://strecks.sourceforge.net/.

    Threaded Messages (68)

  2. Framework for a framework[ Go to top ]

    :)
  3. Good God ![ Go to top ]

    More Struts ? When will it end ?

    Does this actually make it worth using ? I suppose I should find out for myself, eh ?

    Never mind, then.
  4. Good God ![ Go to top ]

    I will become useful, right after the merge with Webwork...
  5. In related news, developer releases extenstions for Borland's OWL (Object Windows Library) and then falls of pet dinosaur while downloading patch for Windows 3.1.

    Actually if I had to use Struts (and I could not afford to quit in disgust) and I was using Java 5 I would consider using something like this.

    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  6. You're FIRED![ Go to top ]

    Anyone that promotes the use of Struts on new projects should be fired.

    Anyone who writes new frameworks that build on top of such a flawed set of ideas should be emasculated.

    Die Struts! Die!

    It had its place. We learned our mistakes. Let's move on. Let anyone who looks back at the abomination of Struts be turned into a pillar of salt.

    Use Spring MVC, Tapestry, WebWork and if you must JSF. Don't use Struts 1.x!

    Struts = Legacy support only.

    Selected readings....
    Ruby On Rails: RoR the Square Turd.

    EJB 3: Boycott EJB3

    Thank you.

    Hadji Murad
    King of all Java Media
  7. You're FIRED![ Go to top ]

    While this is an understandable reaction, there are going to be plenty of developers that are stuck on long term projects using Struts, or in organizations that have standardized on using Struts and are slow to move on. In either case something like this is probably very helpful.

    Flashback to a few months ago when I released Stripes and there were people asking "why didn't you try and build this as an extension to Struts?". My reaction was (and still is) that Struts 1.x is too flawed to be a sound base for a next-generation framework. It is (even Struts 2.x will be based on WebWork, not Struts 1.x), and I think you'd be mad to start new projects on Struts 1.x if you had a choice.

    So I'm glad to see that someone has implemented something like this for those who are stuck on Struts. But for those who aren't, there are indeed better paths.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  8. why[ Go to top ]

    Can someone point out the flaws specifically?
  9. why[ Go to top ]

    Can someone point out the flaws specifically?

    Here's a starter list: http://stripes.mc4j.org/confluence/display/stripes/Stripes+vs.+Struts

    This points out some of the more painful issues that I had with Struts, and why I think they are issues. It would appear that Strecks solves some of these, and could/will solve more of them over time as it gets extended. But it'll never solve all of them unless it reimplements the whole of Struts ;)
  10. You're FIRED![ Go to top ]

    I'm glad to see that someone has implemented something like this for those who are stuck on Struts. But for those who aren't, there are indeed better paths.
    Tim, I am surprised you did not mention Stripes. Well, only in the signature :) Because if I used Java5 and was starting a new project I'd rather have considered something newer, leaner and meaner like Stripes than Struts Classic + some patchwork.
  11. You're FIRED![ Go to top ]

    Tim, I am surprised you did not mention Stripes. Well, only in the signature :) Because if I used Java5 and was starting a new project I'd rather have considered something newer, leaner and meaner like Stripes than Struts Classic + some patchwork.

    Thank you, it's great to hear you say that. Especially considering that I believe you were the first person to ask why Stripes wasn't a Struts extension! :)

    -Tim Fennell
    Stripes: Because web development should just be easier.
  12. You're FIRED![ Go to top ]

    Before I wrote this framework, I felt the same as you, although I wouldn't have expressed it quite as strongly. Seriously, the only reason I created Strecks was because I HAD to use Struts on a project. I added the features that I felt it needed to allow me to use a programming model that I was comfortable with, and afterwards, slipped in a few extra.

    I'm certainly not saying that this is the be all and end all of frameworks - it is still constrained by some of the Struts limitations, notably, slightly verbose configuration, less than optimal templating, and the absense of a component model (which also has its downsides). That being said, the web framework choice is still very hard - even now I would have difficulty picking out the right framework for my next project.

    I would argue a couple of points though. Firstly, many organisations are still "stuck" with Struts. Doing a Jobserve search right now, I got 269 jobs for Struts vs 45 for JSF and 16 for Tapestry. If this is your position and you're on Java 5, you can do worse than use it with Strecks.

    Secondly, Strecks at least narrows the gaps between Struts and other frameworks. Many of the architectural deficiencies become "internal implementation detail", so that they no longer negatively affect the application developer in the same way.
  13. Gradual upgrade[ Go to top ]

    Before I wrote this framework, I felt the same as you, although I wouldn't have expressed it quite as strongly. Seriously, the only reason I created Strecks was because I HAD to use Struts on a project. I added the features that I felt it needed to allow me to use a programming model that I was comfortable with, and afterwards, slipped in a few extra.I'm certainly not saying that this is the be all and end all of frameworks - it is still constrained by some of the Struts limitations, notably, slightly verbose configuration, less than optimal templating, and the absense of a component model (which also has its downsides). That being said, the web framework choice is still very hard - even now I would have difficulty picking out the right framework for my next project.I would argue a couple of points though. Firstly, many organisations are still "stuck" with Struts. Doing a Jobserve search right now, I got 269 jobs for Struts vs 45 for JSF and 16 for Tapestry. If this is your position and you're on Java 5, you can do worse than use it with Strecks. Secondly, Strecks at least narrows the gaps between Struts and other frameworks. Many of the architectural deficiencies become "internal implementation detail", so that they no longer negatively affect the application developer in the same way.

    I can see your need to support legacy apps. Why not do new use cases in the "new" framework (like JSF, Tapestry, etc.)? Then slowly replace your Struts parts over time. Some frameworks make web development a little less evil.

    I've worked on Struts apps where we did the new use cases in JSF, and where we replaced older pages with JSF when folks asked for a lot of new features. It does not have to be an all or nothing affair.

    I think you can work JSF (or Tapestry or WebWork or Spring MVC...) in slowly. My pick is JSF for a component oriented framework with much less XML conf than Struts.

    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  14. Quit admiring your own brown swirl[ Go to top ]

    Before I wrote this framework, I felt the same as you, although I wouldn't have expressed it quite as strongly. Seriously, the only reason I created Strecks was because I HAD to use Struts on a project. I added the features that I felt it needed to allow me to use a programming model that I was comfortable with, and afterwards, slipped in a few extra.I'm certainly not saying that this is the be all and end all of frameworks - it is still constrained by some of the Struts limitations, notably, slightly verbose configuration, less than optimal templating, and the absense of a component model (which also has its downsides). That being said, the web framework choice is still very hard - even now I would have difficulty picking out the right framework for my next project.I would argue a couple of points though. Firstly, many organisations are still "stuck" with Struts. Doing a Jobserve search right now, I got 269 jobs for Struts vs 45 for JSF and 16 for Tapestry. If this is your position and you're on Java 5, you can do worse than use it with Strecks. Secondly, Strecks at least narrows the gaps between Struts and other frameworks. Many of the architectural deficiencies become "internal implementation detail", so that they no longer negatively affect the application developer in the same way.

    No one has to do anything. Let me guess: "you were just following orders".

    The point it is you are not just doing legacy support for Struts, you are rellishing it. It is akin to deficating while in the hot tub and admiring your own brown swirl. What stops you from "using another framework on new use cases"?

    My dear friend, you enjoy your own stinking feces called Struts. You actually like it. I can tell.

    To do the simplest of tasks in Struts take an inordinate amount of XML configuration hell. Even JSF is much simpler than Struts.
  15. Thank you.[ Go to top ]

    Phil, I simply want to thank you for the work you are doing.

    IMHO Struts is still popular and it is used widely.

    e.g. We use Struts with XDoclets on RUNA WFE - OpenSource workflow environment with reach web front end.

    Because of XDoclets build time takes about 3 minutes on p4/1900 with 512RAM.
    Most of the build time ant spends on xdoclets (statless beans/hibernate/struts).
    Without XDoclets it take only 25 secs.

    Please, continue doing you job and don't listen to trolls shouting Struts is Dead. ;-)

    Regards,
    Vitaliy S
  16. Re: You're FIRED![ Go to top ]

    ... such a flawed set of ideas should be emasculated.Die Struts! Die!It had its place. We learned our mistakes. Let's move on. Let anyone who looks back at the abomination of Struts be turned into a pillar of salt....

    I think this is a bit on the extreme side... But more importantly, I think you underestimate the conservatism of the big company.

    One such company I worked for several years ago, had developed its own framework at the time when Struts was still a progressive idea. That framework involved copy-and-pasting an 8000 line servlet class (I am not exaggerating) and replacing significant bits of it every time you had to implement a new use case. That servlet extended a 5000 line long base class (again I am being quite literal here). Every suggestion of using Struts or any sort of command-pattern-based web framework, even an indoor developed one would kill your career prospects in an instant. Struts was dismissed on the basis of being open-source (oooh.... we can't trust them cowboys....) The indoor ones were dismissed just for the hell of it (ahhh... what do you know about software, our mainframe code we wrote 50 years ago is still in production.) I bet the guy who wrote it still believes it's fantastic and wonders why some interviewers never call back.

    I bet they are still using their monstrosity and successfully selling it to clients. I believe at the time it was actually cleared by Gartner group, who evaluated the dev methods and said this was good.

    So, presumably these guys, some years later are waking up to Struts. It's now a mature technology, almost as old as their grandchildren, and hence worth considering. After careful investigation of course. Lasting anything from 1 month to 6 years, depending on who proposed it.

    So, being pragmatic (aren't we all? :) Struts is way better than the rubbish some bloke will produce after 6 months of struggling following his newly completed UML design course and 70 years of CICS programming.

    So, embrace it! It's gonna be there for a long time, because it's not you and me that pay the big money. They want Struts, you give them Struts, and you keep reassuring them, because you do not want to witness the nervous breakdowns I have.

    And, well, evil??? come on, Tom Cruise is evil, Struts is benign........
  17. old hat is not necessarily evil[ Go to top ]

    You can easily condem the whole of Java web frameworks in the same way.

    People expect too much from struts. Write a hash for storing page flows and configure it in XML wow. I can do that in 20 mins.

    Struts is primarily a (very lightweight) view controlling framework and the fact that its so simple and stood the test of time for so long shows not only that the Java web framework space has been essentially devoid of ideas for a long time, but exhibits the inherent difficulty in dealing with the tension between admittedly limited client and server web technology.

    The scope of Spring and JSF, webworks is much more all encompassing and shouldnt even be compared to struts.

    Also, the lack of serious improvement in Java web frameworks reflects the general lack of innovation in the Java space for awhile.

    Pojo programming as its called will result in a whole slew of black box APIs that rely on byte code manip and therefore will be less likely to be truly open efforts and will result in somewhat proprietary looking solutions even if they are open source.

    POJO programming tells you one thing. OOP is essentially dead in Java, because overlaying of patterns in Java doesnt work well.

    The web space is going to change and if Ruby beats Java to the punch then so be it. If you quit in disgust then you should look at other non-java technologies. Even the frameworks you talk about havent come close to proving Java as the best Web development tool.
  18. old hat is not necessarily evil[ Go to top ]

    You can easily condem the whole of Java web frameworks in the same way. People expect too much from struts. Write a hash for storing page flows and configure it in XML wow. I can do that in 20 mins.Struts is primarily a (very lightweight) view controlling framework and the fact that its so simple and stood the test of time for so long shows not only that the Java web framework space has been essentially devoid of ideas for a long time, but exhibits the inherent difficulty in dealing with the tension between admittedly limited client and server web technology.The scope of Spring and JSF, webworks is much more all encompassing and shouldnt even be compared to struts.Also, the lack of serious improvement in Java web frameworks reflects the general lack of innovation in the Java space for awhile. Pojo programming as its called will result in a whole slew of black box APIs that rely on byte code manip and therefore will be less likely to be truly open efforts and will result in somewhat proprietary looking solutions even if they are open source.POJO programming tells you one thing. OOP is essentially dead in Java, because overlaying of patterns in Java doesnt work well.The web space is going to change and if Ruby beats Java to the punch then so be it. If you quit in disgust then you should look at other non-java technologies. Even the frameworks you talk about havent come close to proving Java as the best Web development tool.

    RoR is crap as it most of this post. Where to start... not sure. I fairly sure this is just a troll.
  19. old hat is not necessarily evil[ Go to top ]

    You can easily condem the whole of Java web frameworks in the same way. People expect too much from struts. Write a hash for storing page flows and configure it in XML wow. I can do that in 20 mins.Struts is primarily a (very lightweight) view controlling framework and the fact that its so simple and stood the test of time for so long shows not only that the Java web framework space has been essentially devoid of ideas for a long time, but exhibits the inherent difficulty in dealing with the tension between admittedly limited client and server web technology.The scope of Spring and JSF, webworks is much more all encompassing and shouldnt even be compared to struts.Also, the lack of serious improvement in Java web frameworks reflects the general lack of innovation in the Java space for awhile. Pojo programming as its called will result in a whole slew of black box APIs that rely on byte code manip and therefore will be less likely to be truly open efforts and will result in somewhat proprietary looking solutions even if they are open source.POJO programming tells you one thing. OOP is essentially dead in Java, because overlaying of patterns in Java doesnt work well.The web space is going to change and if Ruby beats Java to the punch then so be it. If you quit in disgust then you should look at other non-java technologies. Even the frameworks you talk about havent come close to proving Java as the best Web development tool.

    RoR is crap as it most of this post. Where to start... not sure. I am fairly sure this is just a troll.
  20. old hat is not necessarily evil[ Go to top ]

    YStruts is primarily a (very lightweight) view controlling framework and the fact that its so simple and stood the test of time for so long shows not only that the Java web framework space has been essentially devoid of ideas for a long time
    I wouldn't say that. I think there has been alot of ideas. Just not main stream.

    I would say that is an indication of the level of skills, abilities, knowlege and training of the majority of those involved in the IT industry (for lack of a more encompasing term). From management down to the interns.
    The web space is going to change
    Yep. Prepare for the javascript enabled browser to go away.
  21. old hat is not necessarily evil[ Go to top ]

    oh i love this very TSS specific comments. We have the standard "struts is dead, use SpringStripesWicketJSF" arguments. Then we have "all Frameworks are evil because they output html", which is an even more insance argument. So i will throw in my thoughts into this discussion:

    1. Yes, the struts architecture is not the best one. But many of the concerns will solved when webwork comes into play. So, all these "i have to use inheritance and that sucks" arguments will be non existant anytime soon. Apart from this fact, its just a MVC Framework with some emphasis von "VC". In regard to real applications, its only a minor part of the app.

    2. Applications do not suck because they rely on Struts or any other framework but because of badly programmed service layers and service implementations. I mean, the real code is not in the action classes or in any form class.

    3. Companies have some real invest in Struts because many employees are quite skilled in struts, whereas nearly nobody has enough people with skills in the latest and greatest MVC Framework. If i had to decide what to use, i would prefer using a 80% framework which everybody knows than a 100% framework which nobody is aware of. Its just an issue of economics.

    We used Struts for a new project started a year ago and we were aware of Spring-MVC and other toolings. But at the end we decided to use Struts (with a commercial Struts enhancement library) in combination with Spring DI/AOP and so far, it works pretty well.

    Back to the original Thread. I would love to test Strecks but i dont know if its a good idea to use something that will be outdated with the Struts/Webwork Merger.

    Marc
    http://www.logemann.org
  22. old hat is not necessarily evil[ Go to top ]

    Apart from this fact, its just a MVC Framework with some emphasis von "VC". In regard to real applications, its only a minor part of the app ... 3. Companies have some real invest in Struts because many employees are quite skilled in struts, whereas nearly nobody has enough people with skills in the latest and greatest MVC Framework.

    I find an inherent contradiction in these statements. For something that is only 20% of the application (which I more or less agree with), a team of developers shouldn't have to have a major investment in a technology. This was (and is) one of the critical issues with Struts that hampers productivity. There are so many wrinkles and little things it does poorly that you have to be an expert in all the workarounds to be productive.

    And if you spend 80% of your time dealing with the back end and not coding in Struts, it's hard to keep all these little things at the front of your mind. For my money, the #1 problem in the Java space is that developer's have learned to accept poor solutions. This is why we're mired in XML and XDoclet and frameworks that have to be worked around.

    As to having developers learn a whole new framework, this is something of a fallacy brought on by the fact that you have to "learn" Struts to be productive. New users on the Stripes list frequently comment that is was extremely easy to pick up and start being productive. One went as far as to state they he picked it because it was easier to have a more junior team be productive with it than with other frameworks. I'm sure similar posts are made to the WebWork, Tapestry, Wicket lists etc.

    The community needs to learn to be more demanding, and to settle less frequently. Just because it's free doesn't mean you should have low expectations :)

    -Tim Fennell
    Stripes: Because web development should just be easier
  23. Great comment![ Go to top ]

    Just because it's free doesn't mean you should have low expectations

    You should replace your tagline with this one :)
  24. Framework resume padding[ Go to top ]

    I am a lead in a shop and I will have to say that I spec'd out struts for a new project. Why?

    I have developers coming to me saying we need to use Ajax, we need to use JSF we need to use Spring and Tapestry!

    Im on board but these same people are folks who wrote a bunch of "struts" apps and coded the database calls and session management in the JSP pages themselves. Entire apps written in scriplets and javascript.

    10K JSPs OMG.

    Now this was not done with my oversight or approval over the last few years but, in your opinion should I let teams of developers who never got anywhere close to developing a struts app "correctly" as simple as that may be, push me into letting them develop in JSF, spring and whatever else?

    Um, no, I dont think so. First they have to stop violating separation of concerns. They havent BEGUN to experience the limitations of struts so why should I care about their resume padding desires?

    When their code is properly reviewed and they have competence building a solid' vanilla J2EE app then we can move on.

    Building layered solutions properly is a core competency.
    Using cool new technology is a luxury.
  25. Framework resume padding[ Go to top ]

    I am a lead in a shop and I will have to say that I spec'd out struts for a new project. Why? I have developers coming to me saying we need to use Ajax, we need to use JSF we need to use Spring and Tapestry!Im on board but these same people are folks who wrote a bunch of "struts" apps and coded the database calls and session management in the JSP pages themselves. Entire apps written in scriplets and javascript.10K JSPs OMG. Now this was not done with my oversight or approval over the last few years but, in your opinion should I let teams of developers who never got anywhere close to developing a struts app "correctly" as simple as that may be, push me into letting them develop in JSF, spring and whatever else?Um, no, I dont think so. First they have to stop violating separation of concerns. They havent BEGUN to experience the limitations of struts so why should I care about their resume padding desires?When their code is properly reviewed and they have competence building a solid' vanilla J2EE app then we can move on. Building layered solutions properly is a core competency.Using cool new technology is a luxury.

    I'd like to ammend my earlier statement about Struts.

    Struts should be used for legacy apps and retarded teams who have a retarded team lead.

    Who does JDBC calls in JDBC? What kind of process do you have?

    So you are punishing your current team by making them stick to the most unintuitvie garbage bin of XML settings.... Brilliant.

    You should be institutionalized. Team lead? HAH! You should not even be employed.
  26. Framework resume padding[ Go to top ]

    So youre suggesting that a team that doesnt understand what a factory is should use spring?

    I can see your involved in a persistent flame so whatever.

    Its not about punishing anyone its about, first do the best you can with something simple. Then run with something better.

    Thats the way people learn. Walk before you run (away from something you dont even understand)
  27. Struts as a legacy framework[ Go to top ]

    So why has Struts become "legacy"? It has increasingly been seen as flexible or powerful enough to be able to support a productive, elegant programming model. Many, obviously including yourself, regard Struts as a dead duck, too fundamentally flawed to do anything about.

    In my view, Strecks refutes this. Forget for a moment that it is based on Struts for a moment, and ask yourself what features that you would expect of a modern web framework are not present in Strecks or couldn't now be built on easily enough? (I've mentioned components and the templating mechanism - don't expect these to change, but if you can think of others, please let me know.)

    Strecks is not pursuing an ideal, but a is pragmatic solution which worked for me and will hopefully be helpful for others.
  28. The root cause of all evil[ Go to top ]

    I applaud Phil for trying to make lemonade out of lemons. I have reviewed his stuff and find it to be a useful advance from the status quo. But it is also true that Struts is evil.

    The root cause of all of this evil isn't the framework. Struts, JSF, WebWork, Tapestry, String MVC, etc are ALL FLAWED AND EVIL. The reason is that they all depend on HTML and browsers as the final user interface. Internet browsers are our problem. They force us to use silly hacks such as AJAX, Javascript, Flex, et al to give the users the experience that they really want.

    Java developers will never become truly effective until they can release themselves from the shackles of the web browser. Rich multi-treaded interfaces will become the norm. We think we still are stuck with the mindset that applicaitons must work over 56K modems. We have entered the broadband world. Let us take advantage of it.

    John Murray
    Sobetech
  29. The root cause of all evil[ Go to top ]

    Rich multi-treaded interfaces will become the norm. We think we still are stuck with the mindset that applicaitons must work over 56K modems. We have entered the broadband world. Let us take advantage of it.John MurraySobetech

    Did you ever take a look at what google and yahoo are doing nowadays? Oh, and that site you're looking at right now runs in... a browser (and was built with Tapestry)! How 90ties of The Server Site ;)
  30. The root cause of all evil[ Go to top ]

    We think we still are stuck with the mindset that applicaitons must work over 56K modems. We have entered the broadband world. Let us take advantage of it.

    iawtc Well said!
  31. The root cause of all evil[ Go to top ]

    I applaud Phil for trying to make lemonade out of lemons. I have reviewed his stuff and find it to be a useful advance from the status quo. But it is also true that Struts is evil. The root cause of all of this evil isn't the framework. Struts, JSF, WebWork, Tapestry, String MVC, etc are ALL FLAWED AND EVIL. The reason is that they all depend on HTML and browsers as the final user interface. Internet browsers are our problem. They force us to use silly hacks such as AJAX, Javascript, Flex, et al to give the users the experience that they really want.Java developers will never become truly effective until they can release themselves from the shackles of the web browser. Rich multi-treaded interfaces will become the norm. We think we still are stuck with the mindset that applicaitons must work over 56K modems. We have entered the broadband world. Let us take advantage of it.John MurraySobetech


    Thanks you for finally pointing this out, I constantly had this feeling for years now.
    The root of all evil simply is html and its limitations regarding realy user interfaces (limited set of controls, stateles protocols, hask like dhtml to resolve these issues
    which are broken beyound repair or unwillingness of the browser writers to repair them just for the sake of keeping compatibility)
    We have had working solutions to this problem for years now, applets, flash (if you must), xul etc...
    and yet it will probably take yet another microsoft we want to take over the world attemt to finally get rid of this absymality html really is fore real applications.
  32. HTML is not the problem[ Go to top ]

    HTML is not the problem. If it were, then the Web wouldn't be as popular as it is today. Users don't care about AJAX particularly in the broadband world today. What I see as the problem is that despite the popularity of broadband, pages are slower than they were 8 years ago without necessarily being more useable, and development is more complicated than it was 8 years ago, without the problem (Creating and populating HTML web pages) changing much in that time. Essentially we as a development community are going backwards. From my persepective, the inmates are running the asylumn.
  33. HTML is not the problem[ Go to top ]

    HTML is not the problem. If it were, then the Web wouldn't be as popular as it is today.

    Smoking doesn't cause health risks, otherwise it wouldn't be as popular as it is today.
    What I see as the problem is that despite the popularity of broadband, pages are slower than they were 8 years ago without necessarily being more useable, and development is more complicated than it was 8 years ago, without the problem (Creating and populating HTML web pages) changing much in that time.

    Hmmm...eight years.... Was CSS well supported eight years ago (is it now)? That's a change (for the better).
    Essentially we as a development community are going backwards.

    Yup. GMail is slower than the old netscape communicator mail client operating over a 14k dial-up connection on a 486 (or a 68040 if you used Macs, I used both).

    We wanted to prove we could create client-side software more bloated than MS fat-client software and still have it require a big server to run. We created AJAX. (Actually, I had nothing to do with it, and I don't know if you did, either, but someone did...).

    I mean really...client side Java GUIs are too slow...let's use JavaScript and XML! Those are some light-weight, high-performance technologies.
    From my persepective, the inmates are running the asylumn.

    Inmates would try to make their lives easier and give themselves lots of happy-juice. Big corporate interests along with a few open-source egos are running the show. And by "running" I mean engaging in evasive manuevers to "outwit" the competition.
  34. Another set of extensions[ Go to top ]

    A couple months ago, I released Sprout, which is also a set of extensions for Struts, but focuses more on making legacy app updates more palatable. At its core, it's a set of annotations that effectively replace struts-config.xml.

    seth
  35. Very Grateful..[ Go to top ]

    Thanks for this extension. There are some of us who prefer to stick with Struts, rather than trying to convince our bosses to switch everything over to the framework-of-the-week. (Can you say "Flaky"?)
  36. Silver Bullets[ Go to top ]

    These frameworks only serve to complicate the typical Java web developers life.

    Servlets/JSPs and JDBC (when written properly) are all that is needed for 90% of web applications.

    Most of these modern 'frameworks' are just reflection based abominations that move complexity from the code to an xml file, or annotations (which only serve to complicate code).

    I just dont get it.
  37. Silver Bullets[ Go to top ]

    These frameworks only serve to complicate the typical Java web developers life.Servlets/JSPs and JDBC (when written properly) are all that is needed for 90% of web applications.Most of these modern 'frameworks' are just reflection based abominations that move complexity from the code to an xml file, or annotations (which only serve to complicate code).I just dont get it.

    I agree somewhat with that last statement. But not with your first. Put like that, there is hardly a difference with developing your sites with Java or PHP or Coldfusion or whatever. Though that works fine for a fair ammount of sites, in many cases that's just a bad idea for reasons of maintainability, cooping with complexity, etc.

    The way the larger share of frameworks seem to want reduce complexity is to minimize the need to write Java code. They are feature/ solution driven whereas a better focus on concepts would imo be better. After all, the ability to conceptualize your problem space is what makes object orientation a strong proposition in the first place.
  38. Silver Bullets[ Go to top ]

    These frameworks only serve to complicate the typical Java web developers life.Servlets/JSPs and JDBC (when written properly) are all that is needed for 90% of web applications.Most of these modern 'frameworks' are just reflection based abominations that move complexity from the code to an xml file, or annotations (which only serve to complicate code).I just dont get it.

    I think statements like these are generally the result of either having been burned by a couple of shoddy frameworks or have just having never found a framework that fit right and added sufficient value.

    Similarly: apache and some old-school c-skills are all that's needed to build a web application. It doesn't mean it's the most effecient or most maintainable way to do it. If you were building a desktop GUI, would you use Swing? MFC? Or hand code everything with drawing primitives?

    Have you tried a more modern framework like Wicket? Or Stripes? You might find that you like the productivity boost and the focus on writing code instead of configuration...

    -Tim Fennell
    Stripes: Because web development should just be easier
  39. performance[ Go to top ]

    Currently we're reviewing framework that can help us to develop faster without ignore scalability and performance. What i mean faster is, if i can develop screen by drag and drop, so it's will be more easier to newbie in java area. That's correct to get new developer learn struts it really difficult, that happen to me too. It's a nice job to introducte Strecks and Stripes, both is quite good, may be Strecks will increase productivity, cause less line of code.
    Stripes also a good idea, it's easy to understand great job Tim, may be if my team look at it, they will comment why not try move to Stripes :). But is there any benchmark or stress test for these framework scalability and performance ? or how about jsf or webwork

    Currently we're using struts for our system that have more than 2 million transaction per day for financial transaction.
    Just my curious, if we use annotation is it will decrease the performance because the server need to process it again ? or using doclet is better cause it's by code generated during compiling the source code :)

    sorry for my bad english
  40. performance[ Go to top ]

    Just my curious, if we use annotation is it will decrease the performance because the server need to process it again ? or using doclet is better cause it's by code generated during compiling the source code :)sorry for my bad english

    Re Strecks, I haven't done any benchmarking, but would not expect a significant or even noticeable loss of performance from using Strecks vs plain Struts.

    The annotations are inspected when the form/action is used for the first time, and not subsequently.

    There is some extra reflection. For example, a form property to domain model operation will use two reflective method calls, one to call a getter and another to call a setter. Each injected dependency will result in one reflective setter operation.

    Also, action beans are instantiated per request. Theoretically, this adds overhead but in the grand scheme of things the effect would be neglible.

    One area of possible performance improvement - using annotation-based validation and data binding should only require at most one type conversion per form property. Using plain Struts, the type conversion can be duplicated, especially if individual form properties apply multiple validations.
  41. Silver Bullets[ Go to top ]

    These frameworks only serve to complicate the typical Java web developers life.Servlets/JSPs and JDBC (when written properly) are all that is needed for 90% of web applications.Most of these modern 'frameworks' are just reflection based abominations that move complexity from the code to an xml file, or annotations (which only serve to complicate code).I just dont get it.
    I think statements like these are generally the result of either having been burned by a couple of shoddy frameworks or have just having never found a framework that fit right and added sufficient value.Similarly: apache and some old-school c-skills are all that's needed to build a web application. It doesn't mean it's the most effecient or most maintainable way to do it. If you were building a desktop GUI, would you use Swing? MFC? Or hand code everything with drawing primitives?Have you tried a more modern framework like Wicket? Or Stripes? You might find that you like the productivity boost and the focus on writing code instead of configuration...-Tim FennellStripes: Because web development should just be easier

    1) Configuration done well automates and removes most coding
    2) JSP is an abomination, and the reason there are so many java web frameworks is that Sun released such poor web technologies as the basis of J2EE
    3) Server-based object-heavy web frameworks are dead. AJAX/DWR and static or minimally generated HTML pages using AJAX are far simpler and more powerful. Practically eliminates an entire processing tier from your architecture, as long as your data services are properly secured.
  42. Silver Bullets[ Go to top ]

    1) Configuration done well automates and removes most coding

    Ok, but where is it done well? And why is configuration superior to coding? You could just as easily state that coding done right removes the need for most configuration.
    2) JSP is an abomination, and the reason there are so many java web frameworks is that Sun released such poor web technologies as the basis of J2EE

    Have you used JSP since the 1.x era? JSP is not without it's problems, but 2.0 JSP spec is a significant improvement, and it's now quite a viable view technology. I have my issues with it, but it works.
    3) Server-based object-heavy web frameworks are dead. AJAX/DWR and static or minimally generated HTML pages using AJAX are far simpler and more powerful. Practically eliminates an entire processing tier from your architecture, as long as your data services are properly secured.

    I don't agree with this either, but everyone is entitled to their opinion. I'm not sure what you'd lump into the 'object-heavy web frameworks' bucket, or how you have determined their death, but I'd be interested to hear. AJAX is interesting, but like many things before it, I don't believe it's going to completely replace all that went before.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  43. Silver Bullets[ Go to top ]

    1) Configuration done well automates and removes most coding
    Ok, but where is it done well? And why is configuration superior to coding? You could just as easily state that coding done right removes the need for most configuration.
    2) JSP is an abomination, and the reason there are so many java web frameworks is that Sun released such poor web technologies as the basis of J2EE
    Have you used JSP since the 1.x era? JSP is not without it's problems, but 2.0 JSP spec is a significant improvement, and it's now quite a viable view technology. I have my issues with it, but it works.
    3) Server-based object-heavy web frameworks are dead. AJAX/DWR and static or minimally generated HTML pages using AJAX are far simpler and more powerful. Practically eliminates an entire processing tier from your architecture, as long as your data services are properly secured.
    I don't agree with this either, but everyone is entitled to their opinion. I'm not sure what you'd lump into the 'object-heavy web frameworks' bucket, or how you have determined their death, but I'd be interested to hear. AJAX is interesting, but like many things before it, I don't believe it's going to completely replace all that went before.-Tim FennellStripes: Because web development should just be easier.

    I don't have immense familiarity with Spring beyond what I've read on it and a hello world app, but Spring seems to be very popular, and seems largely to prefer configuration over coding. I do agree that Struts had too much pointless configuration, largely I only ever used struts for a core controller base and various useful packages like resources.

    JSP: #1 complaint: pointless limits on the EL that Velocity, OGNL, and others easily implemented, a complete wasting of the power of Java reflection. Far too many annoying characters (especially ones that need the shift key) to type, laugh if you want but <c:set value="${somekey}"/> requires pressing the SHIFT key eight times for twenty or so characters. Tag libraries are clunky, don't implement core looping and control abilities, have an annoying programmatic interface, and the custom tag libraries out there are difficult to play with and extend. Just a bad mechanism. Finally, the inclusion statements for classes and taglibs are pointless obfuscated.

    I've implemented some AJAX stuff using DWR. While Javascript is an immense pain in the butt, using it is still much cleaner with writing a data access layer, using DWR to do all the marshalling and access control (another example of the good kind of configuration), and having the web browser's current page control ist own navigation, state, and data requests. AJAX definitely has a way to go, and it will lead eventually to something besides Javascript
  44. Silver Bullet Carl[ Go to top ]

    AJAX definitely has a way to go, and it will lead eventually to something besides Javascript

    So let's see here....AJAX, which is really only accessed via Javascript in the browser, typically in the form of new XMLHttpRequest() or by some wrapping framework (prototype.js comes to mind) is going to lead to something besides javascript? How do you make that connection? Also, what the heck does it matter?

    Would it be correct to say that since java provides java.net.HttpURLConnection and javax.net.ssl.HttpsURLConnection that it will lead to something besides Java? Must I thus despise Java because I can use these objects and this 'something besides Java' does not exist today?
  45. Silver Bullet Carl[ Go to top ]

    AJAX definitely has a way to go, and it will lead eventually to something besides Javascript
    So let's see here....AJAX, which is really only accessed via Javascript in the browser, typically in the form of new XMLHttpRequest() or by some wrapping framework (prototype.js comes to mind) is going to lead to something besides javascript? How do you make that connection? Also, what the heck does it matter?Would it be correct to say that since java provides java.net.HttpURLConnection and javax.net.ssl.HttpsURLConnection that it will lead to something besides Java? Must I thus despise Java because I can use these objects and this 'something besides Java' does not exist today?

    Point is, troll, that if you have a durable, secured web data access tier, as you inadvertantly pointed out, you can switch to other client-side techs. If you have a server-heavy HTML generation tier, you're far more bound to Web Browsers than with DWR or AJAX approaches.

    So you're being a shithead, but you're also proving my point. So thanks.
  46. Angry Silver Bullet Carl[ Go to top ]

    Your point is not proven and you sound quite angry. One simple remedy you might consider in the future is to avoid taking any paying work for developing web applications. Instead, you might look into finding work developing thick clients in either .NET or the Java-Swing or SWT - maybe you'll find that you are happier and no longer need to pine away hoping for something besides javascript...

    Cheers and happy programming!
  47. Angry Silver Bullet Carl[ Go to top ]

    Your point is not proven and you sound quite angry. One simple remedy you might consider in the future is to avoid taking any paying work for developing web applications. Instead, you might look into finding work developing thick clients in either .NET or the Java-Swing or SWT - maybe you'll find that you are happier and no longer need to pine away hoping for something besides javascript...Cheers and happy programming!
  48. Angry Silver Bullet Carl[ Go to top ]

    Oh, that wasn't a bit nice, you have made me very angry, verrry angry indeed!
  49. Silver Bullets[ Go to top ]

    ... laugh if you want but <c:set value="${somekey}"/> requires pressing the SHIFT key eight times for twenty or so characters.

    Now you laugh if you want, but I can type <c:set value="${somekey}"/> with only 5 pushes on the shift. See, the key is to not release it between "${. You'll thank me later. :)
  50. Silver Bullets[ Go to top ]

    These frameworks only serve to complicate the typical Java web developers life.

    Is Java the silver bullet? You don't get to decide how developers perceive automation.
  51. Cold Servers[ Go to top ]

    Everything comes back to servlet engine either by XML or tags
    or anything you name it with respect to a web application. There should be a separate Struts Engine or JSP Engine within the Webserver with completely a new tier over Servelets. Struts or JSP shouldnt use Servlet engine and should have its own engine. I have worked on struts framework for a while and its very painful to create a bunch of class files. Later i developed a separate Tool to create these files for me. Now i'll try this annotations based struts to see whether my work is simplified. If you are interested you can try out this at http://estruts.sourceforge.net
  52. Dont't forget to check Beehive[ Go to top ]

    Apache Beehive also makes a great framework, replacing Struts pains by interesting concepts (and also eliminating the darned struts-config madness).
  53. Great work![ Go to top ]

    Checked them out quickly. Both Strecks and Stripes sound good. They are certainly useful.

    Do I like Struts? Hell, no. The question is does Struts suck that bad?

    We all heard about "Every time you use Struts, God kills another kitten".

    Actually, Struts is not that bad. Otherwise, thousands of web applications, especially those in the vertical of financial application, would not be built on top of Struts successfully. It is simple and working.

    For me, the new generation web application frmaeworks - Webwork, Spring MVC are all still model 2 web application framework. It does not solve the funtamental issue (stateless http) completely. JFS is something fundermentally different. However, the down side is that tons of state information has to be stored somewhere. A lot of web applications I touched prefer to stay as stateless as possible. With JFS, it's not an option anymore.

    One thing Struts family frameworks do well is that they only concentrate on solving one thing - the controller layer. Not sure about what I mean? Try to download webwork and play with it. It is trying to do too much - hibernate integration, spring integration, webwork IOC, ajax (DWR) integration, etc. Not mention that the documentation/tutorial sucks. With 900 pages tutorial, only 3 hello world kind sample applications.

    Struts has the biggest user base. It's much esier to get help and find workarounds. Again, is Struts great? Hell not. Is any other web framework that much better than Struts at this point? No, absolutely not. Just want to be rational here.
  54. Comparison to Beehive?[ Go to top ]

    Am I wrong to see some overlap with Beehive, is there any and what does the developer of Strecks think about Beehive (although Beehive broader aiming at some other things as well like components and WS's right?)?
  55. Comparison to Beehive?[ Go to top ]

    Am I wrong to see some overlap with Beehive, is there any and what does the developer of Strecks think about Beehive (although Beehive broader aiming at some other things as well like components and WS's right?)?

    I'm not too familiar with Beehive, but my understanding is also that it is quite a lot broader in scope than Strecks, introducing some new concepts and artifacts and UI additions.

    From the application developer's viewpoint, Strecks seems to be less of a departure from the traditional Struts programming model. With Strecks you are still working with actions and forms, albeit in quite a different way, and you still work with the same set of config files and tags.
  56. This thread about Struts spawned by the "Strecks" release is one of the best discussions I have seen on TSS in quite some time now.

    Probably one of the biggest problems in using a framework like Struts is due to people in general not separating concerns very well in the implementation of their systems. This problem can obviously appear when using any framework (and it does). Another issue that pops up a lot in the game of using a framework is the problem of 'available knowledge' for a particular framework. Does your team have the knowledge to use a particular framework effectively? If not, is their sufficient knowledge/experience available on the Internet or in books? - or even better yet, as part of the framework documentation?

    The other 'real' factor that comes into play in choosing and using frameworks is that it's just impractical (in business terms) to throw away existing knowledge and skill in order to achieve some kind of architectural 'purity' or to use some clever new feature promised by competing frameworks. Businesses won't succeed by being up-to-date w.r.t. the latest architectural fads; they will fail however by jumping on the latest framework bandwagon and not figuring out how to use a framework or combo of frameworks correctly.

    So basically, I think the combination of incorrect usage/knowledge (of Struts or any framework), and business-costs of framework selection and usage are the key things to keep in mind any time you think about jumping on a bandwagon. It's been my experience that choosing full-stack frameworks for all layers in an MVC system tends to be a brittle choice, whereas combining different framework components for the different concerns of a system tends to yield the most architecturally flexible solutions.
  57. All of a sudden everyone hates struts?[ Go to top ]

    I've never seen so much struts bashing. From my experience, almost any web framework can be very effective as long as the code is well formed and separated.
    When I don't feel the need to create components, is there really that much reason for me to move to something newer like JSF? And also, for most simple apps, do you find component devlopment to be time-effective? I've started a new application with JSF and I'm finding the component model to limit me more than it helps. For instance, the round-about way they recommend we go after session objects, and there seems to be no way to make a request go through the framework without a JSF post (in struts you can just click a link that points to /viewForm.do, in JSF the model has to be built every time).

    What I read about Stripes sounds good, but working in a large company, I think I'd receive some strange looks from management if I recommended anything off the beaten path.
  58. From my experience, almost any web framework can be very effective as long as the code is well formed and separated.

    When you use frameworks, languages, etc you'll get the flaws of that technology with it. It is perfectly possible to write working applications with Struts, but there are much better alternatives nowadays.
    When I don't feel the need to create components, is there really that much reason for me to move to something newer like JSF? And also, for most simple apps, do you find component devlopment to be time-effective? I've started a new application with JSF and I'm finding the component model to limit me more than it helps.

    There are several interpretations of how components should look. I think in general a component model is helpful, especially for more complex user interfaces. If you have a document oriented/ largely readonly site, you won't gain that much. But if you have to cope with more complexity, larger teams, etc, a good component model helps you cope. Whether JSF has a good support for components is another discussion which has been discussed on many posts on this site.
    What I read about Stripes sounds good, but working in a large company, I think I'd receive some strange looks from management if I recommended anything off the beaten path.

    Funny to read comments like that over and over again.

    1) This is a technical forum where we hopefully discuss technical merits. I don't care about your manager.

    2) Do you /think/ he'll give you the funny look, or did you actually experience that? If he does give you that look and he's not a technician, he's a lousy manager. What does he know? He's got you to figure out the tech stuff. There are many attributes on which you can rate technologies. Whether one is mainstream or not is one of the least useful in my book.

    3) Do you sit in the basement? I mean, when you evaluate stuff and believe you found something useful... you don't want to stand up for it? Are you tired of your job and just take the easiest route (listening to whatever your manager says) or are you a passionate employee that wants the best for his projects and company?
  59. Funny to read comments like that over and over again.1) This is a technical forum where we hopefully discuss technical merits. I don't care about your manager.2) Do you /think/ he'll give you the funny look, or did you actually experience that? If he does give you that look and he's not a technician, he's a lousy manager. What does he know? He's got you to figure out the tech stuff. There are many attributes on which you can rate technologies. Whether one is mainstream or not is one of the least useful in my book.3) Do you sit in the basement? I mean, when you evaluate stuff and believe you found something useful... you don't want to stand up for it? Are you tired of your job and just take the easiest route (listening to whatever your manager says) or are you a passionate employee that wants the best for his projects and company?
    They way I phrased my statement, I probably deserved some badgering. However, I realize that this is a technical forum, but I am unable to make decisions based solely on the technical merit of a framework... for good reasons. We don't have access to a bunch of developers who are willing and able to quickly switch between frameworks. I think it's fun to jump around, but others take longer to learn. If in a short period of time, stripes gets kicked to the curb, all the developers who learned it will be upset. The longer a framework sticks around, the better it is for us. And also, the more web apps we have coded with the same framework, the easier it is to have different people mainain them.

    To relate this to the main thread, right now the only framework the people I work with know is Struts. I could either have them use this extension and get some new benefits, or I could take a gamble on picking a new framework for them to learn - and right now I'm just not sure which one I'd pick.
  60. However, I realize that this is a technical forum, but I am unable to make decisions based solely on the technical merit of a framework... for good reasons. We don't have access to a bunch of developers who are willing and able to quickly switch between frameworks. I think it's fun to jump around, but others take longer to learn. If in a short period of time, stripes gets kicked to the curb, all the developers who learned it will be upset. The longer a framework sticks around, the better it is for us. And also, the more web apps we have coded with the same framework, the easier it is to have different people mainain them.To relate this to the main thread, right now the only framework the people I work with know is Struts. I could either have them use this extension and get some new benefits, or I could take a gamble on picking a new framework for them to learn - and right now I'm just not sure which one I'd pick.

    It wasn' meant hateful, I understand where you are coming from :) I just try to do my part in fighting 'common sense' arguments. Arguments like popularity etc /should/ be taken into account, and sometimes your political reality imposes to they are stronger weighted than you would have liked from a technical point of view. But unfortunately these arguments sound so 'management sane' that they are often used to stop any further discussion. I like to fight that as I believe it stops progress.
  61. I've never seen so much struts bashing. From my experience, almost any web framework can be very effective as long as the code is well formed and separated.When I don't feel the need to create components, is there really that much reason for me to move to something newer like JSF?

    Well the stateful component model was sufficient to make me switch from Struts. Now where I work we have several standard UI components. And since the logic is encapsulated in the component there is no more endless JSP pages with c:if and c:choose. Thank god.

    Add to that a web specialized managed-bean facility, which avoid you the stupid null pointer exceptions you often get if you are not careful when you use Struts nested tag library.

    Add to that the merge of Action and ActionForm in a business helper object, ie the backing bean which allows you to handle component events. And if you need some application level events, well there is always Struts Shale.

    Add more powerful message facilities, especially the possibility to bind a particular message to a given component.

    Add an application controller that is not monolithic, ie the Lifecycle and makes it very easy to plug in your own implementations.

    And also, for most simple apps, do you find component devlopment to be time-effective? I've started a new application with JSF and I'm finding the component model to limit me more than it helps.

    Yup! Tons faster! What are you main complains? It is so easy to contruct your UI and bind it to backing beans.
    For instance, the round-about way they recommend we go after session objects, and there seems to be no way to make a request go through the framework without a JSF post (in struts you can just click a link that points to /viewForm.do, in JSF the model has to be built every time)

    Not true. There is a discussion about this topic on the MyFaces mailing list. Search for the topic "JSF can handle GET requests *just as easily* as other frameworks".
  62. By the way, if you want to understand was JSF is really doing under the cover, I have just found out this little application. Looks promising
    http://www.jroller.com/page/cagataycivici?entry=rise_of_the_faces_trace

    And also if you use JSP please take a look at Facelets or Shale Clay. JSP is really what's make JSF hard, get ride of it and it become so simple.
  63. Not true. There is a discussion about this topic on the MyFaces mailing list. Search for the topic "JSF can handle GET requests *just as easily* as other frameworks".

    There are two things, JSF cannot really handle form submits over get easily due to the state transfers it has to handle.
    Normal stateful links are not a huge problem (as Craig pointed out in the list quite verbosely ;-) )
    you always can use an outputlink and link in the parameters from the managed bean facilities. No extension needed outputlinks are part of the normal JSF base component set.
    In the end if you have a jsf page you have way less html and javascript clutter than with other frameworks, because of the heavy encapsulation the components normally do (also the less verbose layouting is very nice)
    As for form gets, there is no real way to do them, due to the state handling, theoretically you could do it for 1-2 component forms practically no one has implemented a gettable form yet, and it does not make sense, given all the state transfers done and the browser limitations on url size.
  64. Not true. There is a discussion about this topic on the MyFaces mailing list. Search for the topic "JSF can handle GET requests *just as easily* as other frameworks".
    There are two things, JSF cannot really handle form submits over get easily due to the state transfers it has to handle.Normal stateful links are not a huge problem (as Craig pointed out in the list quite verbosely ;-) )you always can use an outputlink and link in the parameters from the managed bean facilities. No extension needed outputlinks are part of the normal JSF base component set. In the end if you have a jsf page you have way less html and javascript clutter than with other frameworks, because of the heavy encapsulation the components normally do (also the less verbose layouting is very nice)As for form gets, there is no real way to do them, due to the state handling, theoretically you could do it for 1-2 component forms practically no one has implemented a gettable form yet, and it does not make sense, given all the state transfers done and the browser limitations on url size.

    Yeah but I agree with Craig on this one. A get should be an idempotent request used only to support bookmarks and should not carry form parameters. It's save you from a lot of problems when you don't go that way so I am quite happy it isn't supported out-of-the-box by JSF. I remember how much headaches GET form submit used to give me when I was developping Struts applications and I add to respect some predefined URLs.
  65. Tons faster! What are you main complains? It is so easy to contruct your UI and bind it to backing beans.
    He meant probably the component programming ui model, which results in a lot of code artefacts and boilerplate code for a single component.
    There are ways to get rid of it for normal web applications, you always can revert to facelets for your own components.
    I think in the long run introducing something similar to the core JSF will be inevitable. The current component API is in my opinion one of the weakest points of JSF. Way too much boilerplate code, way too hard to program for.
    Normal app developers usually should not do them anyway, but once you have to do them, and you have time constraints, look for alternatives, which exist (Shale Clay and Facelets)
  66. Tons faster! What are you main complains? It is so easy to contruct your UI and bind it to backing beans.
    He meant probably the component programming ui model, which results in a lot of code artefacts and boilerplate code for a single component.There are ways to get rid of it for normal web applications, you always can revert to facelets for your own components.I think in the long run introducing something similar to the core JSF will be inevitable. The current component API is in my opinion one of the weakest points of JSF. Way too much boilerplate code, way too hard to program for.Normal app developers usually should not do them anyway, but once you have to do them, and you have time constraints, look for alternatives, which exist (Shale Clay and Facelets)

    I agree there is a lot of boiler plate code to produce each time when you write a new component. I think an Apache commons-jsf library could fix the problem for the moment. But the component API indeed needs some works (especially markup based renderers) but there are workarounds(facelets, Shale Clay, ADF Maven 2 plugin) and I really think the main architecture of JSF is excellent.
  67. Tons faster! What are you main complains? It is so easy to contruct your UI and bind it to backing beans.
    He meant probably the component programming ui model, which results in a lot of code artefacts and boilerplate code for a single component.There are ways to get rid of it for normal web applications, you always can revert to facelets for your own components.I think in the long run introducing something similar to the core JSF will be inevitable. The current component API is in my opinion one of the weakest points of JSF. Way too much boilerplate code, way too hard to program for.Normal app developers usually should not do them anyway, but once you have to do them, and you have time constraints, look for alternatives, which exist (Shale Clay and Facelets)
    I agree there is a lot of boiler plate code to produce each time when you write a new component. I think an Apache commons-jsf library could fix the problem for the moment. But the component API indeed needs some works (especially markup based renderers) but there are workarounds(facelets, Shale Clay, ADF Maven 2 plugin) and I really think the main architecture of JSF is excellent.

    I think the problem is twofold, first the boilerplate code you have to do for jsp, which is inevitable, secondly the somewhat cumbersome responsewriter api, third the boilerplate code for the components (mostly getter and setters with a little bit of lightweight serialisation)

    to get rid of jsp means 1/3rd less boilerplate code, to move the boilerplate component stuff to sane overridable defaults or annotations would be 1/4th, to move the rendering to something saner to implement like velocity also would reduce the boilerplate code for another 1/3rd.

    There is a huge need for something more lightweight in this area. I will give an example 10 lines of combined html and javascript resultet recently in about 200 lines, 3 classes and 2 xml entries of component code.
    In velocity the same would have been done in about 5 lines of java and about 10 lines of markup.
  68. Tons faster! What are you main complains? It is so easy to contruct your UI and bind it to backing beans.
    He meant probably the component programming ui model, which results in a lot of code artefacts and boilerplate code for a single component.There are ways to get rid of it for normal web applications, you always can revert to facelets for your own components.I think in the long run introducing something similar to the core JSF will be inevitable. The current component API is in my opinion one of the weakest points of JSF. Way too much boilerplate code, way too hard to program for.Normal app developers usually should not do them anyway, but once you have to do them, and you have time constraints, look for alternatives, which exist (Shale Clay and Facelets)
    I agree there is a lot of boiler plate code to produce each time when you write a new component. I think an Apache commons-jsf library could fix the problem for the moment. But the component API indeed needs some works (especially markup based renderers) but there are workarounds(facelets, Shale Clay, ADF Maven 2 plugin) and I really think the main architecture of JSF is excellent.
    I think the problem is twofold, first the boilerplate code you have to do for jsp, which is inevitable, secondly the somewhat cumbersome responsewriter api, third the boilerplate code for the components (mostly getter and setters with a little bit of lightweight serialisation)to get rid of jsp means 1/3rd less boilerplate code, to move the boilerplate component stuff to sane overridable defaults or annotations would be 1/4th, to move the rendering to something saner to implement like velocity also would reduce the boilerplate code for another 1/3rd.There is a huge need for something more lightweight in this area. I will give an example 10 lines of combined html and javascript resultet recently in about 200 lines, 3 classes and 2 xml entries of component code.In velocity the same would have been done in about 5 lines of java and about 10 lines of markup.

    Totally agree with you. This is why I use a velocity based renderer which is quite simple for the moment but make my life so much easier :) Using the ResponseWriter give you a lot of unreadable Java code.
  69. All of a sudden everyone hates struts?[ Go to top ]

    I've never seen so much struts bashing. From my experience, almost any web framework can be very effective as long as the code is well formed and separated.When I don't feel the need to create components, is there really that much reason for me to move to something newer like JSF? And also, for most simple apps, do you find component devlopment to be time-effective? I've started a new application with JSF and I'm finding the component model to limit me more than it helps. For instance, the round-about way they recommend we go after session objects, and there seems to be no way to make a request go through the framework without a JSF post (in struts you can just click a link that points to /viewForm.do, in JSF the model has to be built every time).What I read about Stripes sounds good, but working in a large company, I think I'd receive some strange looks from management if I recommended anything off the beaten path.

    Actually I cam rather late to Struts, I have used Turbine, Jetspeed, Raw JSP, JSP with taglibs and a few in house frameworks in the past. Then JSF which came closest to the way I think a UI lib has to be defined (on the webside of things) and then I had to work on a Struts project. To sum it up, I did not like it. It was the most cumbersome of all frameworks I had to use. Given the fact that I did not mind xml configuration (in fact the way JSF handles it is quite natural) but in struts it felt clumsy. Way too much xml configuration for things which can be mapped implicitely, the naming was so abstract that things did not make sense.
    And then at one point learning it, I thought to myself. Is that all, xml bloat without doing anything more than what turbine and others do with 1/10th of the configuration with a little bit of having implicit mechanisms.
    Sorry to say it, Struts in its 1.2 incarnation was a dead end road, and why it became a standard is beyound me. I admire the work Craig has put into JSF, but Struts, only if I get paid for it, I would never touch it out of free will.
    Webobjects, Turbine, Tapestry, JSF anything else but no more Struts.

    Sorry for the rant here, Struts works, but that is all there is. And there is better than Struts. In the end the main problem is html anyway not the webframeworks which try to push a square in a round hole and try to fit perfectly in there. HTML simply has deficiencies once it comes down to raw user interface handling, people expect from a modern application.