|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 206
Messages: 206
Messages: 206
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
TSS asks: Is Struts going away?
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?
|
|
|
Message #189651
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About.com polls are limited to 5 choices
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.
|
|
|
Message #189652
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About.com polls are limited to 5 choices
It sure seems like there are still a bunch of employers hiring for Struts if you check the job sites.
|
|
|
Message #189654
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Unlikely...
...especially as this topic was posted on your homepage just above one entitled "Java.net Article on Using Ajax with Struts".
|
|
|
Message #189655
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Unlikely...
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.
|
|
|
Message #189656
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Employers hiring for Struts?
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.
|
|
|
Message #189659
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Employers hiring for Struts?
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....
|
|
|
Message #189660
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Employers hiring for Struts?
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.
|
|
|
Message #189661
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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.
|
|
|
Message #189662
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS asks: Is Struts going away?
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.
|
|
|
Message #189663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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.
|
|
|
Message #189664
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Employers hiring for Struts?
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.
|
|
|
Message #189665
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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.
|
|
|
Message #189666
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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?
|
|
|
Message #189667
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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.
|
|
|
Message #189668
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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
|
|
|
Message #189669
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Should Struts be going away?
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.
|
|
|
Message #189673
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
To develop what?
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
|
|
|
Message #189679
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
coding... is NOT the future for developers...
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 ???
|
|
|
Message #189681
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Switched to Tapestry and Never going back
I think that says it all. Components are the only way to go.
|
|
|
Message #189683
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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
|
|
|
Message #189694
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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?
|
|
|
Message #189698
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rails !
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 :)
|
|
|
Message #189704
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why is it funny?
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.
|
|
|
Message #189705
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
coding... is NOT the future for developers...
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.
|
|
|
Message #189708
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rails !
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.
|
|
|
Message #189709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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.
|
|
|
Message #189713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
would love to switch but...
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.
|
|
|
Message #189715
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks are silver bullets
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.
|
|
|
Message #189716
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Speaking of Polls being fair
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.
|
|
|
Message #189719
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks are silver bullets
...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.
|
|
|
Message #189721
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rails !
True, true and true... Good points.
(However, I'm putting a high weight on "Fun" for this type of project ;))
|
|
|
Message #189722
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: Frameworks are silver bullet
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.
|
|
|
Message #189723
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Switched to Tapestry and Never going back
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.
|
|
|
Message #189724
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks are silver bullets
...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.
|
|
|
Message #189726
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rails !
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.
|
|
|
Message #189736
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I agree completely with Paul
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.
|
|
|
Message #189738
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks are silver bullets
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.
|
|
|
Message #189739
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Additional evidence & contradictions?
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.
|
|
|
Message #189742
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Struts will not die tomorrow; when it dies, JSF will be King.
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
|
|
|
Message #189745
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
+1 Struts will not die tomorrow; when it dies, JSF will be King.
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.
|
|
|
Message #189749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Struts as a good half-framework
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.
|
|
|
Message #189751
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fun is important!
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.
|
|
|
Message #189754
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS asks: Is Struts going away?
+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.
|
|
|
Message #189761
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fun is important!
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.
|
|
|
Message #189768
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Simplified Struts Development
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.
|
|
|
Message #189772
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Additional evidence &amp; contradictions?
/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.
|
|
|
Message #189773
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Additional evidence &amp;amp; contradictions?
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@virtua.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@jsfcentral.com, and you could get your story published and win a free copy of JavaServer Faces in Action!
|
|
|
Message #189774
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Switched to Tapestry and Never going back
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@virtua.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@jsfcentral.com, and you could get your story published and win a free copy of JavaServer Faces in Action!
|
|
|
Message #189776
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189777
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Switched to Tapestry and Never going back
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@virtua.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@jsfcentral.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/
|
|
|
Message #189778
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Additional evidence &amp;amp; contradictions?
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.
|
|
|
Message #189779
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Boring is safe!
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.
|
|
|
Message #189780
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Additional evidence & contradictions?
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.
|
|
|
Message #189782
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in JSF everything is POST
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 :)
|
|
|
Message #189787
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket
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.
|
|
|
Message #189790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in JSF everything is POST
... 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...
|
|
|
Message #189792
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Small shop or big shop?
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.
|
|
|
Message #189799
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in JSF everything is POST
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 :)
|
|
|
Message #189802
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Small shop or big shop?
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.
|
|
|
Message #189809
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Javascript dependency
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.
|
|
|
Message #189810
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF basically does the same
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.
|
|
|
Message #189811
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Small shop or big shop?
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.
|
|
|
Message #189815
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Small shop or big shop?
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.
|
|
|
Message #189820
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189826
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189829
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189830
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189832
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Struts CORE 1.3 is great!
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.
|
|
|
Message #189833
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189838
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Small shop or big shop?
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
|
|
|
Message #189847
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189855
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rails !
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)... :)
|
|
|
Message #189856
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in JSF everything is POST
...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.
|
|
|
Message #189858
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in JSF everything is POST
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.
|
|
|
Message #189862
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in JSF everything is POST
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.
|
|
|
Message #189876
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Actually the myfaces
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.
|
|
|
Message #189884
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket
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
|
|
|
Message #189885
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fun is important!
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.
|
|
|
Message #189886
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Which Large Sites use tapestry
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.
:-)
|
|
|
Message #189887
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in JSF everything is POST
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.
|
|
|
Message #189888
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189890
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189892
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Which Large Sites use tapestry
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.
|
|
|
Message #189893
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Request for spam filter on TSS
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.
|
|
|
Message #189898
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Which Large Sites use tapestry
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.
|
|
|
Message #189905
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks are silver bullets
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/
|
|
|
Message #189906
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Which Large Sites use tapestry
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.
|
|
|
Message #189908
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
|
Message #189909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks are silver bullets
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.
|
|
|
Message #189910
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Employers hiring for Struts?
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.
|
|
|
Message #189916
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF and Portlets (response to Jason)
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.
|
|
|
Message #189924
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
in JSF everything is POST
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
|
|
|
Message #189926
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Moved to Apache Cocoon
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.
|
|
|
Message #189932
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Unscientific == meaningless
Self-selected sample without a complete set of choices. This poll has no meaning whatsoever with respect to Stuts.
|
|
|
Message #189937
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
leveraging html experts
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.
|
|
|
Message #189940
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks are silver bullets
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
|
|
|
Message #189941
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Entering the mine field
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!!
|
|
|
Message #189942
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks are silver bullets
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.
|
|
|
Message #189944
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Entering the mine field
There is nothing fundamentally wrong in Struts, forget it, it is just usual "framework war" on TSS.
|
|
|
Message #189945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Entering the mine field
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.
|
|
|
Message #189954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
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
|
|
|
Message #189958
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
Yes, Spring is a very good anti EJB framework (it is good from political point of view).
|
|
|
Message #189961
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
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).
|
|
|
Message #189963
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
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@struts.apache.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
|
|
|
Message #189964
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
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)
|
|
|
Message #189965
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
BTW, it looks like Struts will be the next enemy, or doe's it have integration with Spring ?
|
|
|
Message #189966
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
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.
|
|
|
Message #189967
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
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.
|
|
|
Message #189968
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not professional
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
|
|
|
Message #189971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
specifics please, WebWork, Struts, JSF, Spring MVC
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.
|
|
