|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 16
Messages: 16
Messages: 16
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Tech Talk: Ed Burns on JSF 1.2
Ed Burns sat down with TSS at JavaOne 2006 to discuss JSF 1.2 and its place in the world of web frameworks. Issues covered include scalability, development environments, Ajax (of course!), and a little about the idea behind JSF's extensibility.
Talking about JSF's reputation for poor performance, Ed said:TSS.com: One of the concerns around AJAX and JSF is scalability with small requests going back and forth - how does JSF address that?
Ed Burns: Okay. There are two sides of that question. First is the transport layer, the cost of doing many a small connections, and the other one is the server side memory footprint. JSF, one of the value adds is that you can have state when you need it, that is user interface state when you need it, but it turns out a lot of times, you don't -- so having a model where you can pay the cost only when you need it rather than every time is a valuable asset.
So, let me be a little more concrete about that. If you have one part of the user interface that wants to affect change in another part, for example the classic list is where you have a list of items and you are adding stuff to an inventory and you have at the top of the page your shopping cart, right? And you want to be able to do that over AJAX, so there is no submit. There is state involved there, so in order to send back the shopping cart item, you have to know what the current price is, and so there, in that case, you need state.
So, you have to deal with some strategies for managing the state transactions and make them be less costly, but there are ways to do it because the JSF model has a very flexible architecture. So you can plug in your own state management and in fact, the ADF framework that was donated from Oracle to MyFaces has some state management techniques that we are going to be leveraging for the next version of the spec. [Editor's note: believe it or not, we did know that we put this online yesterday and not today. I just didn't, um, manage to get the newspost in the right queue, or something like that. *cough*]
|
|
|
Message #225729
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF faces some challenges but has potential
I think the talk touched on the majority of challenges facing JSF but provided few solutions. Ed touched on most of the isssues but provided few real answers for the problems people are dealing with when trying to deliver JSF solutions.
1. The out-of-the-box JSF component feature set is too weak to deliver a substantial project. Currently the only set of components having the necessary functional coverage and robustness are ADF.
2. The standard set of components need to evolve, please don't limit functionality based on out-dated browsers as stated in the interview. If JSF tries to be all things to all browsers it will fail. That's what render-kits are for, let people address older browsers with render-kits. For example, not all ADF components support telnet and the documentation elaborates. Build your specification based on common end-user expectations, not on a least common denominator.
3. The combination of AJAX + JSF to deliver components will make or break JSF. The industry needs to quickly settle on one standard implementation of AJAX. If components from different vendors cannot co-exist on the same page, the promise of JSF will be lost.
4. The state saving issues associated with JSF need to be addressed quickly. The current options of SESSION and REQUEST scope are too limiting. Developers need the concept of at least a conversational/process scope and this scope needs to sit on a caching system. Now that the community has worked out Java Persistence for model state, maybe the community can work out Java caching for controller state.
5. The proliferation and uncertainty of Java Web 2.0 frameworks frustrates most companies and moves them towards .NET. The community needs to rally behind a single framework (JSF). One of the major vendors needs to step up to the plate and deliver a productive development environment with a rich set of components for that framework.
6. The JCP needs to move faster to deliver the capability the development community needs to put these standards into production environments. In this regard, JSF 2.0 needs to aggressively fill in the gaps that it does not currently address. JSF 1.2 did not accomplish that, it just stabilized the 1.0 version.
|
|
|
Message #225751
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF faces some challenges but has potential
The industry needs to quickly settle on one standard implementation of AJAX.
Probably the major reason why there are a bunch of good Ajax alternatives now is because they were freely competing without the burden of standardization and big company politics. I think we should keep it that way for a while.
The state saving issues associated with JSF need to be addressed quickly. The current options of SESSION and REQUEST scope are too limiting. Developers need the concept of at least a conversational/process scope and this scope needs to sit on a caching system.
So why process scope? Wouldn't that be just a word for a scope with a user-defined life time? And do you need that to address scalability issues, and if so, would that solve issues you actually experience or issues you just anticipate, or do you need it to support the programming model you are looking for?
The proliferation and uncertainty of Java Web 2.0 frameworks frustrates most companies and moves them towards .NET.
That's an interesting statement of which the validity I doubt. You can actually turn it around and say .NET developers are moving towards Java as they get frustrated by .NET's lack of choice. It's that simple rule of choice: if you don't know what you want, too much choice is frustrating. However, if you know what you're looking for, abundant choice is exactly what you want. I for one am very happy with all the choice I have with Java, and even though a lot of effort is wasted, competition amongst all those frameworks definitively pushes them to deliver good, innovative products.
One of the major vendors needs to step up to the plate and deliver a productive development environment with a rich set of components for that framework.
I think they already did that and in fact are doing it today (though multiple major vendors).
6. The JCP needs to move faster to deliver the capability the development community needs to put these standards into production environments. In this regard, JSF 2.0 needs to aggressively fill in the gaps that it does not currently address. JSF 1.2 did not accomplish that, it just stabilized the 1.0 version.
I think JCP should learn from past mistakes and evolve best of breed projects rather then drawing up standards from scratch. At least for software frameworks.
In the case of JSF: they have seen significant iterations in a limited amount of time, so my hunch is - even though I'm not a JSF user - they are working hard to facilitate the community.
|
|
|
Message #225785
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF faces some challenges but has potential
Probably the major reason why there are a bunch of good Ajax alternatives now is because they were freely competing without the burden of standardization and big company politics. I think we should keep it that way for a while.
I do not disagree with this statement. My point is directed towards inter-operability of components within a component based system like JSF when each component is using a different Ajax implementation. When I do a project I pick an approach. If that approach is JSF then I want to be able to pick the components I want to use. I must be assured that all of these components will play well together and this is NOT the case today. If not then I'm down to having to choose a vendor's component suite and ocked into a pre-determine UI capability or would have to write my own.
So why process scope? Wouldn't that be just a word for a scope with a user-defined life time? And do you need that to address scalability issues, and if so, would that solve issues you actually experience or issues you just anticipate, or do you need it to support the programming model you are looking for?
My expectation is that JSF would be expanded to accomodate an expanded set of scopes or pluggable scopes. I can achieve this today by using a VariableResolve but that is a lot of work. Management of scope IS a real scalability issue for anyone who has deployed a major application. As mentioned, Seam has a good solution and ADF a crude version for this but it needs to be addressed by the specification.
That's an interesting statement of which the validity I doubt. You can actually turn it around and say .NET developers are moving towards Java as they get frustrated by .NET's lack of choice. It's that simple rule of choice: if you don't know what you want, too much choice is frustrating. However, if you know what you're looking for, abundant choice is exactly what you want. I for one am very happy with all the choice I have with Java, and even though a lot of effort is wasted, competition amongst all those frameworks definitively pushes them to deliver good, innovative products.
No doubt there have been .NET people frustrated by lack of choice but my experience (maybe not yours) is that uncertainty does not sell at most companies. Microsoft's pitch, which has merit, is that they deliver productivity and solutions. I am no .NET fan but the java community must be realistic. Competetition is great up to a point. Maybe your point is that JCP needs to be more agressive in backing a winner and promoting innovation.
|
|
|
Message #225832
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF sucks...and has no hope
I have some experience with JSF, now using it on my second project.
I will never recommend JSF again.
1. Tremendously and unnecessarily complicated lifecycle. It's required to understand in detail how the lifecycle works to do even relatively simple things (of course you don't need it for an absolutely trivial "hello world" type stuff, but in real life you need to know it for even a moderately easy business app).
2. HORRIBLE, HORRIBLE error messages. Terrible output from the logger. WARNING: blah blah??? what??? What exactly is the problem in human terms? What line of jsp is it happening at? What are suggested fixes? What part of lifecycle is it happening it? What is going???? SEVERE: blah blah can't find row = 0? What is that??? Where? table component? Which one? What line number? Etc.
3. SILENT errors... what the?? If you don't configure h:messages or t:messages, and in some cases even IF you configure them, some errors are subtly and silently swallowed. Is some event listener derailing execution? SHOW ME in the log! What's going on?? Silent validation errors? What is going on?? The default should be SCREAMING LOUD (with line number and suggested fix) error. You should have to configure it to turn it OFF (not to turn it ON).
4. Useless GUI support. We use BEA Workshop and it sucks horribly. All our pages look NOTHING like what we designed them! Tabbed pane renders each tab *below* the next tab. WHAT IS THAT??? That's horrible.
5. verbatim??? subview??? WHAT IS THAT JUNK??? This is 2007 guys, please! WAKE UP. Don't tell me "facelets". I download 1 framework and it should be complete. Don't tell me I need to download 5 other packages from various websites to make it actually useful??? Plus there aren't as many GUI choices for facelets as for JSF.
6. JSP sucks... I've had with JSP ever since 2000, why do I have to come back to it again and again??? (Oh, I know why, because big corps are not always brave enough to jump on something like Wicket or Tapestry...they want the "standard" and something "with a GUI").
7. Implementing a custom component is absurdly complicated. IT SHOULD BE TRIVIAL. GUI should enable and GUI-fy custom components automagically. Welcome to 2007. I shouldn't have to write any additional descriptors, jars, xmls, manifests, and whatnot to make it GUI-fied. That's absurd. Use introspection. Use convention. Use intelligence. Use well thought out design to infer everything that GUI needs to know. Make it trivial to design custom components. I am not saying make it easy. I am saying make it trivial.
8. What is going on with all the magic javascript? I hate it! For example, if I want to submit page on a radio button click, why do I need to use onclick submit() and also use valuechangelistener? What happens if I skip valuechangelistener? What is this not documented? DO NOT GIVE ME A DUMB STEP BY STEP RECIPE on how to do thing... EXPLAIN WHY I NEED TO DO IT LIKE THAT and what will happen if I don't do it exactly like that. Where is all that???
Forget AJAX...the basics are not working in JSF. When JSF can cover the basics, then and only then can we think about AJAX. JSF sucks at its very core. It's poorly designed. It's over-complicated. It's hard or impossible to debug. It has terrible error messages. It's full of magic and weird behaviors (like what the hell is immediate=true? why such a nasty hack is not necessary in any other framework I am aware of?)
I am annoyed. My buddy is constantly pushing me to .NET. I love Java. I want to stay in Java world. But JSF has opened a door for .NET on our team. I detest the developer and user-hostile and arrogant attitude of Microsoft. I can't say I am happy about the whole situation.
|
|
|
Message #225848
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF sucks...and has no hope
Make it trivial to design custom components. I am not saying make it easy. I am saying make it trivial.
Just use Wicket.
-----
Gustavo.
|
|
|
Message #225989
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF Inter-operability
I do not disagree with this statement. My point is directed towards inter-operability of components within a component based system like JSF when each component is using a different Ajax implementation. When I do a project I pick an approach. If that approach is JSF then I want to be able to pick the components I want to use. I must be assured that all of these components will play well together and this is NOT the case today. If not then I'm down to having to choose a vendor's component suite and ocked into a pre-determine UI capability or would have to write my own.
I second this. JSF component inter-operability is pure vapor when it comes to Ajax, and I bet that's the first problem to be solved for the next rev of JSF.
|
|
|
Message #225990
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF sucks...and has no hope
When I first read this response I was a bit put off by the anger and tone of the response. While this thread is beginning to duplicate thread_id=43705#224933 I would like to respond since the points are somewhat valid and reflect what I am saying above ... except I think JSF has hope.
Tremendously and unnecessarily complicated lifecycle. It's required to understand in detail how the lifecycle works to do even relatively simple things (of course you don't need it for an absolutely trivial "hello world" type stuff, but in real life you need to know it for even a moderately easy business app).
I absolutely agree with this statement but show me any framework that does not require some knowledge. In the end no IDE is going to substitute for making the developer understand the framework they are using. The learning curve with JSF is a bit high at first but the benefit is worth it. Better integrated components and associated documentation (e.g. ADF) makes this less of an issue.
verbatim??? subview??? WHAT IS THAT JUNK??? The people I see using verbatim all over the place are the ones who are using weak component suites. I did a major project with ADF and not once had to use any raw HTML; this is my point about components. If you have to switch between components and raw HTML you will have a mess. Now the comment about subview tells me you don't understand JSF very well. The concept of a subview (more robust implementation is ADF's regions) is extremely powerful and enables you to create reusable page regions.
Implementing a custom component is absurdly complicated. This comment I agree with but it is mainly due to the complexity of the render-kit concept, not the JSF lifecycle. Too early to see if render-kit concept will pay-off. Right now, writing custom component is difficult, to many things can go wrong. This needs work or better yet someone to write good editor just to do this.
What is going on with all the magic javascript? I hate it! For example, if I want to submit page on a radio button click, why do I need to use onclick submit() and also use valuechangelistener? What happens if I skip valuechangelistener This statement shows a lack of understanding for JSF. I personally have a problem with the way people "teach" JSF patterns and have arrived at my own good techniques. First about the client-side and javascript comment: It's a browser sir, what would you like to see? The point is that JSF+Component+AJAX removes you from the details. Second, the ValueChangeListener is there to assist you in writing your server side logic. You don't need to use it, its your application, can't answer the question if you don't say what it is your doing. I will say there is some confusion about when to use a converter and when to use value change listener. Converters by nature due some form of validation and this gets confusing. My general answer is that Converters validate data type and format, and ValueChangeListener's are good for simple validations (range, limits). Business logic validations are best left for the Invoke phase. Also note that when using an AJAX like implementation (e.g. ADF) the ValueChangeListener is an important player in the partial page rendering.
Forget AJAX...the basics are not working in JSF. When JSF can cover the basics, then and only then can we think about AJAX. The basics are working quite well in JSF. What you are really asking for is a comprehensive implementation like Oracles ADF or similar. That was the point of my post.
I am annoyed. My buddy is constantly pushing me to .NET. I love Java. I want to stay in Java world. But JSF has opened a door for .NET on our team. My story. 1.5 years ago I recommended JSF for my project. This first project was canceled and I moved to another, using the JSF work I had done in the original. The customer, in an internal battle over standards, made another project use JSF during the same time period of my first project. They used IBM RAD 6.0, big mistake, especially for a first JSF project. This project was not very sucessful while my follow-on project based on ADF was. The other project hated WebSphere/JSF so much they lobbied and got the entire company to switch to .NET for all Web Deliveries. I lost my job (consultant) having been the original promoter for JSF (although my second JSF project was overwhelming success and I had no input in the unsucessful one)but someone had to pay. Still, I do not think JSF sucks and will continue to recommend it. However, having been through two projects now, I will say that you need to use a viable implementation (ADF/trinidad/new impls?), watch all the vendor hype, expect to have to train developers in good techniques, and have some understanding to make it sucessful.
I doubt any of these supposed simple java frameworks will make it any easier in a significant Web undertaking. We need one, maybe two Java framework(s) with vibrant implementations and support to compete with .NET or else these types of stories will continue not matter what framework you propose.
|
|
|
Message #226001
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF sucks...and has no hope
I'm with Steven.
I do believe that JSF has potential.
I think Jacob(Facelets creator) once mentioned that JSF is more of a platform. I think the promise of JSF will be realized by projects witch exploit the platform such as Seam, MyFaces, Facelets, Ajax4JSF. The problem with the RI is that they are quite slow to come out with new versions. Perhaps this is where MyFaces can step up?
However I believe that the major problem with JSF is the poor documentation that ships with the RI and even MyFaces. I remember when I first got started on Struts the documentation was a real life saver and helped me out of tough spots frequently. Struts ships with an example web application that shows you how to accomplish all kinds of little yet frequently encountered problems. With JSF we get giant, difficult to follow full blown applications! Who has time for that? Just quick little Struts style examples will go a long way to resolving a lot of the FUD that JSF is difficult. I would recommend to "flat out" take the quick examples web application of Struts and convert that to JSF. RI team, MyFaces team, Jacob, you guys getting this?
|
|
|
Message #226016
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
nice try, but no...
By the way, currently I use myfaces and I hate it.
This statement shows a lack of understanding for JSF.
Of course. But that's not because I haven't tried to understand it. The only thing I didn't do is step through JSF execution flow in a debugger. I actually understand it decently well, but I know that my understanding is incomplete, and my original post mentions as much.
For example, I need to have a group of radio buttons that immediately change a section of the page based on which one is selected. How to do that? That appears to be known as a "SubmitPageOnValueChange" problem, documented here: SubmitPageOnValueChange.
Guess what? It gives you two recipes. I hate both of them. Both of them are hacks. Using a hidden button is a hack. So is the second one. For some reason the second one looks more elegant to me, since it doesn't rely on a hidden component. (In retrospect, that may be a mistake, but who cares...both solutions are presented as workable within their limitations, which I am fine with) Now for the second recipe, you are told to use onchange="submit()" and valueChangeListener="#{page.menuChanged}". My question is why not just submit? What happens if I omit specifying valueChangeListener? I understand that JSF has some magic javascript that tells JSF which component was responsible for the submit. When we call submit(), we circumvent that. OK. Does valueChangeListener somehow remedy that? Does it make things better? I don't see how it does. What does it make better? If nothing, then why not simply recommend onchange="submit()" and be done with it? And why isn't this documented in-depth? Do you see how many questions I have? Why should I have to whip out a debugger and source code to understand a framework? Should that be necessary?
The people I see using verbatim all over the place are the ones who are using weak component suites. I did a major project with ADF and not once had to use any raw HTML
I've used RI and myfaces. Both suck. I know about ADF but decided against it, since it is a relatively unknown horse in my book; even less known than RI and myfaces. And it's huge. Anything huge can be a huge win or a huge disaster (usually the latter is true).
Any framework that's only good because it obviates writing HTML is a horrible framework in my book. That simply means you haven't truly put it to test yet. It's simply not acceptable not to have direct access to HTML when needed. Need I mention how horrible CSS styling is on some of the components? In myfaces tomahawk I can't even style many many aspects of tabbed panes. I can't style the tab buttons easily. I can't do any interesting behavior changes easily. It's freaking hardwired up the wazoo. :) Horrible, horrible crap. You either take it the way it is, or leave it. And I don't like that kind of stuff. Currently we're using all kinds of unnecessary CSS hacks to style tabbed pane the way we want to.
The fact that you don't even know how ADF works in the presence of HTML tells me it's a ticking bomb of a framework.
Now, facelets handle HTML much better. That's good, but facelets are not there by default and they have their own problems that I don't want to get into right now.
The whole "JSF is a platform" spiel is really not working out for me. Look, Eclipse is a platform too, but when I download Eclipse + WTP (which can be dl'ed with a few clicks right from within Eclipse, today, so it's hardly separate) I get more or less a complete IDE that handles 95%-99% of my needs. Great! And the fact that it's also a platform and not merely an IDE is an icing on the cake. It means if I need to, I can install CDT on it and do C++ programming. But I don't need to, so I don't. But it's there if I need it, because it's a platform. Great. But I can actually USE it...so I don't mind that it is also a platform. Since I can use it the way it is, the fact that it's also a platform becomes a good feature.
On the other hand JSF RI is crap due to poor features and all the inherent problems in JSF design. JSF myfaces is crap due to more bugs than RI and crappy extensions (for example tabbed pane that cannot be easily styled, etc.). And both of them are crap because they don't integrate gracefully with HTML. And they are both crap because by default you get ugly URLs. What is up with that? Why is my app sitting and Login.jsf throughout its entire lifecycle? You mean I have to take special effort and apply a mountain of hacks to have normal, web-friendly URLs? That's crappy.
JSF is not acceptable.
Granted, I could learn that sucker in and out. I can learn it as well as its implementers and then I'll know every little trick and every subtlety of its use, and then, I can do more or less anything with it. But, I'd have to learn it at an implementer level for one, and even with all that knowledge and wisdom it would still suck, because even though I'd know every workaround, I'd have to rely on many workarounds to do simple things that shouldn't require workarounds.
Finally to show you how crappy JSF is, let me cut and paste one line from my log file:
Dec 5, 2006 3:53:14 PM org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBase encodeInnerHtml
SEVERE: Row is not available. Rowindex = 0
What kind of piece of crap is that? What table? I have many. What particular jsp? What is expected? What is the suggested fix? What line number did it occur at? Do I really need to see this in my log: org.apache.myfaces.shared_tomahawk.renderkit.html.??? Does it add any useful information to me? I already know I use apache tomahawk, thank you very much. When row was not available, what was the state of the backing bean?
You seem like a smart guy to me, so don't take it personally. I just think JSF sucks and has no hope, because much of its suckiness is designed into it right at its core.
|
|
|
Message #226061
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: nice try, but no...lets make it yes
This response is too bad, I am sorry you did not get the help you needed and JSF community needs to take responses like this to heart.
I know about ADF but decided against it, since it is a relatively unknown horse in my book; even less known than RI and myfaces. And it's huge. Anything huge can be a huge win or a huge disaster (usually the latter is true). Your analysis about ADF is completely unfounded and wrong. ADF does not get the play it deserves in this community. It is hugh which is a POSITIVE because it will deliver 80-100% of your component needs and it is VERY well documented. It does not of what you said and truly enables productivity. The only think I would like to see is better help with Skins (ADF/Trinidad skinability has promise) similar to what SAP NetWeaver/Web Dynpro.
Finally to show you how crappy JSF is, let me cut and paste one line from my log file:
Dec 5, 2006 3:53:14 PM org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBase encodeInnerHtml
SEVERE: Row is not available. Rowindex = 0
After my first project I went back to basics and reviewed all of the JSF component suites. Your first problem is Tomakawk, it is poorly documented and extremely buggy. I will hold off on recommending Trinidad for *REAL* projects until it comes out of the incubator and meets the documentation level of ADF. Youyou might go there if you want a free version (ADF is 5K/CPU in production and bundled with other Oracle goodies if you're an Oracle shop). Again my point is we need quality, well documented, inter-operable, component suites so people are not struggling as you have. .NET is not a specification or reference implementation, it is a well documented and stable (??)implementation of a web framework. So your point is not lost on me, I just think you started in the wrong place.
The whole "JSF is a platform" spiel is really not working out for me. Look, Eclipse is a platform too, but when I download Eclipse + I don't want to seem to be an oracle for Oracle but try JDeveloper. I hate IDE's myself but JDeveloper is by far the best IDE I have worked with for JSF. Its free and I hear little about it.
For example, I need to have a group of radio buttons that immediately change a section of the page based on which one is selected. How to do that? That appears to be known as a "SubmitPageOnValueChange" problem, documented here: SubmitPageOnValueChange.
A piece of cake with ADF/Trinidad. If you write me directly and give me a short description, I will give you an example. This is bread + butter stuff for ADF/Trinidad and PartialSubmit and you will not get a page flash like in the MyFaces example.
so don't take it personally
Nope I'm listening, the JSF community needs to listen, the vendors need to listen, I try to help when I can. Cheers!
|
|
|
Message #226175
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ADF...
Hi Steven,
ADF sounds interesting, but...
5k per CPU? I'm not sure about that.
ADF has partial submit...nice, good for ADF, but why should 5k framework be needed to fix something that should never have been missing/broken in core JSF?
I assume ADF has better logging, since you don't mention it.
Still, I don't know if I want to switch to JDeveloper and pay up for ADF. Before I do that, of course I am going to look at free alternatives. I hope this doesn't seem like an unnatural choice to you. :)
|
|
|
Message #226188
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF is another failure
I totally agree with Leo L. because I had the same experience. JSF is just another plain paranoid technology coming as push from Sun for pleasing the corporate sick brains.
You know what? For multiple projects I had to implement the presentation layer I discovered that using Spring MVC controllers with custom view classes rendering Freemarker templates and the fantastic ECS library from Apache http://jakarta.apache.org/ecs/index.html or Custom JSP tags is the most clean and productive approach.
More recently after Spring WebFlow was released I started to use-it and this makes me even happier besides the richness diversity of controllers offered by the Spring MVC possible to choose and adapt exactly to fit your specific needs. For me, JSF is another failure because of not fitting the niche …
|
|
|
Message #226395
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF has major issues
I have spent much time learning JSF and using it in real applications. I have gone through Sun's implementation source code with a fine tooth comb. I have written custom components. In summary, I can say that I have a small amount of knowledge and experience with JSF. I have also used ASP.NET which JSF clearly attempts to emulate.
I will recommend Java, J2EE over .NET if my job depended on it. But, I must say that ASP.NET is a far better product than JSF. JSF has been a wasted opportunity. It has fundamental problems deep in the guts of the architecture. For example, much of the lifecycle is enforced by individual components (through the UIInput base class) and not by a central controller. There is no "page load" event handler to do initialization. Have you tried changing the value of a component (say a text box) from a value change event handler (of say a listbox)? This truly exposes a number of problems with the framework. In ASP.NET the simple postback mechanism eliminates any need for value change event handler.
The default value of a check box is null and not false. A value change event is unavoidable when the form is first submitted. Every turn of the corner, there are unexpected problems with JSF.
If you have used ASP.NET you will know that JSF is unnecessarily complicated. Value binding, component binding, <h:outputText>, faces-config.xml - none of this is necessary in ASP.NET to achive the effect that they achieve in JSF.
|
|
|
Message #226441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF has major issues
For example, much of the lifecycle is enforced by individual components (through the UIInput base class) and not by a central controller.
And where is the problem here?
There is no "page load" event handler to do initialization.
This is not true for JSF 1.2 (and we are speaking about it).
You can use the "beforePhase" attribute of the view component.
Value binding, component binding, <h:outputText>, faces-config.xml - none of this is necessary in ASP.NET to achive the effect that they achieve in JSF.
Value binding now is part of EL (now are called value expressions), and I don't find it difficult, it's one of the simplest and usefull things of JSF.
<h:outputText> is not necessary with facelets (a de facto standard), faces-config.xml is not necessary with Seam for many things.
|
|
|
| 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)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, 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)
|
|
