|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 81
Messages: 81
Messages: 81
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Differences between Struts and JSF?
A reader sent in a question: "What's the difference between Struts and JSF? Which one is better?" That's a ... question. What do TSS readers say? What about other frameworks? How would you sum up the primary strengths and weaknesses in a comparison?
(As food for thought, consider Fred Daoud's web frameworks conference, in the same vein as David Rupp's "conference" for languages...)
|
|
|
Message #241696
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
At the risk of sounding too harsh...
Both frameworks are abysmal. It's like asking someone if they prefer Hitler to Stalin. A better question might be, "If you could use any web framework besides Struts or JSF at your current job, what would it be and why?" Another option would be, "If you are currently satisfied with Struts or JSF, please explain why so we can laugh at you."
|
|
|
Message #241700
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: At the risk of sounding too harsh...
Both frameworks are abysmal. It's like asking someone if they prefer Hitler to Stalin. A better question might be, "If you could use any web framework besides Struts or JSF at your current job, what would it be and why?" Another option would be, "If you are currently satisfied with Struts or JSF, please explain why so we can laugh at you."
May I ask: what do you use? I won't laugh I just want to know any better option.
|
|
|
Message #241702
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Looks like a post from the deeply past. Who cares about what is a difference between two those ones now? There are many new frameworks that pretend to be known. Let them to fight between each other.
-
Sergey
JSFTutorials.net
JBoss RichFaces
|
|
|
Message #241704
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'd go JSF/Seam
Neither framework is perfect. I actually like JSF for it's view components, so laugh away. My team members all prefer it as well. While using it, I found at least a dozen "features" that could have been better designed or more thought out. However, being able to add ajax-enabled features and rich widgets with virtually no effort on my part, makes up for it's overall cumbersome design. Seam also has a lot of great potential which I haven't been able to explore fully just yet.
I dislike Struts quite a bit. I haven't used it since the 1.x days, so cannot comment on the most recent releases.
I'm also curious as to the superior framework, Marc. Please have your laugh and share with us your infinite wisdom on where so many of us have gone wrong.
|
|
|
Message #241706
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I vote for GWT
Imho GWT is the best at the moment.
It is designed for Ajax.
It is designed by people who proved that they are best in Ajax.
It has reach set of UI controls (and there are a lot of free additional controls on market)
It can let you write client side code in Java and debug it without dealing with JavaScript.
You can write unit tests for UI.
It is very simple (I've never imagine ajax framework can be that simple).
It is very Object Oriented. You make develop it terms of classes that support inheritance not in terms of Components.
It is Open Source project.
Drawbacks of GWT - no commercial support.
|
|
|
Message #241708
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
webwork user here
we are using webwork since 1.x, and move to struts, because webwork guy move to struts.
and we love it, because the technology is not amazing to fast like JSF, dont know what happen in the future of JSF, will this tech become heavy complex
but i am learning JSF for review.
|
|
|
Message #241709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Routing around the hyperbole and actually trying to answer the question...
The key differences between the two are the base paradigms that underly each platform.
Specifically, JSF is a "component" framework whereas Struts is an "action" framework.
What does that mean?
In a component framework, artifacts that are rendered on the page are initially developed as individual components, much like in modern GUI "fat client" libraries. You have components, they have events, and your code is written to work with those events against the components.
Most of the time, in mainstream development, your code is pretty much ignorant of the HTTP request cycle and processing.
Struts (both 1 and 2) are action frameworks. In essence they give you the ability to map URLs to activities and code on the back end. Here, the layout and workflow tends to be more page oriented. As a developer you tend to interact with the HTTP request cycle directly, though Struts 2 helps isolate at least the binding of the request data to the action implementation classes.
Action frameworks tend to be much "thinner" in how they stand between your code and the raw HTTP request compared to component frameworks.
For those people just cutting their teeth on web development, the component frameworks (especially with good tooling) can be much more approachable, as the tools tend to hide the heavy weight nature of the component frameworks. But, on the downside, their size and their "square peg in to round hole" nature of turning HTTP requests in to the rough equivalent of mouse clicks mean there's more complexity to try to understand if and when the framework starts misbehaving or getting in the way.
But, to be fair, frameworks like ASP.NET and JSF are popular because novices can get quick success with them with the modern tools.
Old School HTTP wranglers may simply be more comfortable with action frameworks, simply because they've been through the crucible of understanding how HTTP requests are structured. Action frameworks tend to work better with "pretty" urls (though component frameworks are getting better at his). Action framework coders can have more control of the structure and presentation of URLs, since their systems are more intimately tied to them compared to a component framework.
As a basic guideline, I find the action frameworks are better for "web sites", site like this one, sites that focus on delivering content to the user. Where it's mostly a "read only" experience for the end user who is likely to want to bookmark things, come back to arbitrarily deep pages, etc.
But the component frameworks are better for "web apps". CRUD screens, back office applications, lots of forms and controls, etc. Here, the workflow is more controlled. You tend to not get to a "detail" screen with going through the "list" screen or "header" screen first, for example.
It's nice to be able to just drag and drop a grid component on to a form, add a couple of buttons and point it as a DB table to get "instant" results. But these apps don't bookmark well, HATE the "refresh button", may behave poorly with the back button, etc. Overall, they can not be very good citizens when working with the web browser.
So, if it were me, I'd write a blog in a action framework like Struts 2 (or even better, Stripes), but I'd write an accounting package in JSF.
|
|
|
Message #241710
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Looks like a post from the deeply past. Who cares about what is a difference between two those ones now? There are many new frameworks that pretend to be known. Let them to fight between each other.
-
Sergey
JSFTutorials.net
JBoss RichFaces
Can we debate VHS vs Beta next?
|
|
|
Message #241713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Using plain JSF does not give you any value addition. Availability of ready made components in JSF based rich frameworks (ICEFaces, RichFaces and a few others) is where it pays off.
You can't easily mix and match components from different JSF based frameworks yet, but hopefully it will move towards that.
|
|
|
Message #241712
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Seriously, though
JSF was designed by the same folks who developed Struts, applying the lessons they learned from doing Struts. David Geary, at least, pretty much disavows Struts. You'll find JSF to be more flexible in many areas, as revealed in this (serious) comparison:
http://websphere.sys-con.com/read/46516.htm
P.S. If you are new to this forum, you may be surprised to find that the majority of answers to serious questions are smart-alecky, beside the point, and often vulgar.
|
|
|
Message #241714
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
There's way too much focus on those two frameworks recently. Everyone tries to push them and everyone seems to hate them. At the same time whole web world goes in the same direction. Even PHP finally starts to get it. Despite all that, my personal preference is Stripes framework. How much more easy can it get?
|
|
|
Message #241715
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I'd go JSF/Seam
Steve, I will never claim to have "infinite wisdom". However, I can recognize a turd pretty easily and lets face it, that doesn't take a genius. Seriously, during your experiences with JSF, you haven't sat there and wondered why you have to deal with numerous XML files and the high learning curve of JSF just to spit out a simple web page? Why they have to wrap JSF with other frameworks like Facelets and Seam just to keep the smell down? The problem with the Java community is that it's gotten way too comfortable with unnecessary complexity. This is what the Rails snobs laugh at all the time and, at least in that regard, they are absolutely right.
As for my framework of choice, I like Wicket. It's component based, there's no XML, HTML stays HTML so GUI developers can maintain it themselves, it has Ajax components out of the box, small learning curve (although the online docs could be better), auto session management, etc.
|
|
|
Message #241718
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
WebObjects, Tapestry, and Wicket
Apple's WebObjects is still the best web framework I've come across, but it's commercial ($699) and not open source. It's disappointing that the OSS community hasn't produced anything as elegant or powerful. The two best open source web frameworks I've come across are Tapestry and Wicket (both Apache projects). Like WebObjects, they're both component-based, and unlike JSF, reasonably well-architected and easy to get started with.
If you're open to trying something more esoteric, you could also learn Scala and try Lift, but it's pretty new, and so still not something most developers are ready to use in production applications (yet).
|
|
|
Message #241720
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Looks like a post from the deeply past. Who cares about what is a difference between two those ones now? There are many new frameworks that pretend to be known. Let them to fight between each other.
-
Sergey
JSFTutorials.net
JBoss RichFaces
Can we debate VHS vs Beta next?
Did you see a "new" keyword in my post?
|
|
|
Message #241721
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for GWT
Imho GWT is the best at the moment.
It is designed for Ajax.
It is designed by people who proved that they are best in Ajax.
It has reach set of UI controls (and there are a lot of free additional controls on market)
It can let you write client side code in Java and debug it without dealing with JavaScript.
You can write unit tests for UI.
It is very simple (I've never imagine ajax framework can be that simple).
It is very Object Oriented. You make develop it terms of classes that support inheritance not in terms of Components.
It is Open Source project.
You forgot the most important point that keeps this stuff still alive - it is promoted by Google.
Drawbacks of GWT - no commercial support.
Last time, Google has a strange tendency to kill any commercial initiatives. Good example is "My Maps" that killed tons of new mashup-oriented startups.
|
|
|
Message #241722
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Grails!
I vote for Grails.
It's action-based, but very easy to create tags that can have their own 'controller' and 'view'. All of the view templates can be written as plain XML/ HTML etc. There is _no_ XML configuration and URL mapping is done through a simple configuration mechanism. It is easy to get up an running without hiding too much of the environment from the user.
|
|
|
Message #241725
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Looks like a post from the deeply past. Who cares about what is a difference between two those ones now? There are many new frameworks that pretend to be known. Let them to fight between each other.
-
Sergey
JSFTutorials.net
JBoss RichFaces
Can we debate VHS vs Beta next?
Did you see a "new" keyword in my post?
Yes. I was just furthering your "who cares" argument.
|
|
|
Message #241728
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF, Struts, blech
DWR + Dojo!
I'm done with Struts, JSF, and other heavyweight MVC frameworks.
|
|
|
Message #241734
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for GWT
First, I'd like to say that these are only my opinions (can be right or wrong).
Imho GWT is the best at the moment.
...
It has reach set of UI controls (and there are a lot of free additional controls on market)
I don't think so. I think RichFaces & Trinidad have more components (I don't provide the link to rf & trinidad live demos because I don't want to persuade you that rf & trinidad have more components than gwt).
It can let you write client side code in Java and debug it without dealing with JavaScript. That's what I like in gwt.
You can write unit tests for UI. If I use a jsf component set, that set guarantees me that all the generated javascript code works correctly. Then, why do I need to test if those components work correctly or not?It is very simple (I've never imagine ajax framework can be that simple). Maybe, it took me less time to learn gwt than jsf.
It is Open Source project. Is there any commercial jsf implementation? There are a few commercial jsf component sets, but all the free jsf component sets are enough, I assume.
A few questions for gwt users:
1. any way to not compile the whole project if there is only one change in one java file in the client directory?
2. it took me 37s on my PIV 3Ghz with hyper threading technology machine to send 200 rows of 5 columns each from the server to the gwt client and display them in a flex table. any way to make it faster? (don't ask me to reduce the 200 to 20. 200 is a beautiful number that the client wants). it will take me less than 5s if I use jsp.
|
|
|
Message #241737
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clearly...
...the winner is emacs.
and_open_braces_go_here() => {
{ <== not here
2, or 4 spaces for indentation are better than 5 (or 8, god forbid), but ANY number is better than tabs.
And of course, camelCasingIsForPansyPascalJunkiesAndDotNetGoobs.
What'd I miss?
|
|
|
Message #241744
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
They both suck
I use Spring Webflow (SWF), since it has the notion of a conversation -- whereas Struts does not.
My next choice would be Seam, although I haven't used that much yet. All I really know is that Seam also has the notion of a conversation.
Struts is also 'forward' based whereas SWF implements PRG (Post Redirect Get) out of the box.
Since SWF also provides flow, conversation, and flash scopes, the form backing object also stays a lot cleaner (than say, Spring MVC or Struts form backing objects), and so you feel less dirty passing a SWF command object down to the business logic layer. Command objects under SWF start to quite closely resemble the GOF command object pattern.
For me, JSF sort of missed the point. Web development isn't so much about a single page, but the flow between pages which everything except SWF and Seam seem to handle abysmally.
I'm also looking at http://extjs.com with interest. Looks damn impressive. (
|
|
|
Message #241743
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
not the only drawbacks
GWT only allows Java 1.4 code for the client side. Also it is limited in the API's that it supports, which is understandable, but you need to be very careful.
|
|
|
Message #241748
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Hi,
I used Struts 1.x, and a lot of WebWork 2 (Struts 2)... I also evaluated GWT, Wicket, Tapestry, Stripes...
but forget all of them, the Click framework is definitely the most simple and easy to use and learn. It has a lot of components out of the box, good documentation, it is page oriented (but can be used as a action framework too)... it looks like wicket but it is more simple. See the examples and source code for yourself:
http://www.avoka.com:8080/click-examples/home.htm
|
|
|
Message #241750
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket online doc
As for my framework of choice, I like Wicket. It's component based, there's no XML, HTML stays HTML so GUI developers can maintain it themselves, it has Ajax components out of the box, small learning curve (although the online docs could be better), auto session management, etc.
To complement the online docs, I've written some tutorials
on Wicket at http://www.agileskills2.org/EWDW/chapters1-3.pdf.
|
|
|
Message #241749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Action-centric frameworks have components too - taglibs. They just never seemed to take off beyond struts taglibs and jstl. You would never think to extend the struts taglibs but that is what you can do (more easily) with JSF components by writing your own, extending, renderers, etc.
The architectural smell about JSF is the tight coupling with everything: committees, servlet and jsp specs, with other component libraries, specific dependencies on implementations, the need to tack on other third party libraries to make it useful - facelets. Tack on tools to get that sweet smell of vendor lock to top it all off.
I like SpringMVC just because it's so light, portable, and decoupled.
|
|
|
Message #241755
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nice analysis
Routing around the hyperbole and actually trying to answer the question...
The key differences between the two are the base paradigms that underly each platform.
Specifically, JSF is a "component" framework whereas Struts is an "action" framework.
What does that mean?
In a component framework, artifacts that are rendered on the page are initially developed as individual components, much like in modern GUI "fat client" libraries. You have components, they have events, and your code is written to work with those events against the components.
Most of the time, in mainstream development, your code is pretty much ignorant of the HTTP request cycle and processing.
Struts (both 1 and 2) are action frameworks. In essence they give you the ability to map URLs to activities and code on the back end. Here, the layout and workflow tends to be more page oriented. As a developer you tend to interact with the HTTP request cycle directly, though Struts 2 helps isolate at least the binding of the request data to the action implementation classes.
Action frameworks tend to be much "thinner" in how they stand between your code and the raw HTTP request compared to component frameworks.
For those people just cutting their teeth on web development, the component frameworks (especially with good tooling) can be much more approachable, as the tools tend to hide the heavy weight nature of the component frameworks. But, on the downside, their size and their "square peg in to round hole" nature of turning HTTP requests in to the rough equivalent of mouse clicks mean there's more complexity to try to understand if and when the framework starts misbehaving or getting in the way.
But, to be fair, frameworks like ASP.NET and JSF are popular because novices can get quick success with them with the modern tools.
Old School HTTP wranglers may simply be more comfortable with action frameworks, simply because they've been through the crucible of understanding how HTTP requests are structured. Action frameworks tend to work better with "pretty" urls (though component frameworks are getting better at his). Action framework coders can have more control of the structure and presentation of URLs, since their systems are more intimately tied to them compared to a component framework.
As a basic guideline, I find the action frameworks are better for "web sites", site like this one, sites that focus on delivering content to the user. Where it's mostly a "read only" experience for the end user who is likely to want to bookmark things, come back to arbitrarily deep pages, etc.
But the component frameworks are better for "web apps". CRUD screens, back office applications, lots of forms and controls, etc. Here, the workflow is more controlled. You tend to not get to a "detail" screen with going through the "list" screen or "header" screen first, for example.
It's nice to be able to just drag and drop a grid component on to a form, add a couple of buttons and point it as a DB table to get "instant" results. But these apps don't bookmark well, HATE the "refresh button", may behave poorly with the back button, etc. Overall, they can not be very good citizens when working with the web browser.
So, if it were me, I'd write a blog in a action framework like Struts 2 (or even better, Stripes), but I'd write an accounting package in JSF.
Wow Will! After a long time I got to read some sensible analysis on technology than usual incoherent claptrap.
|
|
|
Message #241756
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for GWT
Drawbacks of GWT - no commercial support.
Hi Mark.
Have you checked out the support in Seam for calling ajax-enabled serverside components from GWT? It's pretty smooth..
|
|
|
Message #241757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Great post Will! If you don't mind, I'd like to add it to the Struts 2 FAQ as it perfectly answers the question of when to choose an action-based or component-based framework; I'll even leave the Stripes bit in ;)
The only point I'd add is that action-based frameworks, Struts 2 in particular, are a better match for Rest-oriented designs and client-side heavy designs that use Dojo and other libraries to consume server-side JSON/XML services. For example, I'm writing a Struts 2 plugin that simplifies writing Rest resources and automatically supports multiple data representation formats so a Dojo component could consume JSON while a third-party client could use XML. Since you need full control over the URL and response headers, action-based frameworks are a great fit.
|
|
|
Message #241760
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
it's also depend on your team
I don't think that it only depend on the webapp type, component vs action, but also on the dev team,
personally if I have a small team with guru's, I will use velocity,
with velocity you can create your own ui component and your own navigation controller, and adapt it to each webapp
I think that each web framework represent the vision of the one hwo developp it,
velocity let me adapt my component/controller to each webapp I create
|
|
|
Message #241765
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Slight correction ...
Apple's WebObjects is still the best web framework I've come across, but it's commercial ($699) and not open source.
I think you will find that WebObjects is now free (and has been for some time). The recommended development environment is now one of the popular Java IDEs (e.g. Eclipse) with a couple of open-source tools to assist (with setting up the OR map and configuring Web pages).
Cheers,
Ashley.
|
|
|
Message #241768
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No Ajax
Hi,
unfortunately not, this is on of the drawbacks of click. You must create your own components and override the toString() method to generate some ajax stuff...
|
|
|
Message #241769
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Hi,
I used Struts 1.x, and a lot of WebWork 2 (Struts 2)... I also evaluated GWT, Wicket, Tapestry, Stripes...
but forget all of them, the Click framework is definitely the most simple and easy to use and learn. It has a lot of components out of the box, good documentation, it is page oriented (but can be used as a action framework too)... it looks like wicket but it is more simple. See the examples and source code for yourself:
http://www.avoka.com:8080/click-examples/home.htm
Yes Click is very easy and intuitive, the only downside being Strong Ajax support.
|
|
|
Message #241770
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: At the risk of sounding too harsh...
. . . . . "If you are currently satisfied with Struts or JSF, please explain why so we can laugh at you."
LOL!
|
|
|
Message #241777
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: At the risk of sounding too harsh...
Both frameworks are abysmal. It's like asking someone if they prefer Hitler to Stalin. A better question might be, "If you could use any web framework besides Struts or JSF at your current job, what would it be and why?" Another option would be, "If you are currently satisfied with Struts or JSF, please explain why so we can laugh at you."
Good one!!
|
|
|
Message #241779
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for GWT
I vote for Spring MVC. Moved away from struts 2 years ago, and have been happily using spring mvc ever since.
|
|
|
Message #241786
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Grails!
A show of hands of people that have used a light framework with an awesome javascript library like jQuery.
A show of hands of people that after using the light framework with jQuery would go back to JSF.
|
|
|
Message #241787
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for GWT
Imho GWT is the best at the moment.
...
It has reach set of UI controls (and there are a lot of free additional controls on market)
I don't think so. I think RichFaces & Trinidad have more components (I don't provide the link to rf & trinidad live demos because I don't want to persuade you that rf & trinidad have more components than gwt).
GWT components from different vendors can be used together.
Try to use IceFaces with RichFaces.
You can write unit tests for UI. If I use a jsf component set, that set guarantees me that all the generated javascript code works correctly. Then, why do I need to test if those components work correctly or not?
What if you misused compoent, or created your own and want to test?
What if you want to test client side logic?
There are many cases where you need client side debugging.
re:1. any way to not compile the whole project if there is only one change in one java file in the client directory?
No, but you can make the compilation process much faster.
While developing build only for one browser and add more memory to gwt compiler.
it took me 37s on my PIV 3Ghz with hyper threading technology machine to send 200 rows of 5 columns each from the server to the gwt client and display them in a flex table. any way to make it faster? (don't ask me to reduce the 200 to 20. 200 is a beautiful number that the client wants). it will take me less than 5s if I use jsp.
It takes time not to send but to display.
That's because of client side rendering.
Try to use text in cells, not objects.
If your application still not fast enough you'll have to
draw rows on server and send html on client. (ugly but works).
--Mark
|
|
|
Message #241789
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Great post Will! If you don't mind, I'd like to add it to the Struts 2 FAQ as it perfectly answers the question of when to choose an action-based or component-based framework; I'll even leave the Stripes bit in ;)
Sure, free free to copy it wholesale in to the FAQ if you like.
The only point I'd add is that action-based frameworks, Struts 2 in particular, are a better match for Rest-oriented designs and client-side heavy designs that use Dojo and other libraries to consume server-side JSON/XML services.
Yes, of course. This is lightly implied by the mention of how an action framework has more control over the URLs. I was simply trying to answer the question at hand rather than go down in to the depths of the further ramifications of the frameworks beyond your base requirements for web applications.
|
|
|
Message #241790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Action-centric frameworks have components too - taglibs. They just never seemed to take off beyond struts taglibs and jstl.
You haven't seen my code. I make extensive use of Tag Files in building our pages, and think that they are one of the unsung heroes of modern JSP. Our pages are very clean because of it.
In the end, though, they don't offer the granularity of control or events that a full bore component framework offers. If they did, then I would have written my own component framework.
And also, tag libs are JSP specific, whereas JSP is a only one of many rendering options (though Freemarker and Velocity have similar mechanisms). With the action frameworks, the rendering mechanism can more easily by separated from the actual back end framework.
|
|
|
Message #241793
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for GWT
another one here for GWT. At this point i really can't stand doing webapp work in anything else.
previously used: jsp/servlets, tapestry 3, jsf, rails/jror, springmvc
adrian
|
|
|
Message #241796
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One vote for Struts 2
I've used both JSF and Struts 2 quite a bit.
JSF: Plenty of special IDEs and control libraries to choose from. Although, I found it very hard to get these tools to do what I wanted them to do and ended up coding most functionality from scratch. I really had a bad experience with JSF. If you don't mind working in the Microsoft universe, ASP.NET is a much better framework for this type of novice-friendly component-rich development.
Struts 2: Very simple, elegant, and flexible. If you are comfortable with raw HTML/JS/CSS, and tend to dislike "heavy" tools and frameworks that get in the way, this is for you. This works really well with client-side GUI libraries (Scriptaculous, Yui, etc). Very much designed around test-driven development. I love it and feel very productive with it so far.
GWT: I have limited experimental use with this, but I wanted to point out that this is for a really different type of app. GWT is more of an RIA framework along the lines of Flash, Flex, Silverlight, JavaFX, while Struts and JSF are for more traditional web development and compete with PHP, Rails, and ASP.NET.
|
|
|
Message #241803
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
It's nice to be able to just drag and drop a grid component on to a form, add a couple of buttons and point it as a DB table to get "instant" results. But these apps don't bookmark well, HATE the "refresh button", may behave poorly with the back button, etc. Overall, they can not be very good citizens when working with the web browser.
So, if it were me, I'd write a blog in a action framework like Struts 2 (or even better, Stripes), but I'd write an accounting package in JSF.
Excellent post Will. Thank you for increasing the signal-to-noise ratio of this thread.
JSF is complex, but so is Swing. In both cases, the complexity of these GUI development frameworks or toolkits also an indication of their power.
I think some developers new to JSF may be frustrated by the learning curve, but I can safely say at this stage (having climbed it myself) that the rewards are huge. JSF truly separates UI design from programming, meaning Web designers and Java developers can do the things they do best within the same framework.
I love being able to drag-and-drop a command button onto my page in Dreamweaver, wire it up to an EJB3 stateful session bean with some EL, load the view in my browser, click the button, and debug my code in Eclipse. Leveraging the full power of the Java EE stack from your UI is awesome.
The criticism that you need other frameworks to make JSF usable completely misses the point. JSF was designed for extensibility, and frameworks like Facelets and Seam take full advantage of that to add new features to the framework, such as advanced view composition, binding UI components to EJBs, and much more.
Those efforts are also helping to define new standards for enterprise Java-based Web development and are leading the way to enhancements to the JSF framework. JSF is still young, and is evolving. Third-party frameworks like Facelets and Seam are a clear indication of this, and the wide range of UI component libraries promote innovation and reusability.
As for the back button issue, I thought we solved that problem with the Post-Redirect-Get pattern. As for bookmarking, I'm leaning towards REST principles and pull-style MVC to make my URLs easier to work with. Have you looked at the Seam RESTful blog application example?
Ian Hlavats
JSFToolbox for Dreamweaver
UI Design with JSF, Dreamweaver, and the JSFToolbox
|
|
|
Message #241804
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for GWT
Thanks Mark for some advices. I hope you don't bother giving some more detailed advices.While developing build only for one browser and add more memory to gwt compiler Add more memory to the gwt compiler means -Xmx1024m, isn't it? And how can I tell gwt compiler to create the javascript for IE only? (if you don't have time to answer, a link to some page telling that is much appreciated).
|
|
|
Message #241806
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry 5
I've been evaluating the latest frameworks to use on an upcoming project. I've looked at Spring MVC, Seam, Stripes, Struts 2, Wicket, and finally Tapestry 5.
I'm currently in the process of building a prototype with Tapestry 5 and I gotta say I'm impressed. It's basically a better Wicket...more reliance on annotations and great IoC support. No base classes to extend, all PoJo and clean separation of UI.
|
|
|
Message #241808
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for GWT
Thanks Mark for some advices. I hope you don't bother giving some more detailed advices.While developing build only for one browser and add more memory to gwt compiler Add more memory to the gwt compiler means -Xmx1024m, isn't it? And how can I tell gwt compiler to create the javascript for IE only? (if you don't have time to answer, a link to some page telling that is much appreciated).
During development I recomend to compile to Firefox or IE for one language. By default GWT compiles to all browsers for all languages.
Add this to your .gwt.xml file
<extend-property name="locale" values="en_UK"/>
<set-property name="user.agent" value="gecko"/>
<!-- in case you use ugly m$ browser for development
<set-property name="user.agent" values="ie6"/>
-->
Good luck ;-)
PS
One more coin to GWT
GWT forum is extreemly user friendly (comparing to Hibernate forum).
|
|
|
Message #241811
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5
Tapestry 5. It's basically a better Wicket...
Are you sure it's better than wicket? We have switched from JSF to Wicket. We didn't evaluate Tapestry... I have heard it's quite complex.
|
|
|
Message #241813
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Forget XML-frameworks
Instead you should consider a framework where UI:s are developed in Java. Currently available options are: GWT, IT Mill Toolkit 4, Echo2 and Thinwire.
Upcoming IT Mill Toolkit 5 will combine the best of server-side and client-side Java UI development: http://forum.itmill.com/posts/list/318.page
|
|
|
Message #241819
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
struts and components
what I find a little funny is people saying Struts is all action based. Fact is, you can do component based development with Struts... well, if you use the nested tag library. But only a few people were open minded enough to listen to me back in the day (oh well, the world's loss)
...but with the nested tags, you really can separate out complete components, and hook them all up on the server. Include them in a component fashion in the UI, and it's all married back for you through the tag library itself. Very usable. Some people have used it for this very ability to manage very large object structures (including true recursion)... but "popular" was not a term you could pin on the nested tags (and I sleep at night knowing that just because it wasn't popular, didn't mean it wasn't a wickedly productive way to do things :)
Also, the nested tags boiled down the tags to a much simpler form. Just ask the people that did "get" the nested tags mojo if they like developing with Struts in a component fashion, they are out there.
|
|
|
Message #241823
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5
I too thought that the previous versions of Tapestry were overly complex, but Tapestry 5 has been rewritten from the ground up and is not even trying to be compatible with the previous versions. It's clean, simple, elegant and powerful...clearly a step in the right direction.
http://tapestry.apache.org/tapestry5/
|
|
|
Message #241824
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
I, for one, before have started using WebWork had longterm experience with plethora Java frameworks including classic Struts 1, few implementations of JSF including ADF, Spring MVC, Stripes etc. Starting to work with WebWork 2 was like enlightenment. All, simply all problems I had with those farmeworks were solved here, in lightweight, elegant way. Simply one of the best piece of software I've ever seen. I'm amazed how simple, elegant and powerful WW is. Never ever look back.
Speaking about JSF and other "controls" oriented frameworks like ASP.NET. I cannot understand who actually is using it for real life projects, except most simple ones? Unless You are using standard functionality (which is in most cases, especially in JSF, is just rudimentary) be prepared for hard work. Want something different from "standard behavior"? Want to integrate two frameworks? Welcome to hell ;).
|
|
|
Message #241825
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I vote for Server-Centric architecture
It is strange to compare GWT with Struts and JSF. GWT is client-centric architecture, while the others are server-centric. Client-centric is better for light-weight applications/websites. Otherwise, GWT is tend to bring back the age of fat clients if you design it carelessly. That said, too many codes will be written at the client and then open up security/maintenance headache. It is the common problems in fat client/server architecture. No mention JavaScript is notorious for its bad performance.
Try to create a moderate big table with GWT and compare it with JSF/Struts. If you want to use load-on-demand with GWT, you are throwing stones on your nails. On the other hand, you can use JSF's data model directly.
For security, try to access, say, Paypal with GWT. Or, dare you?
There are a lot of server-centric frameworks. My personal preference is ZK. It is the most intuitive yet powerful framework I ever tried.
|
|
|
Message #241827
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What about JSF 2.0?
The architectural smell about JSF is the tight coupling with everything: committees, servlet and jsp specs, with other component libraries, specific dependencies on implementations, the need to tack on other third party libraries to make it useful - facelets. Tack on tools to get that sweet smell of vendor lock to top it all off.
I like SpringMVC just because it's so light, portable, and decoupled.
FYI, JSF 2.0 takes the best of all those addons and builds them into JSF. JSP will no longer be the default view technology. The replacement will be built from a combination of Facelets + JSFTemplating + Clay. The Managed Beans functionality is being replaced by WebBeans -- a combination of Seam component model + Google Guice. WebBeans is kind of like Spring (same sort of idea) but does things differently. The UI component model is being completely redesigned for simplicity. Built in AJAX support is a top priority. The JSF 2.0 expert group has been studying other web frameworks such as Wicket and even Ruby on Rails for inspiration.
So JSF is coupled to servlets, but SpingMVC and every other web framework isn't? You know JSF being tied to other JSR standard makes it portable. That is the whole point of every JSR standard. You are not locked into any one vendor. All Java EE5 app servers support the same JSR standards if they want to be certified. The Java EE5 certification is must more strict than the J2EE 1.4 certification.
+1 for JSF. I like JSF just because it's so portable, decoupled, and JSF 2.0 will be light.
|
|
|
Message #241826
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for Server-Centric architecture
It is strange to compare GWT with Struts and JSF. GWT is client-centric architecture, while the others are server-centric.
Correction - GWT is not client centric. It is client-server.
That said, too many codes will be written at the client and then open up security/maintenance headache. It is the common problems in fat client/server architecture.
UI logic, not security logic should be implemented in client part. Nobody forces you to do security checks on client
No mention JavaScript is notorious for its bad performance.
Rendering on client saves CPU time of your server.
More over, no server neither client have to rerender page each on click.
Try to create a moderate big table with GWT and compare it with JSF/Struts. If you want to use load-on-demand with GWT, you are throwing stones on your nails. On the other hand, you can use JSF's data model directly.
Have you ever tried to use big table in IceFaces or Infragestics? Or any other AJAX JSF solution?
For security, try to access, say, Paypal with GWT. Or, dare you?
What problems did you have with paypal? ;-)
|
|
|
Message #241832
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for Server-Centric architecture
Rendering on client saves CPU time of your server.
More over, no server neither client have to rerender page each on click.
In an AJAX world, what's a "click"?
To really gain what you're talking about, you need to migrate away from a page-oriented flow whereas most apps still use AJAX as a supplementary facet of web application development.
In addition, the mechanics of GWT basically require subsequent requests on load to populate dynamic-server based content (your clicks are driven by code instead of by the user). In a JSF/traditional call, you can simply render everything up front in the first request-- lending itself as being actually more efficient than GWT for a majority of web apps.
|
|
|
Message #241863
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What about JSF 2.0?
Yeah, those all sounds good. But sorry for being sarcastic here, is JSF 2.0 going to be released some time with the current decade? Any guess on by that time, what other better alternatives will be there?
|
|
|
Message #241881
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for Server-Centric architecture
Rendering on client saves CPU time of your server.
More over, no server neither client have to rerender page each on click.
In an AJAX world, what's a "click"?
Same as in NOT AJAX world ;-)
To really gain what you're talking about, you need to migrate away from a page-oriented flow whereas most apps still use AJAX as a supplementary facet of web application development.
That's because most web apps are written on LAMP.
In addition, the mechanics of GWT basically require subsequent requests on load to populate dynamic-server based content (your clicks are driven by code instead of by the user). In a JSF/traditional call, you can simply render everything up front in the first request-- lending itself as being actually more efficient than GWT for a majority of web apps.
Do you REALLY think that to rerender whole page just to validate user input is more efficient?
I'm not talking about how it ugly looks to user.
|
|
|
Message #241883
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I vote for Server-Centric architecture
Do you REALLY think that to rerender whole page just to validate user input is more efficient?
I'm not talking about how it ugly looks to user.
No, I don't. Even LAMP solutions can do client-side validation. The only optimization a GWT-like deployment offers is when you want to provide multiple views over the same data-- not requiring another request to the server. Often these use cases are still supplemented by secondary AJAX functionality without locking your application into a different development paradigm. That simple, secondary AJAX functionality can be fulfilled by near every web-framework out there and isn't purely a benefit owned by GWT.
|
|
|
Message #241893
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Well, if it weren't for bad programmers. . .
I enforce Struts usage not because it's easy to use; it's not.
I enforce Struts usage not because it's easy to learn; it's not.
I enforce Struts usage because at least it imposes some semblance of MVC, although I have yet to meet a developer who hasn't found some way to screw this up too. . .
|
|
|
Message #241935
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The view of the competitivity
A good framework is one that is cheap to use over the short, medium, and long term.
As private companies are now evolving in a global and extremly competitive world, developers will save their jobs by adopting cost efficient frameworks around these 3 horizons.
Short term:
The upfront learning cost of a good framework must be as cheap as possible. This means should require the smallest footprint in terms of time to be efficient to start delivering web applications on top of it.
Medium term:
A good framework will have to be extensible. New pages can be designed at low cost. New widgets can be integrated cheaply (time and money wise).
Long term:
This is the most difficult to achieve: Applications designed with a good framework must be maintainable. MVC is one way of achieving this but it so easily wrongly implemented. The language plays a significant role here. The ability to find developers on the technology as well.
In the proprietary world, my personal intuition is that ASP.NET is emerging as a winner.
In the free world, the picture is more complex. Taking the long term horizon, it seems a Java-based framework is a good candidate. Ruby on Rails developers are not widely available globally yet for example.
So it seems that we are looking at a Java based framework.
Taking the short term horizon, it seems that J2EE based frameworks are too costly. A core java developer needs weeks to understands the way HTTP, servlets, tag libs, EJBs and the like. I place JSF in this category. Structs is in the same line: It takes time(=money) to learn it.
Spring is a step in the right direction, but its MVC implementation is only alleviating the pain.
Let me share some thoughts from an other angle:
A company can take a young software engineer right out of school and start building rich gui applications (with frameworks like swing or swt). Why cannot we figure out a way to develop a web application using the same simplicity ?.
Answers to this question are starting to emerge in the java free world:
- Tapestry, Wicket, GWT, RAP an others.
In my opinion, none of them do answer the medium term horizon: They lack real extensibility.
Who will win ? Tought to say.
I start to have a significant experience with GWT. Out of the box, it lacks professional looking controls. GWT-Ext is a beginning of answer, but this is still way too cutting-edge for a conservative company.
I don't think there is a clean winner yet, but the winner will be the one adopting a GWT like approach with a choice of javascript/ajax controls wide enough to build very professional and dynamic applications as we can do with Swing or SWT.
My 2 cents,
Sebastien Marc.
|
|
|
Message #241972
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Diffs
As for the back button issue, I thought we solved that problem with the Post-Redirect-Get pattern.
The Post-Redirect-Get pattern only really works in the Web 1.0 world. With Web 2.0 (i.e.: AJAX), that all falls apart.
As for frameworks, the only one I have truly been impressed with is Stripes. I was able to get up to speed with it in 20 minutes. Interestingly, Stripes uses what's already available as of Java 1.5 and servlet 2.4 (annotations, generics, JSTL, etc...) and takes it to the fullest potential (or close to it). You don't have to completely learn everything all over again with it.
In a sense, there really was not ever a need for JSF. We already had custom tags to create components with. JSP was not the problem, scriptlets were and JSTL fixed that. Besides, JSF *is* also action-based under the hood like everything else. It just *also* happens to have a complicated component framework and touts itself as "component-based".
|
|
|
Message #241982
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I vote for ZK
Best server-centric RIA solutions I found so far. If you know how to develop event-driven application, you'll find it very easy to use. Great support, too.
|
|
|
Message #242021
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5
Tapestry 5. It's basically a better Wicket...
Are you sure it's better than wicket? We have switched from JSF to Wicket. We didn't evaluate Tapestry... I have heard it's quite complex.
Nah it's not (but as a Wicket developer, I'm biased). Tapestry 5's Ajax support still isn't great and Wicket is way more dynamic. The only thing imho you might like better about Tapestry 5 is that you can get away with writing less code.
|
|
|
Message #242023
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5
I've been evaluating the latest frameworks to use on an upcoming project. I've looked at Spring MVC, Seam, Stripes, Struts 2, Wicket, and finally Tapestry 5.
I'm currently in the process of building a prototype with Tapestry 5 and I gotta say I'm impressed. It's basically a better Wicket...more reliance on annotations and great IoC support. No base classes to extend, all PoJo and clean separation of UI.
I don't mind anyone liking Tapestry 5 better than Wicket. But I don't agree with the arguments you give here.
Why is 'more relience on annotations' a good thing? I disagree.
And I'm sure Tapestry 5 has great IoC support, but Wicket has that as well. In fact, IoC is supported in a general fashion, so you can plug in Spring or Guice (both already available) or whatever lib you like.
Clean separation of UI is something both frameworks support and in fact Wicket is a bit more zealous in that separation (which you may or may not like).
Using base classes (but not required abstract base classes like Tapestry had before!) instead of interfaces actually makes sense sometimes. With base classes, you have finer control over what you expose how and you can better guarantee contracts. Even those base classes are 'pojos'. Furthermore, Wicket only requires components to extend base classes (and for good reasons). Most other things are based on interfaces, including behaviors, which are Wicket's way to support object composition.
|
|
|
Message #242024
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Forget XML-frameworks
Instead you should consider a framework where UI:s are developed in Java. Currently available options are: GWT, IT Mill Toolkit 4, Echo2 and Thinwire.
With Wicket, the only thing you don't do in Java is layout management (for which you use plain HTML and CSS). Layout management in Java can be both convenient (if you're UI requirements are modest) or a PITA (when you're deviating from the mean).
|
|
|
Message #242025
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Differences between Struts and JSF?
Hi,
I used Struts 1.x, and a lot of WebWork 2 (Struts 2)... I also evaluated GWT, Wicket, Tapestry, Stripes...
but forget all of them, the Click framework is definitely the most simple and easy to use and learn. It has a lot of components out of the box, good documentation, it is page oriented (but can be used as a action framework too)... it looks like wicket but it is more simple. See the examples and source code for yourself:
http://www.avoka.com:8080/click-examples/home.htm
Yes Click is very easy and intuitive, the only downside being Strong Ajax support.
One of the best things about Click imho is that the code base is tiny, making it very easy to trace back errors and making you less dependent on a magical box.
But The other side of simplicity is that it won't help you as much with complex scenarios. And that's one of Wicket's best parts: it scales really well for development.
|
|
|
Message #242047
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What about JSF 2.0?
Yeah, those all sounds good. But sorry for being sarcastic here, is JSF 2.0 going to be released some time with the current decade? Any guess on by that time, what other better alternatives will be there?
The JCP page for JSF 2.0 says that there will be a public review in 3 months, final spec in April (with a beta RI), then the release timed with Java EE 6 (Q3 2008). Those who use Sun's Application Server (GlassFish) like we do will be able to take advantage of Java EE 6 as soon as it's available. The rest will have to wait another 6+ months for their vendor to support it.
I'm looking forward to JSF 2.0, WebBeans, EJB 3.1, JPA 2.0, Servlets 3.0, etc. Very exciting stuff.
|
|
|
Message #242049
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What about JSF 2.0?
Yeah, those all sounds good. But sorry for being sarcastic here, is JSF 2.0 going to be released some time with the current decade? Any guess on by that time, what other better alternatives will be there?
The JCP page for JSF 2.0 says that there will be a public review in 3 months, final spec in April (with a beta RI), then the release timed with Java EE 6 (Q3 2008). Those who use Sun's Application Server (GlassFish) like we do will be able to take advantage of Java EE 6 as soon as it's available. The rest will have to wait another 6+ months for their vendor to support it.
I'm looking forward to JSF 2.0, WebBeans, EJB 3.1, JPA 2.0, Servlets 3.0, etc. Very exciting stuff.
That time line basically says you don't even need to think about it now. 6+ months is a very long time on a tech watch. Q3 2008? Forget about it, that means it's irrelevant now.
|
|
|
Message #242057
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Client must not be bogged down with Javascript!
Rendering on client saves CPU time of your server.
More over, no server neither client have to rerender page each on click.
The trouble is customers can outright reject your work if javascript bogs down their web client, I had it happen to me, fool!
It is often much faster (for page download and render time) and more efficient to write proper optimised server code (and data storage) which the client can make requests to, the browser should not be treated as a heavy Javascript client.
Visitors do give a shit about page download and render time, too long and they are gone, even for intranets!
|
|
|
Message #242081
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What about JSF 2.0?
That time line basically says you don't even need to think about it now. 6+ months is a very long time on a tech watch. Q3 2008? Forget about it, that means it's irrelevant now.
I am happy with JSF 1.2 and use it in production today. I am looking forward to JSF 2.0, and completely disagree with those who say that JSF 1.2 is terrible.
|
|
|
Message #242110
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Layout management
For layouts, both declarative (in HTML) as well as programmed layouts should be supported and mixable. This allows you to use the best tools for all situations.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
