Published: May 15 2009 / 03:19
sadly i converted to struts 2 for many of the reasons outlined in these
I'd have to agree. It's the most painful of the web frameworks I've tried. I'd urge any newcomers to have a look at Wicket or Tapestry instead.
The most of the documents are outdated, a lot of issues are solved by using Facelets and JBoss Seam, and they will be standard in the next J2EE version. The Ajax part is implemented in a clean way using RichFaces or ICEfaces.
This is not a criticism on the other framework (there are a lot of good fw out there) but this is not real information about JSF development status at this moment.
Just one question, say I choose IceFaces and implement an enterprise app.
JSF is supposed to be a "standard" right ? Will I be able to migrate to RichFaces without any change to my code ?
Do let me know.
LOL this is a bit dumb (sorry) question because you are not talking about JSF, you are talking about 2 different components libraries...what you say is like saying that if I develop an application with a swing component suite, let's say JIDE Swing Components, I can switch to another component suite of another vendor because Swing is standard.
Read a little bit about the topics before asking for questions.
Actually in my experience, all the "decision makers" who propose JSF are typically "dumb" (like you say) so I hope they read your comment. Thanks !
To make it clearer, the moment you choose say ICEFaces, you are well and truly locked in to the vendor. Big Time. And what happens when the "latest and greatest" versions of JSF arrive (that are "supposed" to fix the problems in 1.X) is another discussion altogether.
LOL you are very funny...I don't think you know JSF so much to say if JSF is good or not...anyways...
coming back to your dumb question (that was already clear) I try to explain again: if you choose a library that is not a standard you are locked in every "world" not only JSF so also your answer is still "dumb" (as I said in the last reply :))...
to make it clearer: JSF is one thing and it is standard (do you figure out why there is more then one JSF implementation?), RichFaces is a component library but it is not a standard, also ICEfaces is a non-standard component library so if you choose one or the other you are obviously locked...but, I repeat (and if I have the next time I will also post a drawn), it is not a JSF related thing...if the water boils with fire it's not a JSF related thing ;)
And what happens now (using JSF 1.2 + Facelets + Seam) IS a discussion against the arguments of this post (mostly of them outdated)...
It's like ppl saying that Java is slow showing documents of '98...
Also the discussion on JSF 2 fits this topic as the are a few links about that (did you read ALL the links proposed by the post??)...
Just to add something also a part of those Ajax frameworks will be standardized in JSF2...
Don't waste your breath, pity you didn't get my intentionally "dumb" question. I have just 2 points.
a) There are far better alternatives to JSF available *today* , better than even what can be expected when the monkey-patched JSF 2.0 is ready for production usage - which would take at least 2 years from now to stabilize going by past experience
b) People are prepared to live with JSF's limitations today and choose it even when far better open-source web-frameworks are available. Why ? because JSF is a "standard" and most decision-makers (yeah call them dumb if you will) mistakenly assume that Java EE standards promise vendor-independence. Thanks for making it clear how terrible this assumption is :)
thank again for making intentionally "dumb" question without our need, and sorry if I didn't understand you, I'm just a JSF developer :P
sure there are a lot of web framework, but I think you have to make "the" choice for every project looking at the requirements...I don't know how many "decision-makers" you know but I suggest you to do the "decision-makers consultant" as I know you always do better ;)
bye and thanks for all your truth (coming from your "intentionally dumb question")...
Sorry but I have problems getting your point. You are saying that this article is outdated because the problems are resolved in Seam. Then, JSF is still a valid standard, just take care to avoid your vendor lock-in.
Isn't this a contradiction? Avoid Seam to keep vendor-independent, then use Seam because the standard is screwed?
Sorry, it's just that I never got how this "JSF is standard" thing works. Have you ever looked at Oracle ADF? The point above related is true, it's impossible to port a real-world JSF application between different frameworks.
I'm saying it's outdated also because they talk about jsf 1.1, JSP with JSF (Facelets solves a lot of problems and it's not a nw technology)...and I never talked about standards (first I don't care, the second we are comparing JSF with wicket that is not a standard so what's the point?). I never said to avoid vendor lock-in (it was the other guy).
So the point was not about being standard or not. The stuff that Seam and Facelets (and RichFaces and other frameworks built on JSF) brought will be ported to the new version of J2EE and will become standard (so you are still investing in the future standards). But, I repeat, my point was never about the standard.
I like Seam + Facelets + JSF because it's a very clean and complete solution. And if you add RichFaces you have Ajax with a lot of control and out-of-the-box components.
I'm not telling it has no problem, but it is not like they want you to show. Obviously if you get together all the bugs of every version of Java from the first version you would think Java is bad, isn't it?
Again, what does it mean "it's impossible to port a real-word JSF application between different frameworks"? If you use different components from other vendor you are locked to the component but the general application remain the same one.
I repeat it happens also to swing, but maybe it's me that can't explain very well my point! O_o
Also if you use GWT what can you port? Or wicket? Or swing for desktop? I really can't understand you guys...
JSF has a lot of benefits that come with actually taking the time to learn how it works. Just because you've had a bad time trying to figure it out, doesn't make it a bad framework, it just means that it takes more learning to understand.
Many people think that's the most important quality of a framework, ease of use, but that's why there's JSF2. Problems were recognized, addressed, and implemented. And like others have said, 3rd party libraries further enhance usability of JSF.
JSF has a basic concept that is very powerful, it's up to the user to figure out how to leverage that. It's not going to do everything for you like Rails does. You have to think and solve problems in the way that suits your needs best.
Frankly, I didnt even read your post. I just hate JSF so much that I vote you up just for the title you gave it...
ya I agree its sucks big time....
Hmm. He cites one of my old blog posts from 2006, too. Meanwhile I write a book about ICEfaces (expected for October 2009). So, you may recognize there has changed something in between. Most of the stuff JSF 2.0 standardizes is already available with ICEfaces 1.8.
I don't think it is a good idea to compare JSF with Rails, Wicked, etc. Any one using Rails as a frontend to Spring/Hibernate? Flex (+ Spring-BlazeDS) would be a better candidate to compare to JSF.
For sure, vendor lock-in is still a topic. But, if you have a look at how often you change your DBMS (Oracle, DB/2, ...) this can only be an empty phrase by the vendor's marketing. For the stable parts in your architecture vendor lock-in is no real problem if you choose the vendor with care. For the rest in your architecture open standards can help to take the better implementation in a later step. But, experience shows that this is an option precious few really use. The open standards help to get enough experienced people into your team. This helps to reduce initial training costs. The likelihood to reimplement something with a new technology is indeed higher these days. JSF as an open standard is only interesting because it delivers more choice. Flex has the better and cheaper programming model, the better maintenance costs, the better user experience. This may be true for Rails, Wicked, etc. (what I never used myself).
The point is: if you choose JSF
- because it is a "standard"
- because you think there is an "ecosystem" that will help you
- because you think you can achieve "vendor-independence"
You Are Dumb.
You are much better off choosing say Wicket. At least you can work in pure Java.
That is the point being made about vendor lock-in.
I have to make one more point about the great "ecosystem" that JSF apologists keep bringing up.
If say you use ICEFaces and expect the great ecosystem to help you (like MyFaces, Oracle ADF, RichFaces etc.) you are dumb. If you decide to use the proprietary Seam and Facelets to monkey-patch JSF and expect the ecosystem of Spring Faces / WebFlow to help you, you are dumb and dumber.
>If you decide to use the proprietary Seam and Facelets to monkey-patch JSF
For the love of god, stop trying to assume that Seam and Facelets somehow 'patch' JSF. Seam and Facelets both take advantage of what JSF was designed for: extensibility. This is really hard for you to get I guess.
you say extensibility - I see proprietary lock-in
and that JSF is half-baked as a spec
>you say extensibility - I see proprietary lock-in
Nonsense. Java is open source and an open specification. That by itself is a benefit. Of course, people use third party libraries on Java. That doesn't make Java itself any more a vendor locking then the extensions make JSF a vendor lock-in. Namely, you can still switch your code (and the extension along with it!) to another JSF implementation. You are NOT locked-in to any particular JSF vendor.
Wow, nice try switching a conversation about JSF to Java :) Especially when JSF is XML tag soup and namespace confusion, see this comment: http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/#comment-13610
And you are flat-out lying now about vendor lock-in. If you use ICEFaces you will end up using <ice:foo> tags for e.g. <ice:selectOneMenu> - hope you are not claiming that you can switch that to RichFaces :P
You go on with this stupid point, I bet it's unuseful to discuss that they are different components built on the JSF standard model, too difficult to understand?
Also as other said Seam and Facelets don't "patch" JSF, they extends it using the standard extension point of J2EE and JSF, so (again) please study before saying things...
About the XML, Seam resolve the problem and the new version of J2EE will use annotations (but you can still use XML if you want) for every configuration...
As others said things changed a lot from 2006 so just try to keep you informed on what's going on now...
Anyway I think those are unuseful words...
So my point is stupid when you can't come up with a decent argument ? Jeez.
I can't???? I'm guessing if you read my answers or not...
Look, you can't say yes or no about the original point which is whether you can port ICEFaces to RichFaces. You just mumble something about them being built on the JSF "standard model" or something. Please.
No point addressing the rest of your comment because it is just an infinite loop of previous comments. But one thing I have to point out - my comment on the XML tag soup and namespace hell was regarding the JSF *view* - and your blabbering about annotations for configuration has absolutely nothing to do with it.
You are starting becoming very uneducated, I answered explaining that the API of RF or IF are different because they are proprietary but they are standard JSF component and you can use a JSF application in every standard container (that's the standard for). I also made a lot of examples that you didn't understand. I didn't "mumble" anything!
You clearly don't know a lot of what you are talking about and you are trying to no-answer in an infinite loop (yours) repeating the same things without answering to my point (you can't because you don't know what you are talking about) and started becoming rude in you language.
Look: use what you want but at least speak when you know the topic (2nd time I say that).
>> API of RF or IF are different because they are proprietary
>> but they are standard JSF component
Ok finally you admit that they are proprietary ! Thanks.
ahahah with this answer you explained you didn't understand anything, thanks and bye!
.. and that too, annotations for configuration is possible only in JSF 2.0 that is not even final yet.
>And you are flat-out lying now about vendor lock-in. If you use ICEFaces you will end up using > tags for e.g. > - hope you are not claiming that you can switch that to RichFaces :
Either you REALLY don't understand or you pretend to not understand for the sake of keeping the discussion muddy. Let me try in the most basic wording possible.
A) User develops app using the RichFaces library and Geronimo as the Java EE implementation.
B) Geronimo implements JSF with MyFaces.
C) User switches to Jboss AS.
D) Jboss implements JSF with Mojarra.
E) User moves his application classes and libraries (thus including RichFaces) to Jboss AS.
F) Application still runs.
-THAT'S- the idea.
Compare this with:
A) User develops app using Apache commons and the SUN JDK as the Java EE implementation.
B) User switches to JRockit
C) User moves his application classes and libraries (thus including Apache commons) to JRockit
D) Application still runs.
Do you see a pattern?
Thank you Henk but it seems it's impossible to make him understand this simple concept...
That's a good explanation henk! pt93903's line of reasoning is just flawed. Whether you are for or against JSF is not even an issue here anymore.
BUT you are *still* vendor-locked into ICEFaces (RichFaces in your example)
And *that* is my point :)
pt93903, it's at a higher level. You don't build your application totally out of Richfaces. You build your application on Java EE. Java EE contains Java SE, which if fully a standard and vendor neutral and Java EE contains JSF, which is fully a standard and vendor neutral. These are the largest parts.
If any of those vendors calls it a day, you can switch to another vendor, and take RichFaces along with you.
Of course, someday RichFaces may stop or go into a direction you don't like. Being a library on which you depend, you indeed have to rewrite code, but you can do this piece by piece. Your whole application will keep running, and will keep running alongside other JSF components that you use to replace the Richfaces components with.
You can't do this with the core technologies. If Java wasn't a standard, and Oracle would take Java in a completely wrong direction, then I can't just take my Java EE app and run it on .NET, while I piece by piece replace my code with .NET functionality.
So in a way when using any library, any at all, your code DEPENDS on the vendor of that library. But since it's a library, the lock is of a different kind then if the platform was owned by a single vendor.
Ah so I am locked into the vendor "at a higher level" ?
Thanks ! I feel so much better now :P
The lower the lock, the harder to break free from it. So yes, you should feel better now. :)
Yeah right, I really feel better that all the JSF view code (or rather "tag soup") has to be re-written to break free :)
You don't have to rewrite it all in one go. If you had to rewrite ALL the JSF view code at once, that would be bad indeed. But luckily, that's not the case. You can just start with replacing that one component that makes you want to move away from component library X and replace that with a component from component library Y. Mean while, all other components of library X will still be there and your app continues to run for many years to come.
So, yes, you should indeed be feeling better. But wait, didn't I already said this before? :)
Yeah, I'm feeling better because I see a lot of business in the future for "JSF migration services". For example:
- upgradation of JSF 1.X to JSF 2.0 (for the people who still think JSF is worth committing to)
- migration of JSF 1.X to better web frameworks
- migration across component vendors (e.g. ICEFaces --> RichFaces)
- upgradation of JSF "extensions" e.g. Seam 2.X --> Seam 3.X
- migration across JSF "extensions" e.g. Seam --> Spring Faces / WebFlow
Oh the future is so bright, I gotta wear shades :)
The future is indeed looking bright. Upgrading to JSF 2.0 is going to offer a very good experience. JSF 1.X apps run unchanged on a JSF 2.0 implementation. You can test this yourself now using the public preview or a nightly build. This is a very well engineered update indeed. Facelets users can even immediately reap the advantages with very little effort.
The second point is mood, there aren't yet any better frameworks.
Migration across component vendors is not an issue of migrating. You just start using the extra component from the other vendor. E.g. if you are using RichFaces now, just throw in the components from OpenFaces you like.
It will be interesting to see what the update/migration path for Seam will look like. There's a potential migration to Seam 3.x, but there's also a potential migration path to WebBeans. It is going to be interesting though, I'm sure about that.
Anyway, Wicket users are in for a blast too this year:
-upgrading Wicket 1.3 to Wicket 1.4 (for the people who still think Wicket is worth committing to)
-migrating Wicket 1.x to Wicker 2.0 (requires a complete code re-write, as many of the APIs will change completely)
-migration of Wicket 1.3 to better web frameworks (JSF, Struts 2, Tapestry, Spring MVC)
Admittedly, there's no even half the fun there, but even half the fun is still a good deal of fun, right? :D
Ha, of course JSF 2.0 has to be downward compatible. I'm talking about people who have to escape from the well-documented issues and limitations of JSF 1.X and make use of all the things supposed to make life better in JSF 2.0.
>> The second point is mood,
>> there aren't yet any better frameworks.
Wow, I really don't need to respond to that comment, it speaks for itself.
About your point that you can easily mix components in JSF (and thus have a gradual migration path), sorry no - especially if AJAX is involved. Many people have commented on this, refer the link dated 2008-04-10 in my blog post for an example.
Hmm, I guess you suddenly brought Wicket into this conversation because I mentioned in another comment that I recommend it.
Ok, I'll play. I have personally migrated a Wicket 1.2 app to 1.3 and guess what, since it was pure Java code (unlike the tag-soup abomination that is JSF) I was able to use the refactoring capabilities of the IDE to good effect.
Yes, it actually was fun :)
>Ha, of course JSF 2.0 has to be downward compatible. I'm talking about people who have to escape from the well-documented issues and limitations of JSF 1.X and make use of all the things supposed to make life better in JSF 2.0.
hahah... we're sure having fun here, haven't we? :) But indeed, JSF 2.0 of course has to be downwards compatible. The beauty is that you can escape from the well-documented issues in JSF 1.x piece by piece. First you move your entire app to JSF 2.0 and it just keeps running. Any new code in your app can then immediately take advantage of JSF 2.0 features. Meanwhile, you can update older code piece by piece.
This is basically the same that we did when moving from Java2 1.4 to Java 5. New code immediately took advantage of generics and enums for instance, while older code was migrated whenever we had some hours to spend. Worked great.
>Wow, I really don't need to respond to that comment, it speaks for itself
Indeed, there is very little else to say about that. For once I think we totally agree :)
>About your point that you can easily mix components in JSF (and thus have a gradual migration path), sorry no - especially if AJAX is involved.
Well, there is some incompatibility at times I give you that, but my mentioned example is valid. OpenFaces works with RichFaces and RichFaces works with TomaHawk.
>Hmm, I guess you suddenly brought Wicket into this conversation because I mentioned in another comment that I recommend it.
It's just an example really, don't worry too much about it ;)
>I was able to use the refactoring capabilities of the IDE to good effect.
True, although you did had to do the porting yourself. You as a human had to instruct your IDE to do certain refactorings. I can't remember the Wicket guys providing a script for Eclipse that automated this for us. And once again, JSF is not inherently a tag soup. There are two well known ways to construct a component tree and that's through Facelets and JSP. However, both of these just call into the pure Java API of JSF. What Facelets can do is exactly the same that your code can do. You see tags and you think that those tags -ARE- JSF.
It's very easy to just build the tree in pure Java. JSF doesn't know Facelets. It's Facelets that knows JSF. Small subtle difference in wording, but makes for a HUGE difference in architecture.
>> This is basically the same that we did when moving from Java2 1.4 to Java 5.
Exactly, looks like you are coming around to my point that working in pure Java is easy. The problem with you attempting to compare Java code migration to JSF view / tag-soup migration is that it is apples to oranges, nice try claiming that piece by piece migration of JSF views is straightforward - using that comparison !
Especially when you actually agree that mixing components causes incompatibilities.
So you recommend projects to actually use the famously verbose and clunky JSF API to build component trees instead of using Facelets / tags or JSP ? Interesting :) As someone on the blog comments said, you really should write a book. Looks like you know of a lot of best practices I don't see too many people aware of.
>Exactly, looks like you are coming around to my point that working in pure Java is easy
I fully agree with that, so one more point that we agree with :) I have two additional lucks:
1) With JSF I can work fully with pure Java only. The framework is so cleanly designed that the choice is really up to me. Pure Java, Tags, or a combination? JSF doesn't care and it shouldn't care. The only thing JSF wants is a component tree. From where it gets this is not interesting for JSF.
2) Working with Facelets is easy too.
>nice try claiming that piece by piece migration of JSF views is straightforward - using that comparison !
It's IS straightforward and it can be done piece by piece. I like your metaphor of apples and oranges. Yes, Java is the apple and (Facelets) Tags are the oranges. But guess what? You can eat them both, and you can eat them both piece by piece. No need to swallow either a whole apple or orange! :P
>Especially when you actually agree that mixing components causes incompatibilities.
But it does! I would be lying if I said it wouldn't. Some components don't play along nicely. So be it. It's not in general true. In my project I use components from 4 maybe 5 different libraries and you know what? They all play along rather well. Thank you. And how is this different from using Java classes in some environment? Does every Eclipse plug-in works well with every other Eclipse plug-in, even though they are programmed in Java and ultimately classes? I think you already feel what's coming, but let me tell you: the answer is plain and simple "no'.
>So you recommend projects to actually use the famously verbose and clunky JSF API to build component trees instead of
It depends on the situation at hand. I personally have no beef with Facelets, but occasionally I want to do something highly dynamic and then I build a part of the component tree using the elegant and well designed JSF API. I guess if you would be a Java-only purist that you might build your entire UI that way, but personally I haven't felt the need for that. As I mentioned, and please let me mention it again, I don't hate Facelets ;)
My last comment here, apologies to all who actually read through this painful thread up to here :)
Just 2 comments that Henk made that I will repeat here:
a) There are no better web frameworks than JSF
b) The JSF API is elegant and well-designed
That is all.
P.S. - Yes you are right Henk, repeating your words of wisdom without commenting on them means I completely agree with them :P
>My last comment here, apologies to all who actually read through this painful thread up to here :)
OMG! You guys are still debating this issue? What are you trying to do, set the world record for number of comments on a Dzone link? *lol*
I have to say though that I mostly agree with Henk. pt93903 comments to me seem to be too much like grasping at any straw that can be used to say something negative about JSF.
>a) There are no better web frameworks than JSF
>b) The JSF API is elegant and well-designed
That means... you've seen the light? You're throwing in the towel? I... won!?
Thank you so much pt93903 and good luck with all Java coding :)
Yes, we're using JRoR with Hibernate/Spring on the back end, as well as JMS and a few different types of SOAs.
JSF with facelets rocks. JSF 2 will be awesome. But Click framework or Wicket or Tapestry 5 are my favorites or for MVC Spring MVC.
-- sorry replied to wrong post --
Wow, JSF seems about as bad as the Web Forms in ASP.NET
I thought I was the only odd one. I am so glad so many people hate it. It sucks than any other framework I ever used and I used a lot.
Well. I happen to have ported an enterprise application from MyFaces (JSF 1.1) with Tomahawk and Tiles to Mojarra (JSF 1.2) with RichFaces and Facelets. You can't just switch jars and restart the application server, but it is not much to be scared of either.(See http://techinorg.blogspot.com/2008/10/upgrading-jsf-11-project.html)
That said, I certainly think Wicket is a better web framework.
>Well. I happen to have ported an enterprise application from MyFaces (JSF 1.1) with Tomahawk and Tiles to Mojarra (JSF 1.2) with RichFaces and Facelets.
Of course, the main switch here is from JSF 1.1 to JSF 1.2 and from Tomahawk to Richfaces. If you made the switch from MyFaces (JSF 1.1) to MyFaces (JSF 1.2) you may have to do some porting too (depending on what features you used). The main argument is that porting from say MyFaces (JSF 1.2) to Mojarra (JSF 1.2) both using RichFaces is basically a question of restarting the server.
Also Tomahawk is largely a pure component library that keeps working when using RichFaces components on the same page.
I don't agree. We use JSF extensively and it improved the maintainability of our application a lot. As of now I'm really happy with JSF and looking forward to JSF 2.0 which is going to rock!
Why is it a vendor lock-in if I use Open Source products? Where's the dependency that let me think about not to use it? Which kind of openess is missing then? You recognize the contradiction? If you get full access to the source there is no dependency at all.
You can of course give up to use higher-level components, but that's one of the key assets with JSF. And for me JSF makes only sense when I use one of them (ICEfaces, RichFaces, Tomahawk, ...). Sure, with all the AJAX stuff we use today, the agile methods, the demand for a desktop-like presentation the JSF architecture has a lot of tweaks and is pretty old. And even with a lot of experience the mixture between request/response and component/event is really annoying. For me a s a former desktop developer it is even worser.
So, we should think about developing smarter components. Imagine what desktop developers get when they use Delphi or Visual Basic. We still get not what those tools already delivered a decade ago! This kind of components would speed up development. For ICEfaces users maybe the http://www.edorasframework.org will be a good help in the future. It delivers a full-blown ICEfaces/Liferay/Spring/Hibernate/Generic DAO stack and delivers Facelets-based components.
I can only agree that JSF is totally flawed. As is JSF 2.0. Compound validation is still a nightmare. Consistent CSS integration is not available. Making components render in 1998 1-0-1 web style (Labels red when field is invalid! Labels bold for required fields!) is still impossible with the basic JSF components. There is no consistent Ajax integration. Templating with Facelets does not help, since the problems are deep in the system and the standard renderkit/standard components. There is no cross cutting component market, because plain JSF is much to weak as an integration point. Yes, there are excellent frameworks built on top of JSF, but they are not JSF, they are IceFaces, or ADF or RichFaces etc. But they fragment the component market, and thus there is no visible component market for IceFaces, ADF etc. as well. Of course this creates a technology lock-in, there is simply no denying it, maybe a "vendor" lock-in if you will. And it does not get easier because these frameworks themselves have dependencies to no small amount.
>There is no cross cutting component market, [...] Yes, there are excellent frameworks built on top of JSF, but they are not JSF, they are IceFaces, or ADF or RichFaces etc.
Uhm... duh!? There is no cross cutting class market for Java SE. Yes, there are excellent frameworks build on of Java SE, but they are not Java SE. They are Apache Commons, Quartz, OS Cache etc.
Does sound a little silly, doesn't it? Yet this is exactly what you are saying...
Does this mean that when we say JFS is a framework and compare it to say Wicket or RoR, the comparison is entirely wrong? Since by your own definition and examples, JFS seems to be a standard for building frameworks like IceFaces. Whereals Wicket is a framework for building Web Applications.
Is JFS pushed as a web application framework or a component library framework? This is important as the comparisons should be valid. If JFS is a web application framework, it should address web application developer's needs. And if it's a component framework to allow web application frameworks to be built, then it should not be pushed as a solution in the web application space; the resulting frameworks built on JFS standard should be in that space.
It seems to me JFS cannot decided on where it wants to be, and thus the resulting misunderstanding between the web developers who want productivity above all else, and the JFS proponents who UNDERSTANDS that deep down, JFS should be a standard and stay there.
For those looking for solutions, this DZone link is a good read: http://www.dzone.com/links/for_the_love_of_vaadin_java_rias_done_right.html
Just new to oracle ADF and I have to say it sucks big time. The way it removes you from JSF by introducing an aweful binding layer that means you end up programming dynamically, you get no compile time checking and when you try to do anything slightly tricky your code just does not read well. Introduction of a page definition file just to add to the confusion and maintenance..it really is a nightmare. It adds to the XML hell problem which is prevalent throughout the whole Oracle Fusion suite. You can't debug anything cause its all configuration in XML instead of clean java code.
Tried building a richfaces/facelets/seam CMS application. It was a battle of epic proportitions, even with RedHat support it nearly burnt me out. Long story short I'm now looking at other frameworks.
Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.
Advertising - Terms of Service - Privacy - © 1997-2014, DZone, Inc.