Discussions

News: TSS asks: Is Struts going away?

  1. TSS asks: Is Struts going away? (206 messages)

    On About.com, a poll asks what framework developers will use on their next application, and the poll leaves Struts off; at conferences, developers focus on frameworks like JSF, Wicket, Tapestry, Spring-MVC, or WebWork. Struts gets little mention except as an archaic technology, with the occasional article reminding us that it's out there. So what's your feeling about Struts?

    Are we likely to still be discussing the "new Struts-killer" framework in two years? Are books still going to refer to Struts as a primary comparison point? Is Struts even something that needs to be replaced, considering all the work that's going into replacing it?

    If so, what should replace it and why? The JCP has apparently blessed JSF (and for understandable reasons); is that enough for you to switch to JSF for future development?

    Threaded Messages (206)

  2. As the author of the poll says, about.com's polls are limited to only 5 choices, so he picked those that he considered the most interesting.
  3. Sure, but the reigning framework would merit one of those choices, in my opinion. Assuming a change will occur (or is occurring) doesn't seem like a wise assumption.
  4. It sure seems like there are still a bunch of employers hiring for Struts if you check the job sites.
  5. Employers hiring for Struts?[ Go to top ]

    It sure seems like there are still a bunch of employers hiring for Struts if you check the job sites.

    There are still plenty of employers hiring for COBOL, VB, C, but I would not bet my career on any of these.

    The problem with Struts is that its founder and chief architect has found the new love (JSF/Shale)

    The remaining project team has been slow to play catch up
    with other very healthy and innovative web frameworks.

    There is a fragmentation within frameworks itself - Shale, Ti, Overdrive efforts that are not all inclusive.

    Vendors do not like it. They are all JSF focused.

    Open source developers (that I know) do not like it because it is not as productive or innovative compared to other competing favorites (http://raibledesigns.com/page/rd?anchor=oscon_spring_mvc_vs_webwork).

    Developers in general (that I know) do not like it because it has been known as outsourcing friendly framework.
    How many times I've heard this: "architect on shore, send to developers to implement in Struts offshore". Every outsourcing (J2EE) vendor I know boasts about its Struts development capacities.

    So if you are hired as a Struts developer today - you may not be there tomorrow.
  6. Employers hiring for Struts?[ Go to top ]

    So if you are hired as a Struts developer today - you may not be there tomorrow.

    True, but so what? A lot of the competing frameworks are actually claiming they are easier to handle, not harder, using simpler concepts, better abstraction.... anything that does not at least SEEM to be offshoring/outsourcing friendly would surely not stand too large a chance anyway....
  7. Employers hiring for Struts?[ Go to top ]

    So if you are hired as a Struts developer today - you may not be there tomorrow.
    True, but so what? A lot of the competing frameworks are actually claiming they are easier to handle, not harder, using simpler concepts, better abstraction.... anything that does not at least SEEM to be offshoring/outsourcing friendly would surely not stand too large a chance anyway....
    It is "offshore friendly", cause they know it. With these "new" frameworks, it is less likely that they are knowledgeable enough for someone to be willing to hand it over to them.

    The real advantage of these other frameworks is that they lower costs and make it less advantageous to offshore things.
  8. Employers hiring for Struts?[ Go to top ]

    It is "offshore friendly", cause they know it. With these "new" frameworks, it is less likely that they are knowledgeable enough for someone to be willing to hand it over to them.The real advantage of these other frameworks is that they lower costs and make it less advantageous to offshore things.

    In my view there is nothing like "offshore friendly" or "less advantage to offshore", developers will just learn any framework their employers want. We don't know anything about Struts when it was required for a product, we just learnt it and gone to the extent of customising the Struts for the product(Now more than 500 clients in US are using it and most of them are Fortune 500 companies).The client was damn impressed. The same thing happened with JSF and the samething will happen for other frameworks, I worked for a offshore development center for this product in India. May be, developers in Offshore development centers like in India are slow to try new frameworks, because the employers didnt ask them to do so, but not incompetent at learning those frameworks and using them right way.
  9. Employers hiring for Struts?[ Go to top ]

    send to developers to implement in Struts offshore.

    Let them have it. I hope all maintenance regarding struts goes offshore so i never have to smell it anymore. And anyone who still uses it for new projects, what I can say without being bashy. Nothing.
  10. Considering the wide spread of technologies and frameworks enabling a certain amount of abstraction... I see only 2 possibilities for developers who want to leverage their coding skills on Java language :

    1/ create a new language from scratch with new paradigms.. and a lot of buzzwords !
    2/ consider doing more composing and less coding...
    3/ go working for a Top 5 software vendor to source code the tools that 95% of the developers will use to create application!

    nowadays great products help you to build applications almost without a single line of code.. so the real challenge is ideology/results ???
  11. You're basically talking about wizard code. Wizard code is great if it matches what you want to do.

    Which happens about 1% of the time once you actually get into requirements.

    Most coding time in systems I've been hasn't been consumed by the rote generation stuff that wizards excel at. Most is the difficult stuff that is hard to figure out, much less have a wizard do it.
  12. You're basically talking about wizard code. Wizard code is great if it matches what you want to do.Which happens about 1% of the time once you actually get into requirements. Most coding time in systems I've been hasn't been consumed by the rote generation stuff that wizards excel at. Most is the difficult stuff that is hard to figure out, much less have a wizard do it.

    Exactly. I think coding IS the future. The success of Ruby and Phython as alternatives for 'full blown J2EE' probably has to do with the fact that they are more code-oriented. Declarative programming is ok in some cases, but a lot of times it forces you in a mould that's only a subset of what can be done with a 3GL language.

    Remember 4GL? My professors told me I should better keep away from 3GL programming as that would be lower education stuff pretty soon. Well, the contrairy happened. The future is in code, but in smart code, like RoR. Combine good APIs/ frameworks to really boost your productivity, but without loosing the flexibility and maintainability that 3GL gives you.
  13. Exactly. I think coding IS the future. The success of Ruby and Phython as alternatives for 'full blown J2EE' probably has to do with the fact that they are more code-oriented.

    Even though I am starting to move some of my development towards these languages, I find it hard to take seriously a statement like this. Right now, there is no evidence that these languages are generally successful as alternatives for J2EE. I'm not saying that they won't be at some point in the future, but they certainly aren't now. Just take a look at the job market for server-side development. The demand for Ruby and Python is insignificant compared to more established web languages like PHP, and that is minor compared to .NET and certainly compared to J2EE.
  14. Even though I am starting to move some of my development towards these languages, I find it hard to take seriously a statement like this. Right now, there is no evidence that these languages are generally successful as alternatives for J2EE. I'm not saying that they won't be at some point in the future, but they certainly aren't now. Just take a look at the job market for server-side development. The demand for Ruby and Python is insignificant compared to more established web languages like PHP, and that is minor compared to .NET and certainly compared to J2EE.

    We were talking about the future, right? Struts is still the de-facto standard, but can hardly be called 'the future'. Furthermore, I targetted full J2EE like we have seen in the past few years. Yes a large part of the community moved to EJB2 and the likes, which makes it a leading technology. But I think it this point, you won't find that many people that still think EJB2 is that great/ the future. And an easy measure for this is of course the popularity of Spring and Hibernate.

    Anyone who has been around in IT has seen the recurring 'code is not the future argument' pattern. The ideal of a lot of people seem to be to deliver a non-code centric tool set so that applications can be build by cheaper personel in less time, ideally by 'business people'. Again: rember how 4GL would change the world? Or MDA? Or... well, time and time again it shows that even though some of the repetitive tasks can be automated fairly good, the most productive way of developing software is still code centric. The recent increased attention for languages like Ruby must be partly due to the fact that a lot of people think that Java/ J2EE development got bloated too much and is in the way of their productivity. I don't nescesarily share that opinion yet, but it sure is interesting to see /who/ are making the shift to those languages. And I'm more interested in what some of the leading figures think than in information like the current market penetration of language x.

    Oh, and about
    Right now, there is no evidence that these languages are generally successful as alternatives for J2EE
    .Indeed, right now. We'll see in five years, yes? I still very vividly remember how I had to defend 'toy language' Java in favor of C++. Wasn't that long ago. I'm not saying those language /will be/ more used then but they /might be/.

    Lastely. Job market blah, blah, blah. I am really the only one here that influences the kind of technology to be used for projects? Does it really have to be your manager that decides on language/ framework x based on some quasi-objective info like market penetration and job offers?
  15. I'm not saying those language /will be/ more used then but they /might be/.

    Fair enough. But that hardly justifies saying that Ruby and Python are successful as J2EE replacements now, which I assumed was what you are trying to say.
    Lastely. Job market blah, blah, blah

    How else are you going to define success? I agree it is hard to do, but I can't think of any alternative.
  16. Speaking of Polls being fair[ Go to top ]

    Sure, but the reigning framework would merit one of those choices, in my opinion. Assuming a change will occur (or is occurring) doesn't seem like a wise assumption.

    Speaking of fairness in polls.... I seem to remember a certain TSS poll at the last symposium in Las Vegas.

    What web framework do you use? Spring MVC, Struts, WebWork or Tapestry. JSF was left off the list. Which is some sort of sick joke because I am sure it would have come into second place.

    The only poll that really matters is the Dice poll (http://www.dice.com). Who is hiring for said skills. In this poll, JSF comes second to Struts. Which is not bad considering, that most of the other frameworks have not been around that long.

    Struts is still the Java Web Framework behemoth.
  17. Unlikely...[ Go to top ]

    ...especially as this topic was posted on your homepage just above one entitled "Java.net Article on Using Ajax with Struts".
  18. Unlikely...[ Go to top ]

    Indeed, thus the reference to the "occasional article." They're certainly less common than they used to be, but people are still writing about Struts.
  19. leveraging html experts[ Go to top ]

    We are currently a struts shop, but looking for alternatives.

    JSF (at least w/ the JSP renderer), struts, and others that leverage JSP tags for rendering seem to come up short, in that it seems once in the hands of programmers, the html can never again be edited by non-java coders.
    J2EE once preached that there would be j2ee roles - "deployer" "page designer", etc. JSF and other frameworks seem to be forgetting the fact that non coders should be able to edit pages w/out understanding a great deal of java.

    Tapestry seems to be the only framework that addresses this, so
    we will likely be developing with it in future apps we write.
  20. leveraging html experts[ Go to top ]

    JSF and other frameworks seem to be forgetting the fact that non coders should be able to edit pages w/out understanding a great deal of java. Tapestry seems to be the only framework that addresses this, so we will likely be developing with it in future apps we write.

    Then I invite you to take also a look at Wicket as it has an even stronger separation between HTML and java.

    Anyhow, using either Tapestry or Wicket will make your life more fun.
  21. leveraging html experts[ Go to top ]

    Then I invite you to take also a look at Wicket as it has an even stronger separation between HTML and java.Anyhow, using either Tapestry or Wicket will make your life more fun.

    FUN, literally :-D
  22. Why is it funny?[ Go to top ]

    Why is it funny?

    I think pagedbased/componentbased event driven webframeworks are a lot easier to develop than model2 based systems like Struts because thinking in pages feels a lot more natural.

    The company I work for designed a small pagebased layer on top of maverick and are developing goes a lot quicker and the java code is a lot less complex.
  23. leveraging html experts[ Go to top ]

    We are currently a struts shop, but looking for alternatives.JSF (at least w/ the JSP renderer), struts, and others that leverage JSP tags for rendering seem to come up short, in that it seems once in the hands of programmers, the html can never again be edited by non-java coders.J2EE once preached that there would be j2ee roles - "deployer" "page designer", etc. JSF and other frameworks seem to be forgetting the fact that non coders should be able to edit pages w/out understanding a great deal of java. Tapestry seems to be the only framework that addresses this, so we will likely be developing with it in future apps we write.
  24. leveraging html experts[ Go to top ]

    We are currently a struts shop, but looking for alternatives.JSF (at least w/ the JSP renderer), struts, and others that leverage JSP tags for rendering seem to come up short, in that it seems once in the hands of programmers, the html can never again be edited by non-java coders.J2EE once preached that there would be j2ee roles - "deployer" "page designer", etc. JSF and other frameworks seem to be forgetting the fact that non coders should be able to edit pages w/out understanding a great deal of java. Tapestry seems to be the only framework that addresses this, so we will likely be developing with it in future apps we write.

    Apologies for blank reply. Browser problems.

    I have never really understood this 'can't be edited by html developers or non-java coders' problem. If there was embedded Java code that could seriously confuse an HTML editor, I could understand the issue, but JSF is yet more simply tags. What is required from designers is markup around those tags and stylesheets to control presentation. There is nothing to stop these being changed after JSF tags are included. Am I missing something?
  25. leveraging html experts[ Go to top ]

    I have never really understood this 'can't be edited by html developers or non-java coders' problem. If there was embedded Java code that could seriously confuse an HTML editor, I could understand the issue, but JSF is yet more simply tags. What is required from designers is markup around those tags and stylesheets to control presentation. There is nothing to stop these being changed after JSF tags are included. Am I missing something?
    Designers edit plain HTML and JSP tags is not a problem, but they need to preview stuff in browser without web server. I am not sure JSF code is browser friendly.
  26. leveraging html experts[ Go to top ]

    I have never really understood this 'can't be edited by html developers or non-java coders' problem.
    Designers edit plain HTML and JSP tags is not a problem, but they need to preview stuff in browser without web server. I am not sure JSF code is browser friendly.

    The most efficient way to work with designers IMO is to let them make the layout in their favorite image editor (photoshop?) and let us use the separate images. Developers can make clean HTML/JSP/CSS/Whatever this way and pagedesigners don't have to be bothered with anything else then what they are good at and like to do.
  27. leveraging html experts[ Go to top ]

    JSF (at least w/ the JSP renderer), struts, and others that leverage JSP tags for rendering seem to come up short, in that it seems once in the hands of programmers, the html can never again be edited by non-java coders.

    The problem you are highlighting has great impact. But I can remember web designers being capable of editing my JSP code (using Struts) without great trouble. I was not aware of the designers' skill in programming, though.
    Tapestry seems to be the only framework that addresses this, so we will likely be developing with it in future apps we write.

    Makes me want to try it. I am already using Hivemind (also from HLS) on serverside, so I wonder what is so wonderful about Tapestry.
  28. leveraging html experts[ Go to top ]

    Logicless HTML templates is also one of the major features of RIFE. We however don't only limit our templates to XML languages, but we allow invisible or compact markup of any text content.

    By creating a bidirectional template engine, templates become real design blueprints and are used for the providing building blocks that will constitute your final layout. Any HTML, XHTML, Javascript, ... expertise or tools can continue to be applied as before.

    More information here:
    http://rifers.org/features/bidirectional+multi-format+template+engine
  29. XHTML pages for JSF[ Go to top ]

    Check out Facelets at https://facelets.dev.java.net/

    It gives you a similar page development paradigm to Tapestry (it uses XHTML files), but the engine behind it is JSF.
  30. leveraging html experts[ Go to top ]

    JSF and other frameworks seem to be forgetting the fact that non coders should be able to edit pages w/out understanding a great deal of java.
    Not that I necessarily disagree with you, but why "non coders should be able to edit pages"? Can a non-coder easily edit resources of a windows application? Can a non-coder change appearance, behavior of the application or, say, add a new window? Why do you think this should be essential to a web app?
  31. leveraging html experts[ Go to top ]

    We are currently a struts shop, but looking for alternatives.JSF (at least w/ the JSP renderer), struts, and others that leverage JSP tags for rendering seem to come up short, in that it seems once in the hands of programmers, the html can never again be edited by non-java coders.J2EE once preached that there would be j2ee roles - "deployer" "page designer", etc. JSF and other frameworks seem to be forgetting the fact that non coders should be able to edit pages w/out understanding a great deal of java. Tapestry seems to be the only framework that addresses this, so we will likely be developing with it in future apps we write.

    Wicket actually does an even better job with that: there's NO scripting at all in the markup files.
  32. would love to switch but...[ Go to top ]

    I would love to switch to Spring-MVC (using a lot of other Spring components too) but i somehow didnt manage to convince the people at www.common-controls.com to create Spring-MVC bindings for their framework which actually sits on top of Struts. IMO they have the most complete tag library for business web applications available.
  33. would love to switch but...[ Go to top ]

    We are planning Spring bindings for Coldtags suite:
    http://www.servletsuite.com/jsp.htm
  34. TSS asks: Is Struts going away?[ Go to top ]

    While I don't think they should have left it off the poll, I won't be using it on new projects. It, like COBOL and VB and ..., won't be going away anytime soon and it would be nice to see how many are going to, in the face of everything, still use it on new projects.
  35. Should Struts be going away?[ Go to top ]

    Struts provided a lot of clarity and benefit back in the day when people were building web applications using straight servlets and JSPs. It provided a standard model that helped teams make more cohesive applications.

    But that's no longer enough. Newer frameworks (hell, WebWork isn't even that much newer than Struts, just more up to date) and cropping up that are significantly more productive, result in cleaner easier to maintain code bases, and are architecturally superior to Struts. But Struts still gets a lot of airplay because it was the first major framework and is still the biggest. I think it's damaging to the community that the Struts team talk about how Struts is still vibrant, growing etc. Without fundamental design changes (which would break backwards compatibility, something the Struts team seems unwilling to do) I don't think Struts can ever compare favorably to newer frameworks. Efforts like Shale and Ti allow the community to believe that Struts is moving on, but they are not evolutions of Struts Classic, simply new frameworks under the Struts brand name.

    In short, I think that it would be hugely helpful for the various Struts teams and subteams to come out and state what the plan is for Struts Classic, what the roadmaps are for Struts sub-projects and exactly how they relate to the original. For example, is Ti going to be a complete push-button upgrade for classic projects? Or is the effort going to be similar to a migration to another action-oriented framework?

    Note: my opinion is probably biased, see sig for details.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  36. Should Struts be going away?[ Go to top ]

    In short, I think that it would be hugely helpful for the various Struts teams and subteams to come out and state what the plan is for Struts Classic, what the roadmaps are for Struts sub-projects and exactly how they relate to the original.

    I believe we have

    * http://struts.apache.org/struts-core/roadmap.html
    * http://struts.apache.org/shale/index.html
    * http://wiki.apache.org/struts/StrutsTi

    Since Struts 1.2, we've made modest but strategic changes, to be released with Struts Core 1.3

    * http://struts.apache.org/struts-core/userGuide/release-notes.html

    As it stands, we're still plodding along on the same roadmap we set down 18 months ago. The work proceeds slowly, but it does proceed, and we continue to add new committers to project, to help us keep things moving along.

    * http://struts.apache.org/announce.html

    HTH, Ted.
  37. To develop what?[ Go to top ]

    Most of the development now is RiA/Web 2.0, not HTML anymore.

    We use what we learned from Struts, the MVC. I sort of do SwingX/JDNC in a Struts way:
    Action/Listneres
    Model to unit test that talks to remote DAO.
    and Presntation/Render/JPanel.

    The question should have been if you were to write an html application, what framework would you use, and then it be Struts + JSTL.
    .V
  38. I think that says it all. Components are the only way to go.
  39. We're using Tapestry and are very impressed by the ideas it proposes. It definitely aims to make developers more productive - and I agree that components are the way to go.

    The fact that JSF needs of specialized IDEs or plugins makes me lose interest in it - the code they generate make me "wast e time". Correct me on this point if I'm wrong.

    Struts is too "request oriented" and Tapestry ir more "object (or maybe component) oriented" - in that sense, solving the problem of web applications with Tapestry is easier, I think.

    I find Tapestry very straightforward, once you understand the way it should be applied.

    Also, I still have to see what Tapestry 4 offers. It would be great to hear comments on the latest release.
  40. The fact that JSF needs of specialized IDEs or plugins makes me lose interest in it - the code they generate make me "wast e time". Correct me on this point if I'm wrong.

    This is one of the most common misconceptions about JSF. While there are plenty of good tools (and I generally tell people to use them), using them isn't a requirement, and all of them don't generate code. I've been working with JSF for quite some time now, and I usually don't use WYSIWYG tools or code generation. Also, with things like Facelets, you can get Tapestry-style template support and avoid JSPs altogether.

    Kito D. Mann (kmann at virtua dot com)
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info

    Are you using JSF in a project? Send your story to trenches at jsfcentral dot com, and you could get your story published and win a free copy of JavaServer Faces in Action!
  41. The fact that JSF needs of specialized IDEs or plugins makes me lose interest in it - the code they generate make me "wast e time". Correct me on this point if I'm wrong.
    This is one of the most common misconceptions about JSF. While there are plenty of good tools (and I generally tell people to use them), using them isn't a requirement, and all of them don't generate code. I've been working with JSF for quite some time now, and I usually don't use WYSIWYG tools or code generation. Also, with things like Facelets, you can get Tapestry-style template support and avoid JSPs altogether.Kito D. Mann (kmann at virtua dot com)Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and infoAre you using JSF in a project? Send your story to trenches at jsfcentral dot com, and you could get your story published and win a free copy of JavaServer Faces in Action!

    +1

    You can use WYSIWYG tools with Struts or for that matter Swing. No Struts or Swing developer I know uses them. This is the same with JSF. The tools exists, but no developer I know uses them (except maybe to do some prototyping). I can't stand the stuff these tools generate.

    I wrote a series of articles explaining my thoughts on this subject.

    http://www-128.ibm.com/developerworks/java/library/j-jsf1/
    http://www-128.ibm.com/developerworks/java/library/j-jsf2/
    http://www-128.ibm.com/developerworks/java/library/j-jsf3/
    http://www-128.ibm.com/developerworks/java/library/j-jsf4/
  42. I think I'll probably join the "Switched to Tapestry and Never going back" camp. We have developed our first Tapestry app and it's a big step off from Struts, but there are just so many reasons why Tapestry is right.

    Unfair to call Struts a "half-framework", it was never intended to be a app container. It is a very nice way to wrap up servlets, and take some of the scriptleting out of JSPs. It does all that well and is still a useful framework for small web apps.

    The problems with Struts IMO, are that action centric frameworks are just a crummy architecture. Imagine coding Swing applications as a set of action listeners that accept parameters. That would truly suck, yet that is what Struts is doing, and it ties you into servlets, and the servlet context. This creates many headaches for the enterprise web app developer. So Struts needs something on top to provide all that, but then the interfacing is still crummy. No point on extending a fundamentally bad.

    Then there is JSP, a legacy of Suns attempt to mimick ASP. It quickly becomes bad news. It is hard to resist putting scriptlets into it, then business logic leaks into it, and taglibs are unclean, and also start to get all sorts of code inthem that doesn't fit well. Much better to have HTML templates a web page author can develop and then instrument them with real components, with all the business objects well and truly decoupled.

    For above reasons, effective reusue is practically impossible with Struts/JSP, so the appoaches just aren't really OO, which is the whole point of Java dev.

    Sun have addmitted this by createing JSF, an attempt at a componenting of JSP. They have also ripped off HTML templating like Tapestry, so that finally you can create proper components. Does it really work? How does it compare to Tapestry?

    I really don't want to have to look at using the best fit framework for each requirement scenario. I'd like a few libraries that do most of the work most of the time, that are fairly simple yet flexible and capable of complexity.

    Tapestry4 with some HiveMind services and a bit of Cayenne really looks promising for the small to mid-size web projects I often get onto. Add Spring, and you can handle bigger projects with no J2EE.

    Cost is all about developer time, and when you have to factor in a J2EE server, which needs to be deployed to, stopped and restarted, configures. and all thatm you lose hours of production time, each week, per developer. Youneed a bigger skill set on your team, and spend a lot of timedoing stuff other than writing business code. Then you have all the quality issues surrounding JSPs and action centric technology. IMO, it's all pants, and very expensive and complex pants at that.
  43. Sun have addmitted this by createing JSF, an attempt at a componenting of JSP.

    This shows a deep misunderstanding of JSF and one of its potential great advantages over other frameworks. JSF is not a 'componenting of JSP'. It is a general framework for server-side UIs - not not just web pages. It can render to any presentation technology - as long as someone provides the appropriate renderkits. JSP + HTML is simply the rendering nechanism provided along with Sun's Reference Implementation of JSF. Other implementations provide a range of rendering options.

    This flexibility sometimes leads to the mistaken impression that because JSF can do more than web pages that it is somehow less suited to web pages than other frameworks.
  44. JSF is not a 'componenting of JSP'. It is a general framework for server-side UIs - not not just web pages.
     

    This exact aspect of JSF (and JDO for that matter) is the greatest problem.
    Technology that aims being everything for everybody will inevitably fail.
  45. Rails ![ Go to top ]

    Just had to make this decision, and jumped on JSF.
    Tried JSF for a while, and it drove me crazy (too much to mention). However, using Facelets with JSF helped out ALOT in terms of layout.

    In the end, I bought the Pragmatic Programmers guide to Ruby, and have already started my webapp on Rails. It's fun :)
  46. Rails ![ Go to top ]

    Just had to make this decision, and jumped on JSF.Tried JSF for a while, and it drove me crazy (too much to mention). However, using Facelets with JSF helped out ALOT in terms of layout.In the end, I bought the Pragmatic Programmers guide to Ruby, and have already started my webapp on Rails. It's fun :)

    It may be fun but it is neither component based or pure HTML. Rails web pages look a lot like JSP/ASP to me, with the only difference being that you are embedding Ruby rather than Java.
  47. Rails ![ Go to top ]

    True, true and true... Good points.

    (However, I'm putting a high weight on "Fun" for this type of project ;))
  48. Rails ![ Go to top ]

    I think that too much emphasis on “fun” smells “craft” – and craft is the fun thing to do, it just does not scale. Lets look around: we do not use handcrafted furniture, tableware, cars, electronics, etc.
    Sure the nicely done pieces of craftsmanship are cool, but not too practical.
  49. Fun is important![ Go to top ]

    I think that too much emphasis on “fun” smells “craft” – and craft is the fun thing to do, it just does not scale. Lets look around: we do not use handcrafted furniture, tableware, cars, electronics, etc. Sure the nicely done pieces of craftsmanship are cool, but not too practical.


    One of my better days recently was returning to a client to give them half a day about upgrading from Tapestry 3.0 to 4.0. Unprompted by me, the first thing they said (the whole team) was how much fun they were having.

    This is very important. Alpha nerds love their work; they love to be productive. Being productive is fun, creating toys is fun, making the HTML sing and dance is fun. Developing web applications usually isn't fun ... because there are so many obsticles in the way. Apparently, developer fun has a very short decay cycle.

    Web applications should be fun, fun is a good design smell. Fun, for developers, is being able to produce good work without getting frustrated. Fun is getting something for nothing. Fun is it just works. Saying that Tapestry is fun is great, great praise. I'm trying to make Tapestry slimmer and simpler to make it more fun.
  50. Fun is important![ Go to top ]

    Fun is it just works. Saying that Tapestry is fun is great, great praise.

    You're welcome! (Though I think I'll be having more fun using Wicket ;-) )

    I agree with your post. Fun is very important in your work. Having fun means that you actually enjoy building the application(s). Enjoying your work increases the quality and productivity.

    Most times I didn't have fun, my code wasn't as good as it could've been. BTW this also works the other way round: when my code isn't as good as I expect it to be, then I conversely am NOT having fun.
  51. Simplified Struts Development[ Go to top ]

    Struts Development can be very simple if you design another POJO based view layer.

    I designed a POJO based View layer, the following are the core members of the layer,
    Page,
    Tab,
    Button,
    Field,
    Summay,
    ValueList,

    And I defined only one Java Bean inside form bean,
    <form-bean name="myForm" type="org.apache.struts.validator.DynaValidatorForm">

    <form-property name="mybean" type="com.mycompany.myproject.bean.MyBean"/>

    </form-bean>

    I only have one set of JSP files and they can display as many domain objects as you want. And the number of actions is less then the number of pages. For example, I defined the fields to be displayed on the summary area of the page, so the page can pick up the value of the properties of the domain objects and display them automatically. The domain object can be assoicated to other domain objects or composite key and I just need configure the property using JSTL convention like
    myObject.itsCompositeKey.id,myObject.itsChild.someProperty
    in the MessageResources.properties file.

    The input fields are also automatically generated. When Editting, instead of display value, it creates two fields on the HTML form,
    <input name=myObject.itsCompositeKey.id>
    <input name=myObject.itsChild.someProperty>

    The domain objects need to be Java Beans.

    So it is a relief from struggling with JSPs, JSTLs and Actions, everything is just MessageRourses.properties.

    Only one Action is used to get the ValueLists of millions of domain objects.

    The concept is probably similar to Struts Live, but I didn't know Struts Live until today and I designed this POJO based extension be myself.

    This extension can handle,
    JavaScipt-less form submission with Internationalization,
    Form Based business application,
    Code-less HTTP Form to Transfer/Domain Object Mapping,
    ...

    The development is very productive considering it eliminates so many tasks and people who know how to configure message resources can work on the project.
  52. Boring is safe![ Go to top ]

    Struts is VHS. It had its day. I have lots tapes and a dusty VCR but it still works and I'm comfortable with it.

    Wizards such as in the new Visual Studio will push JSF into the limelight. Gotta have the GUI builder.

    The focus seems to be off of "VC" and on "M" of "MVC" with new defacto standards like Spring and Hibernate. Would teams adopt SpringMVC on its own without Spring?

    The presentation has to be fast, safe, and predictable. Why invest in a new MVC if you can estimate accurately with Struts. Great for offshore CMM Level 5 drones. Rails gives you fast over safe and predictable. JSF gives you ASP.Net parallelism. Presentation does not have to be fun. Struts was fun once. There is no competitive advantage in fun only a geek's adulterous affair with something fresh and different. Go back to your wife. Think of the kids.

    I saw Dave Thomas speak recently. He made a statement I had to think about. He said Java was too hard for business development. Knowing full well he was a ruby guy I took the bait and looked perplexed so he would ellaborate. He felt that something easier was required. Something closer to Ruby or even Rails. Are MVCs easy? Maybe easy is fun. But most MVC's out there are not easy.
  53. Fun is important![ Go to top ]

    I agree completely, and this is the same kind of feedback I get coming out of Google for WebWork :-)
    I think that too much emphasis on “fun” smells “craft” – and craft is the fun thing to do, it just does not scale. Lets look around: we do not use handcrafted furniture, tableware, cars, electronics, etc. Sure the nicely done pieces of craftsmanship are cool, but not too practical.
    One of my better days recently was returning to a client to give them half a day about upgrading from Tapestry 3.0 to 4.0. Unprompted by me, the first thing they said (the whole team) was how much fun they were having.This is very important. Alpha nerds love their work; they love to be productive. Being productive is fun, creating toys is fun, making the HTML sing and dance is fun. Developing web applications usually isn't fun ... because there are so many obsticles in the way. Apparently, developer fun has a very short decay cycle.Web applications should be fun, fun is a good design smell. Fun, for developers, is being able to produce good work without getting frustrated. Fun is getting something for nothing. Fun is it just works. Saying that Tapestry is fun is great, great praise. I'm trying to make Tapestry slimmer and simpler to make it more fun.
  54. Rails ![ Go to top ]

    I think that too much emphasis on “fun” smells “craft” – and craft is the fun thing to do, it just does not scale. Lets look around: we do not use handcrafted furniture, tableware, cars, electronics, etc. Sure the nicely done pieces of craftsmanship are cool, but not too practical.

    Excellent analogy Konstantin !
    Well... To be quite honest... I live up in the mountains, grow most of my own food, drink well water, did make most of my own furniture. However, I absolutely need my wireless access and coffee (which doesn't grow well where I live).

    So, I'm going to compromise and code Java at work (an enterprise application with 50+ engineers), and Ruby at home (not so enterprise with 1 absolute amazing engineer)... :)
  55. Matt Raible, while at the Colorado Software Summit last week, pointed out a number of interesting facts as well:
    * The majority of companies hiring new web developers are still looking for Struts experience; and
    * Most developers say they will be using SpringMVC in the future, but quite a few are still planning on Struts (http://raibledesigns.com/page/rd?anchor=spring_mvc_the_most_popular , not a very representative sampling though)

    jeff bonevich
    http://jroller.com/page/bonevich
  56. Matt Raible, while at the Colorado Software Summit last week, pointed out a number of interesting facts as well:* The majority of companies hiring new web developers are still looking for Struts experience; and* Most developers say they will be using SpringMVC in the future, but quite a few are still planning on Struts (http://raibledesigns.com/page/rd?anchor=spring_mvc_the_most_popular , not a very representative sampling though)jeff bonevichhttp://jroller.com/page/bonevich

    I have a lot of respect for Matt, but...

    His poll is questionable at best (as a basis of Spring MVC adoption). It would be like Hani doing a poll on Maven vs. Ant. Okay a little more accurate than that but still.

    Let me put it this way, when giving a talk on JSF, I asked the group how many people plan on using JSF. Ummmm... Errr... The results were overwhelmingly JSF, go figure.

    We do Spring MVC & Spring training, JSF and Spring training. (I do mostly consulting these days, but the company still does a lot of training.)

    We get a lot more people asking for JSF + Spring training than we get Spring MVC + Spring. (10 to 1)

    Yet I doubt this is an accurate poll since we favor JSF.

    Dice is a much more accurate poll for JSF adoption than Matt's.

    Here are the web framework in order of popularity:

    Struts
    JSF
    Tapestry
    WebWork (often trades places with Tapestry)
    Spring MVC
    the rest.
  57. /I do mostly consulting these days, but the company still does a lot of training.)We get a lot more people asking for JSF + Spring training than we get Spring MVC + Spring. (10 to 1)Yet I doubt this is an accurate poll since we favor JSF.Dice is a much more accurate poll for JSF adoption than Matt's.Here are the web framework in order of popularity:Struts JSF Tapestry WebWork (often trades places with Tapestry)Spring MVCthe rest.

    Still promoting JSF he? I would be extremely interessted in a poll of "skilled" web application developers regarding this issue. You are right that there is some degree of JSF adoption inside big companies (even in my current contract) but the people betting on JSF are mostly the ones that doesnt have much expierence at all.

    I doubt that there are too much people with strong webwork or Struts experience that promote JSF. In fact, a lot of people i know would prefer instant death than to switch to JSF. Since i am getting paid for doing a java project which also contains JSF, i decided to die slowly because of JSF.

    But all those people proclaiming the death of Struts dont know the real world. These people should start working in real jobs to see how companies are working nowadays.
  58. I just thought I'd point out that I've spent quite a bit of time working with Struts (and Cocoon, for that matter), as well as my own Struts-like framework before-hand. I've also evaluated countless others.

    I'm a big supporter of JSF, and I think it's a better way to build web applications. And yes, I've built plenty of desktop applications as well, and worked with languages other than Java. As someone who has met a lot of people working with JSF (at engagements all over the world), I really don't get the impression that people who like JSF have never worked with Struts.


    Kito D. Mann (kmann at virtua dot com)
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info

    Are you using JSF in a project? Send your story to trenches at jsfcentral dot com, and you could get your story published and win a free copy of JavaServer Faces in Action!
  59. Still promoting JSF (eh)?

    Nope. Just trying to inject some reality in the conversation. I would be just as happy working with Tapestry or some other component-based web framework. (I have not used Rife, Echo, or Wicket so can't comment on them per se).
    I would be extremely interessted in a poll of "skilled" web application developers regarding this issue.

    I've used Struts extensively and effectively on many large, high traffic sites.
    You are right that there is some degree of JSF adoption inside big companies (even in my current contract) but the people betting on JSF are mostly the ones that doesnt have much expierence at all.

    This sounds like a lot of conjecture. What specifically do you like about Struts that you do not like about JSF? What technical merit does Struts have over JSF in your eyes? Specifics please.

    I doubt that there are too (many) people with strong (W)eb(W)ork or Struts experience that promote JSF.

    Craig Mclanahan (sp?), David Geary, Kito Mann.... Do they not qualify as folks with a strong struts background?

    When you say Struts, do you mean Struts TI, Struts Shale, or classic Struts? Why do you suppose that Struts TI exists?

    WebWork is in a category of its own as it does not have the same problems as Struts (poor extensibilty, actions tied to Http Servlets, a coherent validation model). I don't think you can lump WebWork users with Struts Classic users.

    I would much prefer working with WebWork or Spring MVC than Struts.
    In fact, a lot of people i know would prefer instant death than to switch to JSF. Since i am getting paid for doing a java project which also contains JSF, i decided to die slowly because of JSF.

    I can understand this emotion. It is hard to give up with what you are comfortable with. There are a lot of developers that can't give up COBOL. This does not make COBOL a better model for development.
    But all those people proclaiming the death of Struts dont know the real world. These people should start working in real jobs to see how companies are working nowadays.

    Perhaps, but if you based these frameworks on technical merit, Struts would not do well. It would be bested by JSF, Spring MVC, WebWork, etc. Perhaps Struts will continue to dominate, but it will be socio-economical reasons not technical merit.

    I've worked with Struts long enough to know what I don't like, and what WebWork, Spring MVC and JSF does better.
  60. in JSF everything is POST[ Go to top ]

    What specifically do you like about Struts that you do not like about JSF? What technical merit does Struts have over JSF in your eyes? Specifics please.

    I'm not the original author, but the biggest problem that I see in JSF is that nothing works without Javascript, not even hyperlinks (at least in myfaces demo that I tried). To me that means the technology is quite useless.

    And that's why I chose Wicket. As someone already mentioned: It's fun :)
  61. Wicket[ Go to top ]

    The moment I learned that Wicket stores the history in the session, it fell from grace for me. I like the concept, but the implementation has some caveats.
  62. JSF basically does the same[ Go to top ]

    To my knowledge the RI and myfaces post 1.1.1 (btw. the 1.1.0 and 1.1.1 announcements never made it to the top page, while 1.1.0 was an important milestone, first being out of beta and first having passed the JSF TCK)

    In the latest myfaces builds if you go for server side state handling the last 10 or 20 states of the ui are stored in the session in a serialized state (as far as I understood what was implemented, I followed the discussion a little bit in my sparetime), if you go for client side state handling, tha browser takes care of it.

    To my knowledge the RI uses similar mechanisms, to cope with the back problem.
  63. Wicket[ Go to top ]

    Actually, I think you should keep your eye on Wicket if that's your main concern. The implementation of this is pretty smart by default, especially if you use detachable models. But the long-term design plan is to add more options for tuning session weight (see the two posts on my blog about reducing wicket state here: http://jroller.org/page/JonathanLocke). If time and resources permit, 1.2 will include not only lighter weight pages, but url state encoding (which is really quite interesting with detachable models!) and fully stateless pages. The big advantage of this approach is that you can start simple and dumb and tune as you need to by applying additional elbow grease.

    -- Jonathan
  64. Wicket[ Go to top ]

    The moment I learned that Wicket stores the history in the session, it fell from grace for me. I like the concept, but the implementation has some caveats.

    That's kind of the pavlov reaction most people seem to have. We are working on alternative strategies as well, but I think stroring it in the session is still the best way to go (btw, other than some competitors, session data will be garbage collected automatically).

    Did you ever make a serious consideration of e.g. how much it costs (cpu and net) to serialize state, send that to a client (usually more precious bandwith than any cluster net, and results in large pages), and deserialize again compared to just storing instances of a component tree in the session? Furthermore, /what/ exactly is stored, /how/ it is stored (it is not coupled to httpsession, so it might be a database or clustered cache) etc is all pretty configurable and subject to ongoing improvement.

    And lastely, another simple consideration is how much saving some memory costs you in plain dollars/ euros/ whatever? Web mvc frameworks like Struts scale bad when it comes to UI complexity and developer teams. And the programming model just sucks. I honestly hope not to have to do any project with such a framework anymore.
  65. That's kind of the pavlov reaction most people seem to have. We are working on alternative strategies as well, but I think stroring it in the session is still the best way to go (btw, other than some competitors, session data will be garbage collected automatically).Did you ever make a serious consideration of e.g. how much it costs (cpu and net) to serialize state, send that to a client (usually more precious bandwith than any cluster net, and results in large pages), and deserialize again compared to just storing instances of a component tree in the session?

    I didn't make the original comment, but I also don't like storing component state in session. But I'll expand that: I don't like storing component state server side at all (outside of the boundaries of a single request). We live in a world where users expect to be able to do things like arbitrarily open pages in new windows, navigate back and forward at well etc. With component state stored server side, there's no decent way to handle the multiple-window problem. Seam has tried, and for my money only provides half a solution. Until a server side app can spot a new window the moment it appears and fork state for it, I won't be happy with server-side component state. It's not about memory, or cpu or bandwidth (all are cheap compared to developer time unless you have google's traffic). It's about functionalty plain and simple.
    Web mvc frameworks like Struts scale bad when it comes to UI complexity and developer teams. And the programming model just sucks. I honestly hope not to have to do any project with such a framework anymore.

    I disagree with this pretty strongly. Firstly, the programming model doesnt have to suck. Using a nice clean command pattern (basically combine your form and action to produce a single-use command object) it can be really quite simple and easy. Secondly, scaling for UI complexity can be managed quite simply *if* you have a good model for view-helpers and use UI fragments as components. That way any UI component can be embedded into any page, and you can create re-usable "components" that can have their data fed to them or pull in their own data as applicable.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  66. I didn't make the original comment, but I also don't like storing component state in session. But I'll expand that: I don't like storing component state server side at all (outside of the boundaries of a single request). We live in a world where users expect to be able to do things like arbitrarily open pages in new windows, navigate back and forward at well etc. With component state stored server side, there's no decent way to handle the multiple-window problem.

    Yeah, that can be a problem. We have a solution for multiple windows/ popups/ frames with Wicket. Though yeah, unfortunately we can't detect it, so it has to be done by e.g. clicking a link first.
    Seam has tried, and for my money only provides half a solution. Until a server side app can spot a new window the moment it appears and fork state for it, I won't be happy with server-side component state. It's not about memory, or cpu or bandwidth (all are cheap compared to developer time unless you have google's traffic). It's about functionalty plain and simple.

    If you have plain and simple functionality, MVC will work fine. Still not elegant, but good if you need to do REST. /However/ if you need to build apps that are more like traditional applications (say, pages with mutliple search filters, pageable lists, maybe a tree and that combined), you'll be in a mess mapping one request to several independent screen elements. You'll have to do things like command chaining (hey, let's even create a project for that, so that it doesn't sound like a hack) etc. And/ or you have to put temporary objects in the session for synchronization (without any control over it, as they are put in the session in a ad-hoc manner). And/ or they need an interception to sync 'state'. I have worked and consulted on many webapps with MVC frameworks the last few years, and sooner or later they all end up with hacks like these.
    Web mvc frameworks like Struts scale bad when it comes to UI complexity and developer teams. And the programming model just sucks. I honestly hope not to have to do any project with such a framework anymore.
    I disagree with this pretty strongly. Firstly, the programming model doesnt have to suck. Using a nice clean command pattern (basically combine your form and action to produce a single-use command object) it can be really quite simple and easy.
    Oh yeah. I just love stateless programming. Who needs OO when you have request parameters and XML?
      Secondly, scaling for UI complexity can be managed quite simply *if* you have a good model for view-helpers and use UI fragments as components. That way any UI component can be embedded into any page, and you can create re-usable "components" that can have their data fed to them or pull in their own data as applicable.

    I know. You'll end up with tons of utility/ helper/ whatever classes, preferably with static methods.

    Sorry for being sarcastic. It's just years of frustration with MVC frameworks pouring out.
  67. Re: Wicket[ Go to top ]

    Did you ever make a serious consideration of e.g. how much it costs (cpu and net) to serialize state, send that to a client (usually more precious bandwith than any cluster net, and results in large pages), and deserialize again compared to just storing instances of a component tree in the session? Furthermore, /what/ exactly is stored, /how/ it is stored (it is not coupled to httpsession, so it might be a database or clustered cache) etc is all pretty configurable and subject to ongoing improvement.
    Have you heard about ASP.NET???
  68. in JSF everything is POST[ Go to top ]

    ... the biggest problem that I see in JSF is that nothing works without Javascript, not even hyperlinks (at least in myfaces demo that I tried). To me that means the technology is quite useless.And that's why I chose Wicket. As someone already mentioned: It's fun :)

    Huh?? Care to explain this a little futher? JSF has no dependency on javascript at all, however you can integrate Javascript easily into JSF apps or components as well.

    Sounds like more uninformed JSF bashing...
  69. in JSF everything is POST[ Go to top ]

    Huh?? Care to explain this a little futher? JSF has no dependency on javascript at all, however you can integrate Javascript easily into JSF apps or components as well.Sounds like more uninformed JSF bashing...

    As I said, every JSF page that I've tried so far, stops working the second I turn off Javascript. And as I mentioned MyFaces as an example, you can try it yourself:

    http://www.irian.at/myfaces/home.jsf

    And I have nothing against Javascript. I just think, that if linking between JSF pages really needs *Javascript* to work, then the web framework in question is fundamentally broken.

    Still I admit; my exploration to a JSF wonderland has been quite brief, so feel free to correct any misunderstandings :)
  70. The Javascript dependency[ Go to top ]

    Is basically caused by the command link control, which issues a javascripted post into the outer form.
    There is no reason why you cannot use simple command buttons, or a normal link.

    MyFaces to my knowledge even has a server side option to turn of javascript rendering of controls explicitely.

    While you can use jsf without javascript it is easier to be able to use javascript because as soon as you move out of the realm of basic html controls like an edit field, you run into javascript automatically. It is just a matter of how good the implementation of the control is, whether javascript becomes mandatory or not (it should not but many control programmers do not follow this golden rule)

    JSF lives and dies with the controls you can gain access to.
    Therefore things like facelets are heavens sent, because the JSF control API while being extremely powerful is not the easiest to use, JSF allows to build controls the easy way, as long as you stay in the same rendering domain.

    Besides that, JSF is not more or less dependend on external tools, than Struts, is, in fact it is less dependend, because some of the xml config stuff has been moved back into the form tags and has become easier to handle.

    It is btw. something which I cannot really understand, why so many Struts users have such problems adjusting to the thoughs of moving to JSF, JSF is really easier to use and you get way more benefits, you get a real user interface event system. The whole error handling is miles easier by pushing it back into the forms, and the whole messaging issue is also a tad easier than struts, and you do not lose functionality, you still can use actions and forms (with different names) you simply do not have to.

    If you come from a rich client side of things then jsf is basically known territory, you have form forms, the event system, you have your controller classes which can be triggered as event handlers (optionally) and optional model classes and you can gain access to the controls via the bindings.
  71. in JSF everything is POST[ Go to top ]

    ...I have nothing against Javascript. I just think, that if linking between JSF pages really needs *Javascript* to work, then the web framework in question is fundamentally broken. Still I admit; my exploration to a JSF wonderland has been quite brief, so feel free to correct any misunderstandings :)

    Yes.. I agree, your exploration so far has been brief. The fact is: JSF does not depend on Javascript. However it can use it, just like any other decent Web framework can use it.

    What you are citing as an example is actually a "MyFaces" set of demo apps which actually do use Javascript to improve the end-user usability. However MyFaces is just one example of a custom component library and implementation of JSF. With JSF you have the choice of picking from a number of custom JSF component libraries and implementations each offering their own degree of embedded Javascript support, or not. You can even build your own JSF components..with or without embedded Javascript.
  72. in JSF everything is POST[ Go to top ]

    Yes.. I agree, your exploration so far has been brief. The fact is: JSF does not depend on Javascript.

    First you state that I'm uninformed and that JSF does not depend on Javascript. Then it seems that at least the CommandLink which I was referring (and is very heavily used in JSF) does indeed depend on Javascript? Correct me if I'm wrong. And then you state that the great thing in JSF specification is that you never know how your application happens to behave with the particular JSF implementation you decide to use? Like Forrest Gump's box of chocolates: "You never know what you're gonna get"?

    I don't know why you are getting so personal about the impression I've gotten about JSF. When I see an implementation working without Javascript, I might jump to the merry JSF bandwagon myself. Until that happens, I'll use Wicket.
  73. in JSF everything is POST[ Go to top ]

    Yes.. I agree, your exploration so far has been brief. The fact is: JSF does not depend on Javascript.
    First you state that I'm uninformed and that JSF does not depend on Javascript. Then it seems that at least the CommandLink which I was referring (and is very heavily used in JSF) does indeed depend on Javascript? Correct me if I'm wrong. And then you state that the great thing in JSF specification is that you never know how your application happens to behave with the particular JSF implementation you decide to use? Like Forrest Gump's box of chocolates: "You never know what you're gonna get"?I don't know why you are getting so personal about the impression I've gotten about JSF. When I see an implementation working without Javascript, I might jump to the merry JSF bandwagon myself. Until that happens, I'll use Wicket.

    One of the standard components (h:commandLink) uses JavaScript. You don't have to use this component. You can use h:commandButton. In your earlier post, you made it sound like all JSF development relied on JavaScript. It does not. You can replace the h:commandLink renderer to render a button that looks like a link (using style sheets). The problem is that this will not work on some older browsers.

    This is a problem with links in HTML forms in general and not specific to JSF.
  74. Actually the myfaces[ Go to top ]

    Examples page, is probably a bad demo, if you are in for non javascript, because the demo is more a demo page of the extended components than anything else, and many of those due to the inherent limits of pure html simply rely on javascript to cope with the dynamics.

    But you can do JSF without javascript, just avoid the command link within forms.
  75. in JSF everything is POST[ Go to top ]

    Well as anything the command link is just one control.
    The basic controls are basically just the html entry fields
    form and the command link.
    And some additional supporting stuff, like panelGrid etc..

    They have to behave the same over all implementations.
    What you cannot expect is, to get the same behavior of similar components (tree controls or html editors) over various extension component sets, they are simply not specified.

    As for the rest of the javascript stuff, they have been commented ad nauseum. One reason why you cannot find demos without javascript is, that nobody has done them, most jsf demos on the web usually are there to showcase the possibilies of the extension frameworks, which have to rely on DHTML to get the added functionality.
    Once you are set on "we are using javascript" the usage of commandlink over commandbutton or link is a rather logical choice.

    Guess it really is time to do a javascript less demo sometime, but such a demo is not a good showcase, you end up with basic html controls and additional verfier functionality, which are rather limiting demowise :-(

    Yes.. I agree, your exploration so far has been brief. The fact is: JSF does not depend on Javascript.
    First you state that I'm uninformed and that JSF does not depend on Javascript. Then it seems that at least the CommandLink which I was referring (and is very heavily used in JSF) does indeed depend on Javascript? Correct me if I'm wrong. And then you state that the great thing in JSF specification is that you never know how your application happens to behave with the particular JSF implementation you decide to use? Like Forrest Gump's box of chocolates: "You never know what you're gonna get"?I don't know why you are getting so personal about the impression I've gotten about JSF. When I see an implementation working without Javascript, I might jump to the merry JSF bandwagon myself. Until that happens, I'll use Wicket.
  76. in JSF everything is POST[ Go to top ]

    With JSF you have the choice of picking from a number of custom JSF component libraries and implementations each offering their own degree of embedded Javascript support, or not. You can even build your own JSF components..with or without embedded Javascript.
    You can build components with EJB 1.0-2.1 too, but why the Spring is so widespread? Have a look at components model in Wicket and you'll see a difference...

    I've tried to switch my team to JSF mostly because its "Vendor Support" (similar to EJB slogan), but I've found creating custom components for projects takes too much unnecessary coding and I hate this bloated faces-config stuff (even worse than Struts config)...

    P.S. Please don't refer me to "JSF for nonbelievers"-like articles, I've read most of them...

    Regards,
    Theodore Kupolov
  77. When you say Struts, do you mean Struts TI, Struts Shale, or classic Struts? Why do you suppose that Struts TI exists? WebWork is in a category of its own as it does not have the same problems as Struts (poor extensibilty, actions tied to Http Servlets, a coherent validation model). I don't think you can lump WebWork users with Struts Classic users.I would much prefer working with WebWork or Spring MVC than Struts.

    Bingo. While Struts is the dominant action oriented framework (request/response oriented, whatever) it is not the only one. And given that it was pretty much the first major one, has a large install base, and the team (for perfectly valid reasons) won't break backward compatibility, it has a large number of well understand shortcomings that cannot be easily rectified.

    I think that component oriented development ala JSF, Wicket et al has it's place, but it's not for me. I dream of a world where the wider community learns how much better some of the other action oriented frameworks like WebWork are, and how easy they are to transition to.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  78. I dream of a world where the wider community learns how much better some of the other action oriented frameworks like WebWork are, and how easy they are to transition to.

    You need to be a programmer to use Action oriented frameworks, where component-based frameworks can be powered by simple drag'n'drop development (if so chosen). The simplicity is there, the transition problems you see are from programmers that try to carry action oriented principles into the component frameworks. HLS has said the same for for developers in Tapestry training.
  79. I dream of a world where the wider community learns how much better some of the other action oriented frameworks like WebWork are, and how easy they are to transition to.
    You need to be a programmer to use Action oriented frameworks, where component-based frameworks can be powered by simple drag'n'drop development (if so chosen). The simplicity is there, the transition problems you see are from programmers that try to carry action oriented principles into the component frameworks. HLS has said the same for for developers in Tapestry training.

    I don't really agree that the problem with component oriented frameworks is that developers need to unlearn their current behaviors. While that's almost certainly part of the problem, it's not the problem I have.

    I don't want to turn this into a bashing-component-oriented thread post, so I'll try to summarize my issues and leave it at that. I tend to end up building web applications that are highly concurrent and have strong requirements about seamless multi-window and back-button operation (think large day trading brokerage). Working with a well designed action oriented framework this is very simple to do. Most component frameworks I've looked at make it harder or near impossible to manage this as cleanly. That's not to say they don't have their place, but I don't find them to be a good fit for the kinds of applications I work on.

    It seems to me that a lot of component-oriented affecionados position component oriented web development as the natural evolution of web develoment and that action-oriented is going to go the way of the dinosaurs. I don't buy that, so it constantly rubs me the wrong way.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  80. It seems to me that a lot of component-oriented affecionados position component oriented web development as the natural evolution of web develoment and that action-oriented is going to go the way of the dinosaurs. I don't buy that, so it constantly rubs me the wrong way.-Tim Fennell
    Stripes: Because web development should just be easier.

    I believe there's a general concensus that there's opportunity to find a middle ground between Action and Component oriented frameworks, or at least modify the behavior of Component oriented frameworks such that they accodate the front controller behavior many are looking for.
  81. I believe there's a general concensus that there's opportunity to find a middle ground between Action and Component oriented frameworks, or at least modify the behavior of Component oriented frameworks such that they accodate the front controller behavior many are looking for.

    That makes more sense to me. I like the idea of a front controller/action oriented model that has the drop-in component capabilities that component oriented frameworks tend to offer.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  82. I believe there's a general concensus that there's opportunity to find a middle ground between Action and Component oriented frameworks, or at least modify the behavior of Component oriented frameworks such that they accodate the front controller behavior many are looking for.
    That makes more sense to me. I like the idea of a front controller/action oriented model that has the drop-in component capabilities that component oriented frameworks tend to offer.-Tim FennellStripes: Because web development should just be easier.

    I suggest you read up on RIFE's web engine and it's approach on componentization: http://rifers.org/about

    An excerpt:
    RIFE combines both by taking control of the entire data and logic flow in a request-based model. Developers remain close to the architecture of CGI applications and have full control over URLs, forms, parameters, cookies and pathinfos. However, instead of mapping actions and controllers directly to the request, RIFE provides a component object model that behaves identically in many different situations such as individual pages, intercepted requests, portal-like page fragments and integratable widgets. Components can be wired together and be packaged as groups that are components in their own right. They can be distributed separately and be seamlessly integrated into any other RIFE project. This provides the same form of reusability as component-based frameworks, but with the raw control of the request-based approach.
  83. There's so much duplication between all of these frameworks with subtle changes. The controller behavior and component behavior should be two separate concerns. JSF does a great job of creating a flexible controller (5 steps of all MVC frameworks) that all of us couldn't consolidate with plugin-like functionality, yet go back to the JSF spec in hopes of finding better ways to utilize the controller without locking yourself into JSF UIComponents. It would be a huge step, but a step that's already been proven by Struts-Faces, Shale, and JBoss Seam.

    So, complexity can scale and you can still retain procedural action-oriented controllers while optionally using UIComponents, or other component frameworks with JSF API modifications-- allowing you to use stateless component views or alternate strategies for representing view behavior.

    The point is that the groundwork is there, and that developers should be more vocal about their desire to consolidate into a stack stronger than just the Servlet-API which every different MVC framework is constructed on.
  84. I believe there's a general concensus that there's opportunity to find a middle ground between Action and Component oriented frameworks, or at least modify the behavior of Component oriented frameworks such that they accodate the front controller behavior many are looking for.
    That makes more sense to me. I like the idea of a front controller/action oriented model that has the drop-in component capabilities that component oriented frameworks tend to offer.-Tim FennellStripes: Because web development should just be easier.

    That's what we do with WebWork. The misconception is that we don't have reusable UI components. The reality is that we have excellent UI components that are even MORE reusable because you can modify or replace the template that renders them (as opposed to creating a Renderer class in JSF and doing a bunch of println()'s.). We just don't think that WEB applications are best represented where the UI components are the central paradigm. We think that a command-pattern paradigm of handling a request and rendering a result is a better way to think about it.
  85. That's what we do with WebWork. The misconception is that we don't have reusable UI components. The reality is that we have excellent UI components that are even MORE reusable because you can modify or replace the template that renders them (as opposed to creating a Renderer class in JSF and doing a bunch of println()'s.). We just don't think that WEB applications are best represented where the UI components are the central paradigm. We think that a command-pattern paradigm of handling a request and rendering a result is a better way to think about it.

    What it comes down to is that by packaging component rendering and controller behavior within a single concern, it allows you to quickly express functionality at the page level without separating your development between the controller and the UI. At the very least, the idea of specifying smaller controllers around fragments of included UI logic can help to increase re-usability.
  86. Yes, we do this. In fact, you can package your actions and the views which are rendered for them in a jar file and drop them into your app. You can then call it inline using the ww:action tag to have an in-page controller, if you want to have a drop-in reusable component.

    In fact, you can do the same for a bundle of actions with their configuration and use them as a portlet with different actions per portlet state. How's that coming with JSF?
    What it comes down to is that by packaging component rendering and controller behavior within a single concern, it allows you to quickly express functionality at the page level without separating your development between the controller and the UI. At the very least, the idea of specifying smaller controllers around fragments of included UI logic can help to increase re-usability.
  87. In fact, you can do the same for a bundle of actions with their configuration and use them as a portlet with different actions per portlet state. How's that coming with JSF?

    I don't have a lot of experience with JSF and Portlets combination. But what little experience I do have is positive. I was surprised how seamlessly a sample Hibernate/Spring app I wrote worked in two portlet envs without any changes.

    The problems I've had are more with the envs themselves rather than the JSF support for Portlets per se.

    I'll let you know if I run into any major roadblocks with JSF/Portlet development. The team I am working with has deployed several JSF/Portlet apps.

    I am sure WebWork works nicely with Portlets.
  88. Struts CORE 1.3 is great![ Go to top ]

    I've been working with Struts 1.3 dev version since January, including on large projects, and I think Ted is much too modest about what is great and new in 1.3.

    Struts 1.3 allows you to decompose the request processor, replace parts to your liking, and use the Command (interface) instead of Actions (inheritance).
    You can also inject your own Context to make your code simpler.

    That means you can use Struts 1.3 CORE as robust infrastructure for virtually any specific request-response handling you can think of. Imagine Struby, a Struts app with the simplicity of RoR...

    So we use Struts CORE with some extensions (from the Struts distribution and elsewhere).

    Wolfgang Gehner

    A recent update of a Struts 1.3 suite with sample project here:
    http://www.infonoia.com/en/downloads.jsp (registration required) Attention, download includes complete Eclipse 3.1 and configured SVN to major Struts subprojects source.
  89. I doubt that there are too much people with strong webwork or Struts experience that promote JSF. In fact, a lot of people i know would prefer instant death than to switch to JSF. Since i am getting paid for doing a java project which also contains JSF, i decided to die slowly because of JSF.But all those people proclaiming the death of Struts dont know the real world. These people should start working in real jobs to see how companies are working nowadays.

    JSF is very different than Struts or WebWork. But what you will probably end up seeing is frameworks being written on top of JSF instead of the servlet API in the future. Struts-Faces, Shale, and JBoss Seam to name a few. Plus, you can integrate with frameworks like Spring. The benefits of component-based development are there, but there's always room for more innovation. The difference is that JSF is flexible enough as a platform that you won't be looking for a different solution each year.
  90. I doubt that there are too much people with strong webwork or Struts experience that promote JSF. In fact, a lot of people i know would prefer instant death than to switch to JSF. Since i am getting paid for doing a java project which also contains JSF, i decided to die slowly because of JSF.But all those people proclaiming the death of Struts dont know the real world. These people should start working in real jobs to see how companies are working nowadays.
    JSF is very different than Struts or WebWork. But what you will probably end up seeing is frameworks being written on top of JSF instead of the servlet API in the future. Struts-Faces, Shale, and JBoss Seam to name a few. Plus, you can integrate with frameworks like Spring. The benefits of component-based development are there, but there's always room for more innovation. The difference is that JSF is flexible enough as a platform that you won't be looking for a different solution each year.

    This is a very good point. Don't like JSF's IoC container, you can replace it with Spring (in different ways). Don't like working with JSP, you can replace it with Shale's clay (sp?) or Facelets. Do you want to integrate JSF seemlessly with Portlet 168 IBM provides a way, Apache provides the JSF bridge, and Liferay has support for it. Do you want to improve on the Navigation support? You can plug in your own NavHandler? (I think that Spring Workflow does this.)

    The JSF core framework is very solid and extensible. They learned from the mistakes of Struts and the innovations of other frameworks (Spring MVC, WebWork), and improved the model.

    Is it perfect? No. Is it good? Yes.
  91. Frameworks are silver bullets[ Go to top ]

    All these frameworks seem like silver bullets and this is evidenced by the fact that none of them seem to have much staying power. The ironic thing is that instead of decreasing accidental complexity, they seem to increase it. (I never needed all these XML files, complex IDEs, and ORM tools before) It's funny that you don't hear much discussion about good design anymore ever since EJB's popped up. Developers seemed to be enamored with the paint-by-numbers approach towards design that these architectures seem to promise. However, once you have to step outside of their box you find that rather than helping you, they get in your way. All I seem to hear about nowadays are new languages, IDE's, tools, etc that are supposed to make coding easier. What happened to good design? It's amazing that a whole sub-industry has popped up to just replace the layer that places data in an HTML page and the layer that gets data from the database. It's not that hard. You're moving a value from one place to another. It doesn't require a new paradigm or a tool set beyond JSP's, Servlets, and JDBC. These are simple tools that do the job and they're appropriately simple for the simple problem they solve. I've found they only suck when people can't design properly, but no tool is going to fix that.
  92. Frameworks are silver bullets[ Go to top ]

    ...The ironic thing is that instead of decreasing accidental complexity, they seem to increase it. (I never needed all these XML files, complex IDEs, and ORM tools before)...However, once you have to step outside of their box you find that rather than helping you, they get in your way....It doesn't require a new paradigm or a tool set beyond JSP's, Servlets, and JDBC. These are simple tools that do the job and they're appropriately simple for the simple problem they solve. I've found they only suck when people can't design properly, but no tool is going to fix that.

    I have to disagree with this. In a perfect world where everybody is an awesome developer who understands everything and knows how to design and build things with the right mix of simplicity and power, you're right. But we don't live in a perfect world.

    I think that a framework should help those who are not in the top 10% of coders get things done, and get them done in a way that won't have to be fixed up by someone else the minute they are done. They're designed to help the majority produce applications that don't suck. But a really good framework should also add value, or at a minimum not detract value from, top notch programmers. It should be easy to step around the framework where you need to, and leverage just those features that are useful at any given moment in time.

    Shameless plug: Stripes is designed to do just this - Geert went as far as to knock my statement that a good framework should "solve the problems we tackle every day and not get in the way the rest of the time". If you check it out I think you'll be pleasantly suprised.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  93. re: Frameworks are silver bullet[ Go to top ]

    I guess the goal behind all the additional layers and abstractions is that you can at some point in the future change one layer and the others remain intact.

    Having never seen this happen, I agree completely that using a more direct approach is much simpler, gives faster and cheaper results - but for the life of me I'll never use JDBC direct - use an ORM except for the reports - where custom SQL is necessary.
  94. Frameworks are silver bullets[ Go to top ]

    ...What happened to good design? It's amazing that a whole sub-industry has popped up to just replace the layer that places data in an HTML page and the layer that gets data from the database. It's not that hard. You're moving a value from one place to another. It doesn't require a new paradigm or a tool set beyond JSP's, Servlets, and JDBC. These are simple tools that do the job and they're appropriately simple for the simple problem they solve. I've found they only suck when people can't design properly, but no tool is going to fix that.

    Thank you Paul.

    These frameworks and the sub-industry that you mention are in place to keep the hacks (75% of ALL developers) from completely destroying the fragile systems that are in place.
  95. I agree completely with Paul[ Go to top ]

    Everytime I try to use one of these frameworks I get a bit disgusted. Paul has described this transient industry very well.. Thanks..
    All these frameworks seem like silver bullets and this is evidenced by the fact that none of them seem to have much staying power. The ironic thing is that instead of decreasing accidental complexity, they seem to increase it. (I never needed all these XML files, complex IDEs, and ORM tools before) It's funny that you don't hear much discussion about good design anymore ever since EJB's popped up. Developers seemed to be enamored with the paint-by-numbers approach towards design that these architectures seem to promise. However, once you have to step outside of their box you find that rather than helping you, they get in your way. All I seem to hear about nowadays are new languages, IDE's, tools, etc that are supposed to make coding easier. What happened to good design? It's amazing that a whole sub-industry has popped up to just replace the layer that places data in an HTML page and the layer that gets data from the database. It's not that hard. You're moving a value from one place to another. It doesn't require a new paradigm or a tool set beyond JSP's, Servlets, and JDBC. These are simple tools that do the job and they're appropriately simple for the simple problem they solve. I've found they only suck when people can't design properly, but no tool is going to fix that.
  96. Frameworks are silver bullets[ Go to top ]

    The ironic thing is that instead of decreasing accidental complexity, they seem to increase it.

    I have to agree with you. The more I throw overboard the more I can do what I really want. ORM has to stay though. What the frameworks bring is kind of "one way" of doing it. That's also worth something but not always.
  97. Frameworks are silver bullets[ Go to top ]

    I agree, Frameworks are silver bullets because these framework is impostor, they do not really release developer's work load. I do not like complex xml.

    XML is only a configure, not programme script!


    ===============================
    http://jdon.dev.java.net/
  98. Frameworks are silver bullets[ Go to top ]

    I agree.

    The problem seems be that some of the frameworks have a feature or two that look useful and make you interested. But they also have a TON of crud in them thay you may not need but have to carry along because many of them are 'all or nothing' solutions.

    On top of that, many of these frameworks that are supposed to make our lives easier are very complex with many LARGE books written on how to use them. Most of them simply try to make you write less java code, replacing it with 'configuration' in some xml file.

    Why the hell does anyone think putting validation rules in XML is easier than simply validating through Java? You have so much more flexibility with Java validations than these 'pre-built' validations in XML.

    I don't get it man, maybe I need to take up sheep herding.
  99. Frameworks are silver bullets[ Go to top ]

    they also have a TON of crud in them thay you may not need but have to carry along ....On top of that, many of these frameworks that are supposed to make our lives easier are very complex ....
    Why the hell does anyone think putting validation rules in XML is easier than simply validating through Java? You have so much more flexibility with Java validations than these 'pre-built' validations in XML.
    I don't get it man, maybe I need to take up sheep herding.

    Some frameworks are simple and non intrusive to your code, they make it easier for others to maintain your code or unit test by simply doing MVC KISS. For example unit test the model CRUD. Or UI expert to test the JSP's w/out a DAO.

    Validation should also hapen client side in javascript. No need to code it, just declare what you want.

    Also, declerative programing (in XML) seems to be the future for the langages, such as Flex, MS XAML, and Java JDNC, they are all just becoming declerative (saying what you want, not how to get it done).

    Those that represent JSF or Spring (both high impact/ComplexIMO) as one representing J2EE are doing J2EE a huge de-service. JSF is sort of the EJB of View layer, used mostly by less experienced people w/ no track record working w/ deparmental size solutions using legacy UI. (ex: 8 concurent users). It is possible to simplify J2EE w/o going to Ruby. Ex: Groovy. Apache iBatis Petstore. Simple Logger. etc.

    The new apss are RiA/Web 2.0... and declerative programing. So all of you doing DHTML... sorry buds, large comercial rich apps are on the way to crush your little apps.

    Sheep hearding... now that's a good idea for all of us. Outside of cell phone range and no electricity!

    .V
  100. Frameworks are silver bullets[ Go to top ]

    JSF is sort of the EJB of View layer, used mostly by less experienced people w/ no track record working w/ deparmental size solutions using legacy UI.

    I apologise, as I usually try and remain moderate in my postings, but to suggest that JSF is used by 'less experienced people with no track record of departmental size solutions' sounds like nothing more than trolling to me.
  101. Not professional[ Go to top ]

    Those that represent JSF or Spring (both high impact/ComplexIMO) as one representing J2EE are doing J2EE a huge de-service.

    .V,

    Could you please back up your statement about Spring? Spring's Petstore (which is based on Clinton's original iBatis version) is actually less lines of code than iBatis's Petstore, and simpler to test and maintain because of the IoC and declarative @TransactionManagement facilities. Have you compared the two versions?

    Your statement about Spring being "high impact" or "complex" completely inaccurate and is flat out FUD. Have you even used the framework - and if so, which parts?

    Please back this up -- you are doing the Spring and TSS communities a huge dissservice by making such generally negative statements.

    And I'm no JSF expert, but your rationale for slamming JSF was near offensive. Let's hear your track record, man.

    Keith
  102. Not professional[ Go to top ]

    Yes, Spring is a very good anti EJB framework (it is good from political point of view).
  103. Not professional[ Go to top ]

    Yes, Spring is a very good anti EJB framework (it is good from political point of view).

    The amount of FUD on this thread is astonishing. One of the reasons I am impressed by Spring is because of its neutrality. There seems to be a lack of 'attitude' associated with it - Spring allows a wide range of approaches to development and strategies. Although Spring can be used as a replacement for certain parts of EJB, it is not 'anti-EJB'. If it was, it would not include considerable support for EJBs (see Chapter 17 of the Spring reference manual).
  104. Not professional[ Go to top ]

    Sorry, I see it just was anti-EJB framewok ("j2EE without EJB"), but it looks like EJB's are going to become popular again (Spring is very good indicator to make political decisions, everybody loves it)
  105. Not professional[ Go to top ]

    BTW, it looks like Struts will be the next enemy, or doe's it have integration with Spring ?
  106. Not professional[ Go to top ]

    BTW, it looks like Struts will be the next enemy, or doe's it have integration with Spring ?

    See chapter 15.3 of the Spring reference manual.
  107. Not professional[ Go to top ]

    BTW, it looks like Struts will be the next enemy, or doe's it have integration with Spring ?
    See chapter 15.3 of the Spring reference manual.
    So Struts is the right framework too.
  108. Not professional[ Go to top ]

    BTW, it looks like Struts will be the next enemy, or doe's it have integration with Spring ?
    See chapter 15.3 of the Spring reference manual.
    So Struts is the right framework too.

    Good gods. Is the world so truly black-and-white to you? Your remarks are not useful, nor are they appropriate.

    Look at all the frameworks for yourself, pick the one that is best suited for your needs. None of them are "the right framework." Neither are any of them "the enemy." This kind of discourse is best left to politicians.

    jeff
    http://jroller.com/page/bonevich
  109. Not professional[ Go to top ]

    Sorry, I see it just was anti-EJB framewok

    Agreed!

    as per Rod of Spring at http://www.jroller.com/page/jcarreira/20040403
    "EJBs are a flawed technology" - also his books say same.

    A benefit of Spring is that you can side step a PHB as " yes, we'll try EJB w/ Spring and if it does not work its easy to go to SQL/ER based DAO" as Spring includes a DAO interface (and Struts does not ). This way PHB is glad he got a EJB server, who cares if it gets rolled out.
    So the political part is that you don't have to aruge w/ PHB on EJB is you Spring.
    My favoire story is a $400M project that pulled out EJB after beeing years late becuase they were non-scaleable.

    I see that EJB 3 is still bean based ORM, unlike non Java sucess stories, and it needs anotations, makeing Java 5.0 less readable. EJB allows to use SQL but... that goes back to posters comment... "you don't use most part of the complex framework".

    My point is that Java frameworks can be simple like non-java alternatives. The more complex a framework is, you can only do smaller labratory type projects. KISS.

    So we Java folks are losing the mindshare to alternatives.

    .V


    htpp://roomity.com
  110. Not professional[ Go to top ]

    Your statement about Spring being "high impact" or "complex" completely inaccurate and is flat out FUD.
    And I'm no JSF expert, but your rationale for slamming JSF was near offensive. Let's hear your track record, man.

    Relative to Struts, I find Spring high impact and I said so even here a year ago, not news.
    http://www.theserverside.com/articles/article.tss?l=RiA
    I may have enven mentioned it to Rod and we are able to have a conversation about it, for example about beans vs collections. You are the only person from Spring team to react so poorly.
    More on Spring
    http://www.mail-archive.com/user at struts dot apache dot org/msg21766.html
    JSF is like EJB, IMO, this is not news, no reason to pile on that, and it tired topic.

    I have done many large sites, 1up.com and others are using Struts framework. I'd be glad to compare my track record to yours or others, so give me a few sites you did and I'll match if that is realy important to you as in "lets hear your record". You know my current project too.
    Else relax, this is for play play, not for real real.

    In general, people try Ruby becuase it simplifies. You should try it sometimes on a project, one can write simple code and simple framework in Java too.

    Overall, Java people have an unhelthy regard for frameworks that overshadows the problems that they are supposed to solve.

    .V
  111. Not professional[ Go to top ]

    Relative to Struts, I find Spring high impact and I said so even here a year ago, not news.

    I guess you are referring to Spring MVC, then, one module of larger Spring Framework. That is the only part of the framework that overlaps with Struts, addressing web-tier concerns.

    Many shops *are* using Spring's middle-tier stack *with* a Struts web-tier, as Steve alluded too. This is certainly not news: Spring has shipped proper Struts integration since the beginning.

    Spring is not "anti-EJB", so please spare the drama! Spring and EJB are complimentary in many respects, and Spring has shipped EJB implementation and access support, again, since the beginning. Compared to one another, Spring provides the architectural glue for the internal structure of an enterprise application (based around finer-grained, in-process POJOs), while EJB is about exposing coarse-grained components to the server (for object distribution.) The two are compliments: what Rod and the rest of the world didn't like about EJB 2.x were Entity beans (and using them where it was clearly overkill).
    You are the only person from Spring team to react so poorly.

    I'm sorry, I react poorly to poor statements. Please try to be more considerate (or at the very least, factual) in the future.

    Keith
  112. Not professional[ Go to top ]

    what Rod and the rest of the world didn't like about EJB 2.x were Entity beans ...
    Please try to be more .... factual) in the future.

    Rod can speak for himself, what he said here http://www.jroller.com/page/jcarreira/20040403
    was "EJB 3.0 won't be enough" so I agree with people that say that, they have a point.

    You offered nothing backing up your answer to
    http://www.mail-archive.com/user at struts dot apache dot org/msg21766.html
    and I agree with people like above that that Spring is relatively complex, as are EJB and JSF to the point that some people find that it overshadows the bus. problem that they are trying to solve, so I at least keep thinking Keith tech stack(JSF+Spring+EJB?) is for deparmental scale.

    My back end is Groovy, java based, and it works for comercial scale better than ROR, imo. Best of luck to you w/ your tech stack choices, just don't get to religious about it, stay open minded that in diferent teams, diferent tech stacks work better, and don't take your eyes of the bus. problem.

    .V

    roomity.com
  113. Not professional[ Go to top ]

    You offered nothing backing up your answer to
    http://www.mail-archive.com/user at struts dot apache dot org/msg21766.html

    I don't think I offered any "answer" in that thread??? Not sure what you mean, but I don't think I've ever seen that thread before.
    I agree with people like above that that Spring is relatively complex ... that it overshadows the bus. problem

    I disagree. I personally never would have become involved in sustaining the development of the Spring Framework (and contributing to new products like Spring Web Flow) had I not felt my work directly enabled *focus* on the business problem. Spring, at the highest level, is all about applying enterprise services to POJOs (your intellectual property) in a non-invasive, use-what-you-need manner. Combine that with TDD and a disciplined agile development process, and focus is where it belongs: on solving the business problem at hand (I guess we ultimately agree there, at least).

    Keith
  114. Not professional[ Go to top ]

    And all this started about a post in this thread about frameworks are complex w/ not enough value.

    Friendster ran away from J2EE to PHP. You can't do RiA in PHP like Java JDNC.

    Tate and others ran away from J2EE to Ruby. There are too many usefull jars that I can get to from Java and Groovy.

    I think the sweet spot is in the middle, away from JSF/EJB and away from Ruby/PHP, where JDNC, iBatis Petstore (that uses Struts) and Groovy are for my ROI.(Return on invesment)

    Look at Start.com and .NET v2 that shiped this week, and compare ROI of your tech stack(Ruby,PHP, .NET, Java or whatever) if its most competetive for comercial developers.
    We are going trough a tiping point to Web 2.0 and RiA that will change vendor market shares for sure.
    Old Java can't hack it, but new Java is a winner in the long term despite the vendor tools.


    .V

    roomity.com now w/ video and favorite authors ... all in RiA.
  115. Not professional[ Go to top ]

    Those that represent JSF or Spring (both high impact/ComplexIMO) as one representing J2EE are doing J2EE a huge de-service.
    .V,Could you please back up your statement about Spring? Spring's Petstore (which is based on Clinton's original iBatis version) is actually less lines of code than iBatis's Petstore, and simpler to test and maintain because of the IoC and declarative @TransactionManagement facilities. Have you compared the two versions?Your statement about Spring being "high impact" or "complex" completely inaccurate and is flat out FUD. Have you even used the framework - and if so, which parts?Please back this up -- you are doing the Spring and TSS communities a huge dissservice by making such generally negative statements.And I'm no JSF expert, but your rationale for slamming JSF was near offensive. Let's hear your track record, man.Keith

    +1

    Vic loves to stir the pot with vague, general, negative statements. I am glad he gets under someone else's skin too. Misery loves company.

    I doubt he has used JSF or Spring.
  116. Not professional[ Go to top ]

    I doubt he has used JSF or Spring.

    Lots of things I have not tried buecase I knew I would not like it. (this works in real life, like I never tried hard drugs or alternative lifestyles, I knew it was not for my team)
    I look ahead to reduce project risk and look for dead bodies ahead of me.
    If I see a track record of success I try to duplicate. Drupal or vBulletin seem better than JSF from my angle.

    .V
  117. Not professional[ Go to top ]

    I doubt he has used JSF or Spring.
    Lots of things I have not tried buecase I knew I would not like it. (this works in real life, like I never tried hard drugs or alternative lifestyles, I knew it was not for my team) I look ahead to reduce project risk and look for dead bodies ahead of me.If I see a track record of success I try to duplicate. Drupal or vBulletin seem better than JSF from my angle..V

    One has to make certain choices since we are limited by 24 hours in a day, 7 days in a week, etc. But the issue I have is that you opine, opine and opine on technologies you have not used or quite frankly seem to really grasp.

    Opine is too polite a word. You flame technologies you do not grasp.

    I don't opine on Ruby on Rails b/c I have not used it.
  118. Not professional[ Go to top ]

    .. the issue I have is that you opine, opine and opine on technologies you have not used or quite frankly seem to really grasp.
    You flame technologies you do not grasp.

    So anyone that disagrees with you should not post?
    Show me a non trivial site you worked on JSF and put in production or other would be a great url about now. If it were up to JSF/EJB, there be not much Java ROI deployed relative to other stacks.

    "technologies you do not grasp"... a bit personal. I think many people qualified to grasp it happen to think it's not good relative to others, so they don't use it. Not becuase I said I would not use it. JSF/EJB is a tired subject... I do RiA/Web 2.0, etc.

    A framework is not as important as other things on a project. I don't want to grasp for technology iussues on my project, I want it to work so all of the team is focused 100% on the bus. requirments. I wonder if I am underqualified to think that ;-}
    Struts did it's job and got out of the way.


    .V
  119. Not professional[ Go to top ]

    JSF/EJB is a tired subject... I do RiA/Web 2.0, etc.

    JSF is certainly not a tired subject. If you do rich interfaces and Web 2.0 you should look into it. There is a considerable amount of effort from several groups and vendors to integrate JSF with AJAX. Here are a few examples.

    http://www.icesoft.com/products/icefaces.html
    http://smirnov.org.ru/en/ajax-jsf.html
    https://bpcatalog.dev.java.net/ajax/jsf-ajax/
    http://www.it-eye.nl/weblog/2005/07/20/jsf-ajax-adffacesnext/

    I would suggest that if you don't understand JSF then you don't understand the full range of tools available for rich/AJAX interfaces.
  120. Not professional[ Go to top ]

    I would suggest that if you don't understand JSF then you don't understand the full range of tools available for rich/AJAX interfaces.

    LOL Well, I guess the rest of us can just give up now... the RoR guys with Prototype, the Dojo guys and all of the different things they build with... They all need to give up and use JSF, obviously.
  121. Not professional[ Go to top ]

    I would suggest that if you don't understand JSF then you don't understand the full range of tools available for rich/AJAX interfaces.
    LOL Well, I guess the rest of us can just give up now... the RoR guys with Prototype, the Dojo guys and all of the different things they build with... They all need to give up and use JSF, obviously.

    No, of course not. Nowhere did I say anyone needed to give up anything, and to say so is to misinterpret what I clearly posted. I was talking about a full understanding of the range of tools for AJAX. Of course this includes RoR, Dojo etc. Nowhere did I imply it didn't. But it also includes JSF.

    I am amazed at the degree of misunderstanding and FUD around JSF. Debate seems to fall close to Slashdot levels.
  122. Not professional[ Go to top ]

    I would suggest that if you don't understand JSF then you don't understand the full range of tools available for rich/AJAX interfaces.
    LOL Well, I guess the rest of us can just give up now... the RoR guys with Prototype, the Dojo guys and all of the different things they build with... They all need to give up and use JSF, obviously.
    No, of course not. Nowhere did I say anyone needed to give up anything, and to say so is to misinterpret what I clearly posted. I was talking about a full understanding of the range of tools for AJAX. Of course this includes RoR, Dojo etc. Nowhere did I imply it didn't. But it also includes JSF. I am amazed at the degree of misunderstanding and FUD around JSF. Debate seems to fall close to Slashdot levels.

    Dude, look at what you wrote. Are you and the JSF guys really doing anything that revolutionary in the AJAX space? I mean, our Ajax theme for WebWork makes putting together loosely coupled Ajax UI components, but we're building on the great work of Dojo (and adding a bit to it), we're not breaking new ground in Ajax / Javascript and I would never say that you "don't understand the full range of tools available for rich/AJAX interfaces." because you haven't looked at what we've done. I'm sure that, now that I've begun to grok OO Javascript and Ajax that I could figure out what your components are doing in a couple of hours or less, and it's not going to be anything the rest of us aren't doing, so jump off the high horse.
  123. Not professional[ Go to top ]

    I'm sure that, now that I've begun to grok OO Javascript and Ajax that I could figure out what your components are doing in a couple of hours or less, and it's not going to be anything the rest of us aren't doing, so jump off the high horse.

    Look - all I was doing was responding to a post that implied that JSF was basically like 'legacy J2EE/EJB' and irrelevant as the poster was interested in rich interfaces and Web 2.0 technologies.

    The implication was that JSF was not suited to the development of web pages using technologies such as AJAX. Nowhere was I implying that JSF was doing anything special, and I can't see where you picked that up from.

    All I am saying is that if you want to use AJAX as, JSF is one of the options for development. That is all!
    I'm sure that, now that I've begun to grok OO Javascript and Ajax that I could figure out what your components are doing in a couple of hours or less

    I think you are confusing what I am saying. I am not saying that JSF is a tool to help you understand AJAX and how to write JavaScript. All I am saying is that you will be able to produce AJAX-enabled web pages by using the appropriate components from some JSF implementations. Personally, I'm not particularly interested in writing JavaScript manually - I would rather have components do it for me if possible.

    In the same was as I use my ORM to generate SQL, I want my web framework to generate my JavaScript...
    so jump off the high horse.

    I don't think I am on one, but being involved in a debate where people respond to what they think I have posted, and not what I am actually saying is mildly irritating at the very least.
  124. Not professional[ Go to top ]

    In the same was as I use my ORM to generate SQL, I want my web framework to generate my JavaScript...
    +1. And my HTML too. That is, if I am doing a web ui for my app.

    If I ever run into the person who came up with the idea do do apps in the browser ... "To the moon Alice, to the moon".
  125. Not professional[ Go to top ]

    If I ever run into the person who came up with the idea do do apps in the browser ... "To the moon Alice, to the moon".

    +1.

    It is possible w/ today's technology to write webapps that bypass the browser (but deploy from browser), ex JDNC.

    .V
  126. Not professional[ Go to top ]

    If I ever run into the person who came up with the idea do do apps in the browser ... "To the moon Alice, to the moon".
    +1.It is possible w/ today's technology to write webapps that bypass the browser (but deploy from browser), ex JDNC..V
    Doing it right now. Well, not the JDNC part. :)
  127. Not professional[ Go to top ]

    It is possible w/ today's technology to write webapps that bypass the browser (but deploy from browser), ex JDNC.

    Doing it right now. Well, not the JDNC part.

    What are you using Mark?

    .V
  128. Not professional[ Go to top ]

    It is possible w/ today's technology to write webapps that bypass the browser (but deploy from browser), ex JDNC.Doing it right now. Well, not the JDNC part.
    What are you using Mark?.V
    Haven't decided yet, but it will be cajo or hessian or "roll our own" - more than likely A or B.
  129. Not professional[ Go to top ]

    I'm sure that, now that I've begun to grok OO Javascript and Ajax that I could figure out what your components are doing in a couple of hours or less, and it's not going to be anything the rest of us aren't doing, so jump off the high horse.
    Look - all I was doing was responding to a post that implied that JSF was basically like 'legacy J2EE/EJB' and irrelevant as the poster was interested in rich interfaces and Web 2.0 technologies.The implication was that JSF was not suited to the development of web pages using technologies such as AJAX. Nowhere was I implying that JSF was doing anything special, and I can't see where you picked that up from.All I am saying is that if you want to use AJAX as, JSF is one of the options for development. That is all!
    I'm sure that, now that I've begun to grok OO Javascript and Ajax that I could figure out what your components are doing in a couple of hours or less
    I think you are confusing what I am saying. I am not saying that JSF is a tool to help you understand AJAX and how to write JavaScript. All I am saying is that you will be able to produce AJAX-enabled web pages by using the appropriate components from some JSF implementations. Personally, I'm not particularly interested in writing JavaScript manually - I would rather have components do it for me if possible.In the same was as I use my ORM to generate SQL, I want my web framework to generate my JavaScript...
    so jump off the high horse.
    I don't think I am on one, but being involved in a debate where people respond to what they think I have posted, and not what I am actually saying is mildly irritating at the very least.

    Since I know what you meant, I assume it was poor reading comprehension on his part. I thought you were quite clear.

    Jason is very smart but when you talk about things besides WebWork he gets more than a little defensive. I was fully expecting him to spout his normal JSF conspiracy theories thus my earlier jabs about hidden agenda.
  130. Not professional[ Go to top ]

    Since I know what you meant, I assume it was poor reading comprehension on his part. I thought you were quite clear. Jason is very smart but when you talk about things besides WebWork he gets more than a little defensive. I was fully expecting him to spout his normal JSF conspiracy theories thus my earlier jabs about hidden agenda.

    Umm... thanks a pantsload, Chet.

    His attitude was dismissive and saying that you couldn't really understand the full breadth of tools for building Web 2.0 apps without knowing JSF was just stupid. JSF is not an AJAX framework, it's a web framework that may or may not, depending on the implementation, include some AJAX support. JSF has about as much to do with AJAX as WebWork, Ruby on Rails, or any other web framework that uses AJAX. You don't have to know all of them to know how to build Web 2.0 apps.

    I'm not defensive... If you guys want to waste a bunch of cycles on JSF the same way you wasted cycles touting and using Struts classic, then go for it. It's not my time you're burning.
  131. Not professional[ Go to top ]

    Since I know what you meant, I assume it was poor reading comprehension on his part. I thought you were quite clear. Jason is very smart but when you talk about things besides WebWork he gets more than a little defensive. I was fully expecting him to spout his normal JSF conspiracy theories thus my earlier jabs about hidden agenda.
    Umm... thanks a pantsload, Chet.His attitude was dismissive and saying that you couldn't really understand the full breadth of tools for building Web 2.0 apps without knowing JSF was just stupid. JSF is not an AJAX framework, it's a web framework that may or may not, depending on the implementation, include some AJAX support. JSF has about as much to do with AJAX as WebWork, Ruby on Rails, or any other web framework that uses AJAX. You don't have to know all of them to know how to build Web 2.0 apps. I'm not defensive... If you guys want to waste a bunch of cycles on JSF the same way you wasted cycles touting and using Struts classic, then go for it. It's not my time you're burning.

    Who is Chet?

    No problem. There is no way he was saying that. You read what you wanted to read. Look at the comment he was responding too.

    BTW WebWork is a framework not a cult religion. I am not sure if you noticed.

    Just out of curiosity: Do you see no value at all in JSF?

    Can you name one good thing you like?

    I didn't think so.

    Who is close minded?
  132. Not professional[ Go to top ]

    Who is Chet?No problem. There is no way he was saying that. You read what you wanted to read. Look at the comment he was responding too.BTW WebWork is a framework not a cult religion. I am not sure if you noticed.Just out of curiosity: Do you see no value at all in JSF?Can you name one good thing you like?I didn't think so.Who is close minded?

    That was a quote from Fletch, I think...

    I saw what he was responding to, but I also read exactly what was written and found it dismissive and offensive.

    BTW, this thread was never about WebWork. The only one bringing up WebWork over and over is you. Just because I post about something doesn't mean it's about WebWork.

    Do I see anything at all of value in JSF? Hmm... well, it's good that some people are building tools for Java web apps... I think it would have been better if they'd looked a little closer at what other people were doing successfully already, instead of building something from scratch that has to take years to mature.

    There are lots of things I like... Spring, XFire... even Tomcat!

    Of course, I don't sell consulting around things I like, so I don't spend all day talking them up...
  133. Not professional[ Go to top ]

    Of course, I don't sell consulting around things I like, so I don't spend all day talking them up...

    No you just are one of the lead developers on WebWork who never misses an oppurtunity to slam JSF or anyone associated with it. It easier to sell consulting around technologies your target markets actually use.

    You may be right about the WebWork aspect. Every time I hear your name I think WebWork, but looking back you did mention WebWork a few times on your own.

    It doesn't matter this conversation is going no where. I wish you good health and wealth. I will continue to like JSF and you will continue to despise it. This does not mean that you are not smart b/c I think that you are; it just means that we won't see eye to eye on this issue.
  134. Not professional[ Go to top ]

    No you just are one of the lead developers on WebWork who never misses an oppurtunity to slam JSF or anyone associated with it. It easier to sell consulting around technologies your target markets actually use. You may be right about the WebWork aspect. Every time I hear your name I think WebWork, but looking back you did mention WebWork a few times on your own.It doesn't matter this conversation is going no where. I wish you good health and wealth. I will continue to like JSF and you will continue to despise it. This does not mean that you are not smart b/c I think that you are; it just means that we won't see eye to eye on this issue.

    On the "Chet" comment: It's a phrase... it means "thanks a lot" only sarcastically. From looking it looks like it was originally in Wayne's World 2. I threw that in because I thought this part:
    Since I know what you meant, I assume it was poor reading comprehension on his part. I thought you were quite clear. Jason is very smart but when you talk about things besides WebWork he gets more than a little defensive. I was fully expecting him to spout his normal JSF conspiracy theories thus my earlier jabs about hidden agenda.

    was pretty damn rude...

    Anyway.. I'm not slamming JSF. This wasn't about whether JSF is good or bad. I'm also not saying WebWork is better. I'm saying that saying that you don't know the full set of AJAX tools if you don't know JSF is stupid and insulting. Of all of the cool AJAX apps I've seen, very few are even Java, much less JSF.

    Anyway, since we're doing a "My AJAX is bigger than yours"...

    I haven't used it, but I've read about JSF. I looked at the flowchart of the steps for processing a request... It's kind of ridiculous. I will say that AJAX is making stuff like that less relevant, not more. I can put together a page with a bunch of individual parts to it, each of which can make requests back to the server to modify server state and refresh themselves synchronously or asynchronously. Each of those page segments can interact with the rest of the page in a loosely coupled eventing model using publish and subscribe topics in the page. JSF is all about components sending events back to the server and only changing their own state, but updating the whole page. I'd rather just update the parts that changed and not leave the user waiting for 27 steps in a JSF request lifecycle to complete to re-render the whole page. The modular page refresh model is very much request / response though, not a complex component tree re-initializing and re-rendering process.

    So you tell me, why do you want to have the whole page refresh and have to go through the JSF render cycle? Why not REALLY do AJAX and have the page update the parts that have changed (not the whole thing)?
  135. Not professional[ Go to top ]

    No you just are one of the lead developers on WebWork who never misses an oppurtunity to slam JSF or anyone associated with it. It easier to sell consulting around technologies your target markets actually use. You may be right about the WebWork aspect. Every time I hear your name I think WebWork, but looking back you did mention WebWork a few times on your own.It doesn't matter this conversation is going no where. I wish you good health and wealth. I will continue to like JSF and you will continue to despise it. This does not mean that you are not smart b/c I think that you are; it just means that we won't see eye to eye on this issue.
    On the "Chet" comment: It's a phrase... it means "thanks a lot" only sarcastically. From looking it looks like it was originally in Wayne's World 2. I threw that in because I thought this part:
    Since I know what you meant, I assume it was poor reading comprehension on his part. I thought you were quite clear. Jason is very smart but when you talk about things besides WebWork he gets more than a little defensive. I was fully expecting him to spout his normal JSF conspiracy theories thus my earlier jabs about hidden agenda.
    was pretty damn rude...Anyway.. I'm not slamming JSF. This wasn't about whether JSF is good or bad. I'm also not saying WebWork is better. I'm saying that saying that you don't know the full set of AJAX tools if you don't know JSF is stupid and insulting. Of all of the cool AJAX apps I've seen, very few are even Java, much less JSF. Anyway, since we're doing a "My AJAX is bigger than yours"...I haven't used it, but I've read about JSF. I looked at the flowchart of the steps for processing a request... It's kind of ridiculous. I will say that AJAX is making stuff like that less relevant, not more. I can put together a page with a bunch of individual parts to it, each of which can make requests back to the server to modify server state and refresh themselves synchronously or asynchronously. Each of those page segments can interact with the rest of the page in a loosely coupled eventing model using publish and subscribe topics in the page. JSF is all about components sending events back to the server and only changing their own state, but updating the whole page. I'd rather just update the parts that changed and not leave the user waiting for 27 steps in a JSF request lifecycle to complete to re-render the whole page. The modular page refresh model is very much request / response though, not a complex component tree re-initializing and re-rendering process.So you tell me, why do you want to have the whole page refresh and have to go through the JSF render cycle? Why not REALLY do AJAX and have the page update the parts that have changed (not the whole thing)?

    Bacon Powder. (Waynes World lingo for Beg your Pardon). Esss squeeze me.

    What I said was fairly rude, yet you were being fairly rude yourself even before me (IMHO). To me, he was trying to include JSF in the AJAX conversation not exlude anything else. Let's agree to disagree on this point.

    The funny thing is (or sad thing you might say) that I agree with you about JSF. LET ME REPEAT: I AGREE WITH YOU.

    JSF does not have a good backend Axis story (for pure AJAX play anyway). You have to use JSF + something else.

    I also agree that a pure AJAX application does not need JSF at all. I don't think all future apps will be pure AJAX plays.

    It is more likely that they quite a few of them will be hybrid. It is this hybrid app where JSF shines. I imagine that JSF will deliver nice AJAX enabled components: AJAX enabled TreeViews, AJAX enabled pagintated tables, Smart Text Fields with completion etc. where you don't have to keep redrawing the entire page.

    Granted there will be pure AJAX plays, but I think hybrid AJAX or web apps with rich components will do much better at first (market share wise). Generally evolutions works better than revolution for adoption. (Thus the masses that stayed with Struts eventhough WebWork was much better. And the masses who continue to stay with Struts instead of WebWork, JSF or Spring MVC.)

    Currently the best way to build the backend part of the component (the server Axis piece) is to use something like WebWork (or Spring MVC or maybe something like Struts 1.3 which has moved closer to WebWork recenlty--I guess) or something else request based.

    If they do add a backend AJAX story to JSF, it will look like WebWork, or Struts 1.3. This is in line with my earlier comments which you said were sad (not that you are ever rude :o) ).
  136. Not professional[ Go to top ]

    There are lots of things I like... Spring, XFire... even Tomcat! Of course, I don't sell consulting around things I like, so I don't spend all day talking them up...

    BTW I like Spring, Tomcat and XFire too. (See we have some common ground.)
  137. Not professional[ Go to top ]

    Despite my better judgement.
  138. Nobody wins[ Go to top ]

    Nobody wins
  139. Not professional[ Go to top ]

    Despite my better judgement.

    Brilliant!
  140. Not professional[ Go to top ]

    Hey, the picture looks a lot like the guy who created facelets. ;-)
  141. Not professional[ Go to top ]

    Hey, the picture looks a lot like the guy who created facelets. ;-)

    Heheh, yes, I'll admit, but request oriented frameworks, such as Struts and Webwork, makes everyone feel that way...
  142. Not professional[ Go to top ]

    Dude, look at what you wrote. Are you and the JSF guys really doing anything that revolutionary in the AJAX space? I mean, our Ajax theme for WebWork makes putting together loosely coupled Ajax UI components, but we're building on the great work of Dojo (and adding a bit to it), we're not breaking new ground in Ajax / Javascript and I would never say that you "don't understand the full range of tools available for rich/AJAX interfaces." because you haven't looked at what we've done. I'm sure that, now that I've begun to grok OO Javascript and Ajax that I could figure out what your components are doing in a couple of hours or less, and it's not going to be anything the rest of us aren't doing, so jump off the high horse.

    Second that. Thumbs up for Dojo and WW for contributing further than just their own framework.
  143. Not professional[ Go to top ]

    Dude, look at what you wrote. Are you and the JSF guys really doing anything that revolutionary in the AJAX space? I mean, our Ajax theme for WebWork makes putting together loosely coupled Ajax UI components, but we're building on the great work of Dojo (and adding a bit to it), we're not breaking new ground in Ajax / Javascript and I would never say that you "don't understand the full range of tools available for rich/AJAX interfaces." because you haven't looked at what we've done. I'm sure that, now that I've begun to grok OO Javascript and Ajax that I could figure out what your components are doing in a couple of hours or less, and it's not going to be anything the rest of us aren't doing, so jump off the high horse.
    Second that.

    You are seconding a comment that has already been refuted.

    The poster was setting up a 'straw man' argument that JSF was trying to be a 'revolutionary AJAX framework', whereas the point I was making was that JSF was simply yet another framework that allowed AJAX-enabled pages to be developed.
  144. Not professional[ Go to top ]

    You are seconding a comment that has already been refuted.

    Refuted? Really?
  145. Not professional[ Go to top ]

    You are seconding a comment that has already been refuted.
    Refuted? Really?

    http://www.theserverside.com/news/thread.tss?thread_id=37365#190154
  146. They all need to give up and use JSF, obviously.

    I don't get where you got that he said this. It's almost as if you have a secret agenda. Are you some sort of alternative web framework developer? :o)

    Look all he was saying was don't count JSF out of the equation w/o taking a look at it.

    What I think is kinda of funny is AJAX JSF component developer's who use a Servlet as the backend piece for the client JavaScript to talk to. It's obvious to me (not sure if this is the right phrase) that they should be using something like WebWork to handle the AJAX rendering.

    I still think there is a WebWork + JSF story for AJAX components in JSF. Drop a component on a form that renders JavaScript that talks to WebWork. Maybe the WebWork piece delivers up Tacomite XML.

    Tacomite + JSF + WebWork is how I would develop a custom JSF component that used Ajax (I think). Or perhaps Tacomite + JSF + SpringMVC.

    Just a thought... a working example would be better. hmmmm...
  147. They all need to give up and use JSF, obviously.
    I don't get where you got that he said this. It's almost as if you have a secret agenda. Are you some sort of alternative web framework developer? :o)Look all he was saying was don't count JSF out of the equation w/o taking a look at it.What I think is kinda of funny is AJAX JSF component developer's who use a Servlet as the backend piece for the client JavaScript to talk to. It's obvious to me (not sure if this is the right phrase) that they should be using something like WebWork to handle the AJAX rendering.I still think there is a WebWork + JSF story for AJAX components in JSF. Drop a component on a form that renders JavaScript that talks to WebWork. Maybe the WebWork piece delivers up Tacomite XML. Tacomite + JSF + WebWork is how I would develop a custom JSF component that used Ajax (I think). Or perhaps Tacomite + JSF + SpringMVC.Just a thought... a working example would be better. hmmmm...

    I don't think it's funny, I think it's sad... This should be the kind of thing that sparks the thought in your mind "Hey, the web is really about request / response... It's not a Swing app after all!"
  148. They all need to give up and use JSF, obviously.
    I don't get where you got that he said this. It's almost as if you have a secret agenda. Are you some sort of alternative web framework developer? :o)Look all he was saying was don't count JSF out of the equation w/o taking a look at it.What I think is kinda of funny is AJAX JSF component developer's who use a Servlet as the backend piece for the client JavaScript to talk to. It's obvious to me (not sure if this is the right phrase) that they should be using something like WebWork to handle the AJAX rendering.I still think there is a WebWork + JSF story for AJAX components in JSF. Drop a component on a form that renders JavaScript that talks to WebWork. Maybe the WebWork piece delivers up Tacomite XML. Tacomite + JSF + WebWork is how I would develop a custom JSF component that used Ajax (I think). Or perhaps Tacomite + JSF + SpringMVC.Just a thought... a working example would be better. hmmmm...
    I don't think it's funny, I think it's sad... This should be the kind of thing that sparks the thought in your mind "Hey, the web is really about request / response... It's not a Swing app after all!"

    Yes web apps are just about request / response and computers are just about ones and zeros. Did you write WebWork in assembly or Java? I am pretty sure it was Java.

    JSF is a higher level of abstraction for doing component centric web development. It is not for everyone.

    Are you saying that JSF does not have a place? It is WebWork or nothing eh? You sound like a true believer.

    I like WebWork/XWork and hope to use it one day in anger.
  149. I don't think it's funny, I think it's sad... This should be the kind of thing that sparks the thought in your mind "Hey, the web is really about request / response... It's not a Swing app after all!"
    Yes web apps are just about request / response and computers are just about ones and zeros. Did you write WebWork in assembly or Java? I am pretty sure it was Java. JSF is a higher level of abstraction for doing component centric web development.

    I agree completely with Jason. Developing web application is completely limited by the fact that HTTP forces us into a disconnected request/response paradigm. That's just how it is, and we all have to deal with it.

    The argument that component-oriented development is a "higher level of abstraction" for web development, just as Java is a higher level of abstraction that assembly is disengenious. Component-oriented development removes the ability to do certain things that web users expect: namely multi-window operation and seamless back/forward management. Until a component-oriented framework with a good client-side state model solves these problems, I don't see component-oriented development as a step up, but more as a step sideways. You trade some capabilities (I think they're important, others may not, it all depends on what you're building) for others.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  150. Component-oriented development removes the ability to do certain things that web users expect: namely multi-window operation and seamless back/forward management

    I disagree, as there is nothing to stop you combining a component-based model with other frameworks to handle these things. Although JSF can be used as an entire web framework, it need not be. It can be used as a view layer and other code can handle things like multi-window operation. An example of this is Shale.
  151. I disagree, as there is nothing to stop you combining a component-based model with other frameworks to handle these things. Although JSF can be used as an entire web framework, it need not be. It can be used as a view layer and other code can handle things like multi-window operation. An example of this is Shale.

    I think perhaps we are agreeing violently ;) I don't disagree that component frameworks or component techniques have their place, but I don't see them as a complete replacement for, or logical evolution of action oriented development. Side by side use such as you point out tends to agree reinforce this position.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  152. I disagree, as there is nothing to stop you combining a component-based model with other frameworks to handle these things. Although JSF can be used as an entire web framework, it need not be. It can be used as a view layer and other code can handle things like multi-window operation. An example of this is Shale.
    I think perhaps we are agreeing violently ;) I don't disagree that component frameworks or component techniques have their place, but I don't see them as a complete replacement for, or logical evolution of action oriented development. Side by side use such as you point out tends to agree reinforce this position.-Tim FennellStripes: Because web development should just be easier.

    I too am in violent agreement with you. I have no problem using Spring MVC, WebWork and/or maybe even Struts 1.3x. In fact, I don't always get to pick the web framework. I work with clients who work with stuff I've never heard of. I think WebWork has its place as does JSF.

    For many projects, I prefer to use JSF.
  153. I don't disagree that component frameworks or component techniques have their place, but I don't see them as a complete replacement for, or logical evolution of action oriented development.

    Indeed the world is gray.
  154. I don't think it's funny, I think it's sad... This should be the kind of thing that sparks the thought in your mind "Hey, the web is really about request / response... It's not a Swing app after all!"
    Yes web apps are just about request / response and computers are just about ones and zeros. Did you write WebWork in assembly or Java? I am pretty sure it was Java. JSF is a higher level of abstraction for doing component centric web development.
    I agree completely with Jason. Developing web application is completely limited by the fact that HTTP forces us into a disconnected request/response paradigm. That's just how it is, and we all have to deal with it.
    Developing Windows application is limited by the fact that all events in the system are lined up in a message queue and application processes them one by one in the message loop using getMessage() function. Still, one can write a Delphi or VB application without knowing that fact. On the other hand, one could have been using Power Builder and not caring about message loop either. But here is the difference between total shielding from underlying API (what Power Builder does) and providing with great object/component environment above lower-level API (what Delphi does, and VB in less extent).

    In Delphi you still can write plain WinAPI programs, you can write DLLs, or COM servers. You can use Object Pascal or write inline assebly instructions. You can use full power of OOP or hack memory pointers, you can process events on high-level or use raw window HANDLE. That is what great framework is about, it does not limit you if you want to go "classic" way or "hard" way. But if all you need is five forms and a database connection, you can do it in half an hour without even knowing how Windows works.

    The problem with web frameworks that they still cannot deliver the same range of features and ease of use as some desktop environments. They always try to lock a developer in confines of a paradigm that framework author(s) considers the best, the proper, the only one possible.
    The argument that component-oriented development is a "higher level of abstraction" for web development, just as Java is a higher level of abstraction that assembly is disengenious. Component-oriented development removes the ability to do certain things that web users expect: namely multi-window operation and seamless back/forward management.
    This is not true. Even without Ajax.
  155. I don't think it's funny, I think it's sad... This should be the kind of thing that sparks the thought in your mind "Hey, the web is really about request / response... It's not a Swing app after all!"
    Yes web apps are just about request / response and computers are just about ones and zeros. Did you write WebWork in assembly or Java? I am pretty sure it was Java. JSF is a higher level of abstraction for doing component centric web development.
    I agree completely with Jason. Developing web application is completely limited by the fact that HTTP forces us into a disconnected request/response paradigm. That's just how it is, and we all have to deal with it.The argument that component-oriented development is a "higher level of abstraction" for web development, just as Java is a higher level of abstraction that assembly is disengenious. Component-oriented development removes the ability to do certain things that web users expect: namely multi-window operation and seamless back/forward management. Until a component-oriented framework with a good client-side state model solves these problems, I don't see component-oriented development as a step up, but more as a step sideways. You trade some capabilities (I think they're important, others may not, it all depends on what you're building) for others.-Tim FennellStripes: Because web development should just be easier.
    The meaning of disingenuous has been shifting about lately, as if people are unsure of its proper meaning. Generally, it means “insincere” and often seems to be a synonym of cynical or calculating.
    (Dictionary.com)

    You may disagree with me but I assure you that I am sincere in my beliefs. I don't think I would have written a 4 part article series on something I didn't believe in. I am not that Machiavelian.

    You are in the minority of thinking that JSF was not a higher level abstraction even in the anti-JSF crowd. Some might say it is the wrong type of higher level abstraction, but few would argue that it is not a higher level abstraction.

    I am a bit sick of arguing the merits of JSF. I quit.
  156. I am a bit sick of arguing the merits of JSF. I quit.

    Personally I would love everybody just get tired defending JSF and JSF quietly die without making too much disruption and confusion.
  157. I am a bit sick of arguing the merits of JSF. I quit.
    Personally I would love everybody just get tired defending JSF and JSF quietly die without making too much disruption and confusion.

    I don't understand this point of view. If you don't like JSF, don't use it. Some of us like a component model for web development that has the option to render different presentation mechanisms, has multi-vendor support as well as good open source implementations, and with hundreds of pre-written components. If you don't want this, and find JSF confusing and disrupting, no-one is forcing you to use it.

    Debate is a good thing. Trying to prevent developer choice isn't.
  158. I am a bit sick of arguing the merits of JSF. I quit.
    Personally I would love everybody just get tired defending JSF and JSF quietly die without making too much disruption and confusion.

    I meant I quit arguing not that I quit using JSF. I'll let other folks debate and point out why JSF is doing well.

    Since we are talking about death. It reminds me of this:
    Tyler Durden: Listen up, maggots. You are not special. You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else.
    Narrator: On a long enough timeline, the survival rate for everyone drops to zero.

    ;)
  159. How about using none of them![ Go to top ]

    If you put your code within a "frame" work, one day you need to change it: The best option is to use none of them but learn from them. The only good thing about Struts , I found is its use of main controller servlet -- all the rest can be done better by JSTL and other components.
  160. How about using none of them![ Go to top ]

    If you put your code within a "frame" work, one day you need to change it: The best option is to use none of them but learn from them. The only good thing about Struts , I found is its use of main controller servlet -- all the rest can be done better by JSTL and other components.

    This sounds very unproductive. A far better approach in my opinion is to use a framework that encourages the use of POJOs to contain the logic (such as JSF or Wicket), so you are isolating as much as possible from the framework itself. One of the advantages of JSF is that being a JSR there are many implementations, reducing the need to switch between frameworks if there are problems - you can switch between implementations instead. I think that the value of products that implement JSRs is hugely underestimated.
  161. How about using none of them![ Go to top ]

    I haven't tried JSF yet. JSP can do the job for a simple web interface. Freemarker can also be a viable alternative to JSP as far as know.
    Using Struts' main controller with tiles and only one session bean in my application is all what I need. Spring or whatever is unnecessary as far as I am concerned. May be one day SUN will invent a new interface as sexy as FLASH and as interactive as JSP or JSF
  162. How about using none of them![ Go to top ]

    <quote>A far better approach in my opinion is to use a framework that encourages the use of POJOs to contain the logic (such as JSF or Wicket), so you are isolating as much as possible from the framework itself.
    </quote>

    That's what I did, a POJO and Collection backed view layer,
    http://www.theserverside.com/news/thread.tss?thread_id=37365#189768

    So it doesn't matter whether to use Struts or JSP or JSTL.
  163. How about using none of them![ Go to top ]

    <quote>A far better approach in my opinion is to use a framework that encourages the use of POJOs to contain the logic (such as JSF or Wicket), so you are isolating as much as possible from the framework itself.</quote>That's what I did, a POJO and Collection backed view layer, http://www.theserverside.com/news/thread.tss?thread_id=37365#189768</a>So it doesn't matter whether to use Struts or JSP or JSTL.

    My point is that it is usually a waste of time to re-invent the wheel by doing this yourself. When there are such good frameworks already out there, there has to be a very good reason for justifying spending the time doing this.
  164. It is not re-invent the wheel, please read the description carefully.

    I just designed some Java Beans so you don't need to code hundreds of JSPs for Struts Tiles. One JSP can be used to display hundreds domain objects in a standard way. And ActionForm handles the HTML form to domain object mapping automatically.

    You may wonder how do I handle variables? They are in the resource bundle. Instead of coding each JSP displaying domain object, the add-on just use configure to display the configured properties blindly. Yes blindly.

    It is super productive.
  165. JSF/EJB is a tired subject... I do RiA/Web 2.0, etc.
    JSF is certainly not a tired subject. If you do rich interfaces and Web 2.0 you should look into it. There is a considerable amount of effort from several groups and vendors to integrate JSF with AJAX. Here are a few examples.http://www.icesoft.com/products/icefaces.htmlhttp://smirnov.org.ru/en/ajax-jsf.htmlhttps://bpcatalog.dev.java.net/ajax/jsf-ajax/http://www.it-eye.nl/weblog/2005/07/20/jsf-ajax-adffacesnext/I would suggest that if you don't understand JSF then you don't understand the full range of tools available for rich/AJAX interfaces.

    I would agree 100%. JSF has a lot of AJAX activty. This does not exclude other frameworks, but there sure seems to be a lot going on with JSF and AJAX.

    What I like about the component model that JSF (and Tapestry) provide is that a lot of the details of AJAX can be abstracted behind "smart" components.

    I am sure other frameworks WebWork, RIFE, Tapestry, Wicket etc. will have or have an AJAX story.

    There is so much going on in the JSF space that it is plenty hard enough just to keep up, and not just open source but commercial companies too.
  166. Not professional[ Go to top ]

    .. the issue I have is that you opine, opine and opine on technologies you have not used or quite frankly seem to really grasp.You flame technologies you do not grasp.
    So anyone that disagrees with you should not post? Show me a non trivial site you worked on JSF and put in production or other would be a great url about now. If it were up to JSF/EJB, there be not much Java ROI deployed relative to other stacks."technologies you do not grasp"... a bit personal. I think many people qualified to grasp it happen to think it's not good relative to others, so they don't use it. Not becuase I said I would not use it. JSF/EJB is a tired subject... I do RiA/Web 2.0, etc. A framework is not as important as other things on a project. I don't want to grasp for technology iussues on my project, I want it to work so all of the team is focused 100% on the bus. requirments. I wonder if I am underqualified to think that ;-}Struts did it's job and got out of the way..V
    So anyone that disagrees with you should not post?

    No please continue to opine about technologies you have never used. Just expect to get some flack from people who use this stuff on a daily basis.
    Struts did it's job and got out of the way..

    Classic Struts did a poor job of getting out of the way. The "new" Struts looks a lot more like WebWork and Spring MVC. Spring does an amazing job of getting out of the way so much so that the objects you write that work with Spring don't even have to know Spring exists (in many, many cases anyway).

    If you like Struts, please try Spring MVC. You will love it. I swear.

    I can't give WebWork such and endorsement b/c I have not used it in anger yet, but it seems to be quite an improvement over Classic Struts.
  167. Spring does an amazing job of getting out of the way so much so that the objects you write that work with Spring don't even have to know Spring exists (in many, many cases anyway).

    I can say about the same thing for Struts 1.3. Action classes that have to extend Action are a thing of the past. Tag any arbitrary class with the Command interface (see apache commons chain) and you have your business pretty much wired (if you don't forget to be thread-safe, good for scaling). The chain-based new Struts CORE is built the same way. Really smart stuff. Uses Chain-Of-Responsibility (COR) pattern.

    If you like Struts, you will love Struts 1.3, I promise :-)

    I think the new Struts CORE extends the life of Struts substantially. Going from monolithic request processor to modular, configurable, lego-type, declarative-wiring of request-response process.

    I personally value Vic's judgement; he's been disqualifying EJB already at a time when others didn't have that courage.
    I think what helps Spring for adoption is that it comes with some persistence out of the box while Struts doesn't.
  168. Spring does an amazing job of getting out of the way so much so that the objects you write that work with Spring don't even have to know Spring exists (in many, many cases anyway).
    I can say about the same thing for Struts 1.3. Action classes that have to extend Action are a thing of the past. Tag any arbitrary class with the Command interface (see apache commons chain) and you have your business pretty much wired (if you don't forget to be thread-safe, good for scaling). The chain-based new Struts CORE is built the same way. Really smart stuff. Uses Chain-Of-Responsibility (COR) pattern.If you like Struts, you will love Struts 1.3, I promise :-) I think the new Struts CORE extends the life of Struts substantially. Going from monolithic request processor to modular, configurable, lego-type, declarative-wiring of request-response process.I personally value Vic's judgement; he's been disqualifying EJB already at a time when others didn't have that courage.I think what helps Spring for adoption is that it comes with some persistence out of the box while Struts doesn't.

    This is good news, and if it is true you can officially move me out of the anti-Struts camp. Struts 1.3 and beyond may have same legs after all.
  169. Extensions, fixing many of Struts deficiencies, already exist and they are either direct add-ons, or require very trivial changes in the configuration. Some of these extensions provide a serious paradigm shift without breaking compatibility with Struts core or with legacy application code.

    Some examples of useful extension libraries:
    http://formdef.dev.java.net - easy dynaforms, type conversion, validator extension.
    http://strutslive.dev.java.net - uses POJOs instead of form beans, input/output conversion and validation.
    http://struts.sourceforge.net/strutsdialogs - blends page-based techniques like code-behind class and event handling with action-based approach used in Struts.
    http://struts.sourceforge.net/ajaxtags - allows to Ajaxify Struts application.
    http://displaytag.sourceforge.net - not Struts-specific but very useful for lists and tables.

    Travelocity moved their booking system to Linux/Struts in the end of 2003, National/Alamo Car Rental conveted their web-based ordering system to Linux/OAS/Struts in 2004. These and other companies will not jump into another major makeover in at least two-three years, so Struts will stay with us for some time.

    By the way, the mentioned projects were developed at the time, when WebWork, Tapestry and Spring MVC were already available. Why Struts was chosen nevertheless? My bet, it is because Struts was the de-facto standard. So, the next standard framework will be JSF, simply because it IS now a standard, included into J2EE... er, into Java EE, created by an author of the first standard framework.

    Frameworks like Tapestry or Wicket will have the reputation as smart niche tools for those in the know, kind of like Delphi. Frameworks like Stripes will have the reputation like Watcom C++ compiler, fast and simple.

    --
    This response is definetely biased:
    Struts Dialogs: http://struts.sourceforge.net/strutsdialogs
  170. Extensions, fixing many of Struts deficiencies, already exist and they are either direct add-ons, or require very trivial changes in the configuration. Some of these extensions provide a serious paradigm shift without breaking compatibility with Struts core or with legacy application code.Some examples of useful extension libraries:http://formdef.dev.java.net - easy dynaforms, type conversion, validator extension.http://strutslive.dev.java.net - uses POJOs instead of form beans, input/output conversion and validation.http://struts.sourceforge.net/strutsdialogs - blends page-based techniques like code-behind class and event handling with action-based approach used in Struts.http://struts.sourceforge.net/ajaxtags - allows to Ajaxify Struts application.http://displaytag.sourceforge.net - not Struts-specific but very useful for lists and tables.Travelocity moved their booking system to Linux/Struts in the end of 2003, National/Alamo Car Rental conveted their web-based ordering system to Linux/OAS/Struts in 2004. These and other companies will not jump into another major makeover in at least two-three years, so Struts will stay with us for some time.By the way, the mentioned projects were developed at the time, when WebWork, Tapestry and Spring MVC were already available. Why Struts was chosen nevertheless? My bet, it is because Struts was the de-facto standard. So, the next standard framework will be JSF, simply because it IS now a standard, included into J2EE... er, into Java EE, created by an author of the first standard framework. Frameworks like Tapestry or Wicket will have the reputation as smart niche tools for those in the know, kind of like Delphi. Frameworks like Stripes will have the reputation like Watcom C++ compiler, fast and simple.--This response is definetely biased:Struts Dialogs: http://struts.sourceforge.net/strutsdialogs

    I agree. There may be better frameworks, but JSF will be dominant.
  171. Struts in my opine has always been a good basis of a framework, but not a fully-formed one. It provided lots of infrastructure: error messages, MVC plumbing, etc.

    However, struts failed at the next level, which is essentially the syntactic sugar level:
    - the validator was primitive
    - form beans were pure XML config overhead, I always chucked them along with the validator and wrote my own validator and HttpParam->Object instantiation code
    - the taglibs, while important historically, are, well, taglibs. Taglibs are a dead end.
    - preferred JSPs, although they could accomodate other techniques like Velocity if you wrote a custom processing action

    My experiences with JSPs have all ended in disappointment:
    - the EL is far inferior to the evaluation langs used by OGNL or Velocity
    - tag libraries have a cumbersome interface and implement de-facto Domain-Specific Languages that are poor, usually poorly documented, and yet restricted. And those include URLs. Why? Stupid and obfuscating.
    - from a typing standpoint, JSPs require me to hit the shift key far too often
    - the only thing that's good is the dynamic compilation, although scripted macros can accomplish the same goal.

    Thus, JSF and its new generation of JSPs and taglibs will be a failure. I also do not like GUI component-style frameworks because their object count tends to explode, and data layer / prez layer separation tends to break down when there is a code layer to set GUI component states.

    In the end, I hope that AJAX will shift most of this server-side presentation processing to the browser, and revert the server to a more pure data interface layer with minimal session state. Too bad we have to use Javascript, and have to strictly restrict data access on a user-by-user (or role-by-role) basis.
  172. TSS asks: Is Struts going away?[ Go to top ]

    +1 for both Tapestry and Rife. Tapestry is a choice for excellent component design and debugging--it is in production in many very large sites today. I like Rife for the good templating engine, continuations-based stateless model, and their new CRUD generator...very cool stuff and productive.

    I think that we'll wind up using a framework that uses a continuations-based approach, and does HTML-style templating instead of JSP-style.
  173. Which Large Sites use tapestry[ Go to top ]

    Bruce, which large sites use tapestry ?


    thanx
  174. Which Large Sites use tapestry[ Go to top ]

    Bruce, which large sites use tapestry ?thanx

    This site. TSS
  175. Which Large Sites use tapestry[ Go to top ]

    Bruce, which large sites use tapestry ?thanx
    This site. TSS

    I don't know that that's something to be bragging about with the recent performance...

    Also... they hired the creator of the framework to build it for them.

    :-)
  176. Which Large Sites use tapestry[ Go to top ]

    Bruce, which large sites use tapestry ?thanx
    This site. TSS
    I don't know that that's something to be bragging about with the recent performance... Also... they hired the creator of the framework to build it for them.:-)

    I take it then, you didn't follow the postings on performance and stability on TSS recently. It was made clear that the Tapestry framework wasn't the problem. Try to keep your information correct, please.
  177. Which Large Sites use tapestry[ Go to top ]

    Actually, no, but I know it wasn't a problem when the Tapestry redesign was originally rolled out, so...

    I take it then that you are unfamiliar with the concept of a "joke"?
    I take it then, you didn't follow the postings on performance and stability on TSS recently. It was made clear that the Tapestry framework wasn't the problem. Try to keep your information correct, please.
  178. Which Large Sites use tapestry[ Go to top ]

    Actually, no, but I know it wasn't a problem when the Tapestry redesign was originally rolled out, so...I take it then that you are unfamiliar with the concept of a "joke"?
    I take it then, you didn't follow the postings on performance and stability on TSS recently. It was made clear that the Tapestry framework wasn't the problem. Try to keep your information correct, please.

    Joke != FUD. The redesign of TSS involved more architecture components than Tapestry alone.
  179. Which Large Sites use tapestry[ Go to top ]

    Actually, no, but I know it wasn't a problem when the Tapestry redesign was originally rolled out, so...I take it then that you are unfamiliar with the concept of a "joke"?
    I take it then, you didn't follow the postings on performance and stability on TSS recently. It was made clear that the Tapestry framework wasn't the problem. Try to keep your information correct, please.
    Joke != FUD. The redesign of TSS involved more architecture components than Tapestry alone.
    Probably wrong architecture components break TSS, but sometimes developers make mistakes too.
  180. Which Large Sites use tapestry[ Go to top ]

    Bruce, which large sites use tapestry ?thanx
    This site. TSS
    I don't know that that's something to be bragging about with the recent performance... Also... they hired the creator of the framework to build it for them.:-)

    I'm not too happy with what has, and hasn't, happened to TSS since The Middleware Company was bought by TechTarget.

    I've been trying to get the user base to be a bit more vocal about their successes:

    http://wiki.apache.org/jakarta-tapestry/SuccessStories
    http://wiki.apache.org/jakarta-tapestry/PoweredByTapestry

    So I'm not the only one writing Tapestry apps, apparently.
  181. HLS:
         What would you advice to get educated and productive on Tapestry 4 quickly? Will there be any book? It would surely help.

    Also, it would be interesting to see a professional architecture based on Tapestry + Spring + Hibernate - that would interesting to read about.

    Congratulations on a great job.
  182. I am not HLS, but would recommend http://www.agileskills2.org/EWDT/
  183. Small shop or big shop?[ Go to top ]

    I think that it's very important to make a distinction between web applications being built by small shops or big shops?

    Small shops need to be very flexible, be able to quickly deliver and react to the customer's wishes promptly. They need a framework that doesn't make them lose time on standard functionalities that the customer will never see. They can't afford to spent months in a design phase. They need to be able to have small iterative changes in a maintainable code-base. I think this is the niche for the alternative web applications frameworks (RIFE, Rails, Wicket, Tapestry, ...)

    Big shops need to be sure that their huge applications are not tied to the knowledge of individuals. They need to be able to add developers when needed and there shouldn't be a problem at all to find replacements for people that quit. The fun of the individual is less important. It's normal to spend an eternity in design phase and to be rigid about imposing the requirements that came out of this process. This is where standard web applications frameworks come in (JSF, Struts).

    I thus think that neither of them will ever go away if you're asking the question in such a general fashion.

    What's nice is that a lot of the alternative frameworks are of very high quality and come with much better documentation, code quality and framework design than before. Those are not the simple scratch-an-itch open-source projects anymore, but they are suited for lasting developments.
  184. Small shop or big shop?[ Go to top ]

    I think that it's very important to make a distinction between web applications being built by small shops or big shops?Small shops need to be very flexible, be able to quickly deliver and react to the customer's wishes promptly. They need a framework that doesn't make them lose time on standard functionalities that the customer will never see. They can't afford to spent months in a design phase. They need to be able to have small iterative changes in a maintainable code-base. I think this is the niche for the alternative web applications frameworks (RIFE, Rails, Wicket, Tapestry, ...)

    Having used JSF for some time, I can't see how it prevents flexibility or speed of development, or small iterative changes or how it imposes rigid requirements. I also have experienced no loss of time at all on functionalities that the customer never sees.

    There may be valid criticisms of JSF and Struts, but trying to label them as 'big shop' APIs that are slow to use and impose rigid development strategies just doesn't work, as too many of us have seen the opposite.
  185. Small shop or big shop?[ Go to top ]

    Having used JSF for some time, I can't see how it prevents flexibility or speed of development, or small iterative changes or how it imposes rigid requirements. I also have experienced no loss of time at all on functionalities that the customer never sees.There may be valid criticisms of JSF and Struts, but trying to label them as 'big shop' APIs that are slow to use and impose rigid development strategies just doesn't work, as too many of us have seen the opposite.

    Hi Steve, I have also heard a lot of opposite testimonials about JSF, where people really regretted having chosen it for small development. I can't comment on it more though, since I never used it myself.
    I personally think that solutions like Rails and RIFE that provide a full-stack solution with integration of most layers to reduce setup and configuration are much more suitable for small shops that want to deliver quickly.
  186. Small shop or big shop?[ Go to top ]

    Hi Steve, I have also heard a lot of opposite testimonials about JSF, where people really regretted having chosen it for small development. I can't comment on it more though, since I never used it myself. I personally think that solutions like Rails and RIFE that provide a full-stack solution with integration of most layers to reduce setup and configuration are much more suitable for small shops that want to deliver quickly.

    I think there is a huge amount of misunderstanding about JSF. I am not entirely sure why - perhaps the fact that it is a JSR gives it a reputation of being a 'big' system that requires a full IDE to use. My experience is the opposite. After all, there is not much to it for the typical developer. What goes on behind the scenes is quite complex, but that is usually hidden. All the typical developer has to handle is some tag libraries, an XML configuration file and some POJO beans to handle the data behind the views. This sounds simple, and it is - at least I have found it so.

    I think the emphasis on configuration and setup is misplaced. Firstly, it assumes that all projects are started with no existing code around (when I start a JSF project, I use existing configurations and pages as templates). Secondly, my experience of web development is that modifying configuration files is a negligible part of the time spent in development.

    Finally, comparing JSF with Rails and RIFE is not comparing like with like. JSF is simply a view layer. JSF can be cleanly integrated with other layers through Spring.
  187. Small shop or big shop?[ Go to top ]

    Having used JSF for some time, I can't see how it prevents flexibility or speed of development, or small iterative changes or how it imposes rigid requirements. I also have experienced no loss of time at all on functionalities that the customer never sees.There may be valid criticisms of JSF and Struts, but trying to label them as 'big shop' APIs that are slow to use and impose rigid development strategies just doesn't work, as too many of us have seen the opposite.
    Hi Steve, I have also heard a lot of opposite testimonials about JSF, where people really regretted having chosen it for small development. I can't comment on it more though, since I never used it myself. I personally think that solutions like Rails and RIFE that provide a full-stack solution with integration of most layers to reduce setup and configuration are much more suitable for small shops that want to deliver quickly.
    I've used JSF for 2 small (1 developer) apps. I was able to kick them out pretty quick. The second one even more so because I was able to reused knowledge, code and etc from the first one. The only issue I had was the calendar control. :S
  188. Small shop or big shop?[ Go to top ]

    <blockquoteHaving used JSF for some time, I can't see how it prevents flexibility or speed of development, or small iterative changes or how it imposes rigid requirements. I also have experienced no loss of time at all on functionalities that the customer never sees.There may be valid criticisms of JSF and Struts, but trying to label them as 'big shop' APIs that are slow to use and impose rigid development strategies just doesn't work, as too many of us have seen the opposite.
    Maybe small shops go for the best tools, while big shops go for the whole 'replacable code monkey' idea that seems to be the driver of dnd JSF. Sure JSF works; no-one is arguing you can't get the job done. But there's a huge gap between just that and what a lot of developers search for in terms of elegance, maintainability, tool independence, etc.
  189. Small shop or big shop?[ Go to top ]

    Maybe small shops go for the best tools, while big shops go for the whole 'replacable code monkey' idea that seems to be the driver of dnd JSF. Sure JSF works; no-one is arguing you can't get the job done. But there's a huge gap between just that and what a lot of developers search for in terms of elegance, maintainability, tool independence, etc.

    I use JSF because I find it elegant and maintainable. I really like the component and event model. It reminds me of Swing development, and I find it a far more natural way to develop user interfaces than the action-based approach of Struts.

    Sure, you can use JSF in a clumsy 'drag-and-drop' way in some development tools, and I have seen some appalling web interfaces that have resulted from this. However, there is nothing to stop JSF development independent of tools, and this is the way I prefer to work. JSF is certainly tool independent.
  190. Small shop or big shop?[ Go to top ]

    Maybe small shops go for the best tools, while big shops go for the whole 'replacable code monkey' idea that seems to be the driver of dnd JSF. Sure JSF works; no-one is arguing you can't get the job done. But there's a huge gap between just that and what a lot of developers search for in terms of elegance, maintainability, tool independence, etc.
    I use JSF because I find it elegant and maintainable. I really like the component and event model. It reminds me of Swing development, and I find it a far more natural way to develop user interfaces than the action-based approach of Struts.Sure, you can use JSF in a clumsy 'drag-and-drop' way in some development tools, and I have seen some appalling web interfaces that have resulted from this. However, there is nothing to stop JSF development independent of tools, and this is the way I prefer to work. JSF is certainly tool independent.

    a big +1

    JSF is much more intuitive. It feels a lot more like a GUI style development than something like Struts or Spring MVC. In my opinion for doing forms based development it is much more productive.
  191. Small shop or big shop?[ Go to top ]

    JSF is certainly tool independent.

    Yeah. EJB 2 was tool independent too. Such fun!
    a big +1JSF is much more intuitive. It feels a lot more like a GUI style development than something like Struts or Spring MVC. In my opinion for doing forms based development it is much more productive.

    Agreed. I was comparing JSF to other component based alternatives.

    It's not surprising that the big 'JSF rocks!' shouters here are all somehow connected to JSF (bookwriters, comitters, etc).
  192. Small shop or big shop?[ Go to top ]

    JSF is certainly tool independent.
    Yeah. EJB 2 was tool independent too. Such fun!

    A comparison of hand-coding JSF with hand-coding EJB 2 is plain nonsense. JSF involves nothing more than placing tags in a web page and specifying mappings in an XML file. It is certainly no more work than struts (I consider it far easier). So there is no doubt that it is tool independent and can easily be coded outside of an IDE or visual tool.
    It's not surprising that the big 'JSF rocks!' shouters here are all somehow connected to JSF (bookwriters, comitters, etc).

    I don't know if I am considered a 'JSF rocks' shouter, but I have no link to any JSF vendor or book, so this is yet more FUD.
  193. Small shop or big shop?[ Go to top ]

    I don't know if I am considered a 'JSF rocks' shouter, but I have no link to any JSF vendor or book, so this is yet more FUD.

    Well, I have to take that back then in your case.
  194. Small shop or big shop?[ Go to top ]

    I don't know if I am considered a 'JSF rocks' shouter, but I have no link to any JSF vendor or book, so this is yet more FUD.
    Well, I have to take that back then in your case.

    Although... I just take a look at your other comments on TSS, and you are clearly a JSF fan. Which is good; good to know there are actually people that /do/ think JSF is great as it is now other than people that have 'commercial' interest in it.
  195. Small shop or big shop?[ Go to top ]

    I don't know if I am considered a 'JSF rocks' shouter, but I have no link to any JSF vendor or book, so this is yet more FUD.
    Well, I have to take that back then in your case.
    Although... I just take a look at your other comments on TSS, and you are clearly a JSF fan. Which is good; good to know there are actually people that /do/ think JSF is great as it is now other than people that have 'commercial' interest in it.

    I'm actually not that much of a fan. There are things wrong with it - components should have been far easier to write, for example.

    What I am a fan of is the component model of JSF, and the fact that it is a multi-vendor supported JSRs. I think that is a big advantage. Also, I like that it is (for me) a very easy framework to use (I say this after years of Struts development), which is why I find comments about JSF being tool-dependent and EJB-like hard to understand.
  196. Small shop or big shop?[ Go to top ]

    JSF is certainly tool independent.
    Yeah. EJB 2 was tool independent too. Such fun!
    a big +1JSF is much more intuitive. It feels a lot more like a GUI style development than something like Struts or Spring MVC. In my opinion for doing forms based development it is much more productive.
    Agreed. I was comparing JSF to other component based alternatives.It's not surprising that the big 'JSF rocks!' shouters here are all somehow connected to JSF (bookwriters, comitters, etc).

    This is a very weak argument.

    FYI: I have no JSF book and am not a comitter on any Open Source JSF project. I do have a lot of experience using JSF that I am very happy to share.

    I make money consulting for JSF, but am not married to JSF. I would just as happy working on a Spring MVC or WebWork project or for that matter Tapestry.

    There seems to be more JSF work out there than work with other frameworks. For example, we provide Tapestry, JSF and Spring MVC training. We get a lot more calls for JSF training than Spring MVC or Tapestry.

    (We do quite a bit of Spring training but almost no Spring MVC training. I am sure Interface21 gets plenty of calls for Spring MVC training, and Howard gets plenty of calls for Tapestry training.)

    BTW Does being a committer on a project preclude your opinion from being valid? I would think it should validate it. Also book authors don't make much money off of books. I think your assumption b/c you wrote a book on a topic that you cannot be open minded is off.
  197. Validity of an opinion[ Go to top ]

    BTW Does being a committer on a project preclude your opinion from being valid? I would think it should validate it. Also book authors don't make much money off of books. I think your assumption b/c you wrote a book on a topic that you cannot be open minded is off.
    Validate? I do not think so, it just shows level of commitment and indicates strong bias.
    It certainly does not preclude that opinion from being valid, but quite often such high level of commitment makes people deaf to critique and opposite opinions.
    There is nothing wrong with it that is how brain works. When we committed to something we tend to be biased in favor of this thing.
  198. Validity of an opinion[ Go to top ]

    Validate? I do not think so, it just shows level of commitment and indicates strong bias. It certainly does not preclude that opinion from being valid, but quite often such high level of commitment makes people deaf to critique and opposite opinions. There is nothing wrong with it that is how brain works. When we committed to something we tend to be biased in favor of this thing.

    Yeah. Actually, I am a committer and a beginning bookwriter, so I am definitively somewhat baised. But I started out being a committer for a competing framework because I was very unhappy with JSF when it came out and I didn't get enough people interested to start a alternative view implementation (opposed to JSP) back then.
  199. The poll is a little misleading[ Go to top ]

    A lot of people use Spring with JSF, or Spring with Struts, or Spring with Tapestry, etc.

    The poll should have had "Spring MVC" as an option not just Spring.

    Here is the JRoller Poll:

    http://jroller.com/page/RickHigh?entry=alternatives_to_struts

    And here is the Dice Poll (the most important):

    http://jroller.com/page/RickHigh?entry=alternatives_to_struts_the_dice
  200. Request for spam filter on TSS[ Go to top ]

    I think it would be great to have a spam filter on this message board. There are too many self-promoting posts to get any real discussions on the Server Side anymore. I believe their influence is becoming quite insidious to the profession. Every other post nowadays seems to be a thinly disguised promotion of some type.
  201. Request for spam filter on TSS[ Go to top ]

    Are you selling spam filters? ;-)
  202. Moved to Apache Cocoon[ Go to top ]

    Separation of concerns is easier to achieve. Cocoon Forms let you define reusable web GUI components. It has better validation framework together with a flexible binding framework working on Java Beans as well as XML which let you deal with type objects. Continuation support now integrated by Struts, and recent transparent AJAX support to name a few benefits.

    Although not easier to get into than Struts it's worth the effort and it is a framework older than Struts ! Finally I do not see why Struts would disappear: First given the large user base it has. Second its architecture is flexible enough to cleanly integrate most of Cocoon advantages I mentioned here above.
  203. Unscientific == meaningless[ Go to top ]

    Self-selected sample without a complete set of choices. This poll has no meaning whatsoever with respect to Stuts.
  204. Entering the mine field[ Go to top ]

    I lead a small team of developers who, as a team, are looking to transition across from a CGI environment to a Java-based environment.

    We've built up a foundation knowledge of Java, and have gained some experience in JSP and Servlets - and are doing OK.

    We're about to embark on our first java-based web project, and (wanting to start on the right foot) I want us to implement the app using a framework. I had opted to start with Struts because, although I gather it's not the latest technology, it was the only framework I could find with good coverage and with the backing of tech. books we could use to start us off.

    My questions are:
    > are we starting off on the wrong foot?
    > what's fundamentally wrong with Struts?
    > what is the best alternative?

    We're already making a huge leap moving in to Java, and I don't want to adopt standards/techniques that are already being considered out-dated/questionnable - meaning we'll have to re-learn in the near future.

    Any guidance appreciated!!
  205. Entering the mine field[ Go to top ]

    There is nothing fundamentally wrong in Struts, forget it, it is just usual "framework war" on TSS.
  206. Entering the mine field[ Go to top ]

    There is nothing fundamentally wrong in Struts, forget it, it is just usual "framework war" on TSS.

    The total absence of meaningfull messages is what I consider fundamentally wrong in struts.
  207. Real Point of Web Frameworks Poll[ Go to top ]

    I am the author of the poll in question and would like to mention that it is clear to me that classic Struts is not going away. There is so much "legacy" code now written in Struts that it is the COBOL of the Java industry (sorry for the cliche). And, most large consulting companies and corporations will stick with Struts because there is a large base of developers to draw from to staff their 50-100 person projects.

    But, the question I am most interested in is what alternatives to Struts do developers want to move to--not what are they currently using. If they are happy with Struts, that is fine. Many developers are not, though, and this is reflected in the large and growing number of Web frameworks available.

    As expected, JSF and Spring (MVC) are neck-in-neck in the poll at this point in time.