JSF 2 now has basic Ajax support via f:ajax tag. RichFaces 3 has a very popular a4j:support tag (in fact, f:ajax was inspired by a4j:support). RichFaces 4 comes with a4j:ajax which is based on f:ajax but upgrades the tag with more features and advanced functionality.
Take a look here at the chart Max put together comparing the two:
http://mkblog.exadel.com/2010/08/what-richfaces-a4jajax-adds-on-top-jsf-2-fajax-tag/
Migrating from JSF1.2 to JSF 2.0 was such a big pain. But we had to do so because we wanted support of new rich faces tags.
A simple solution would be to migrate to a more suitable platform (if JSF is not required by management).
GWT (or its siblings) or even Wicket/Click would do much better.
Things are changing fast. At some point of time you need to migrate to newer technologies. This happened to struts. We have a struts application and we want ot migrate to a new solution. The same will happen to JSF 1.2, Wicket.
BTW I like this migration idea beacause this creates some jobs.
A simple solution would be to migrate to a more suitable platform (if JSF is not required by management).
GWT (or its siblings) or even Wicket/Click would do much better.
It's even better to migrate to a more powerful platform like JSF 2.0. Unless GWT or Wicket is required by management of course, but luckily this is rarely the case. We're currently migrating an app from Wicket to JSF 2.0 and the code looks much better now. New developers get up to speed with JSF 2.0 in seconds and it's a huge advantage that many people that come to work with us already know JSF.
At the time Wicket was nice, but it hasn't really been picked up by the market. None of our new hires had Wicket experience on their résumé and there are very little to no "wicket components" available from external sources. With JSF, we have many, many sources to choose from.
In our company, most programmers liked to work on the JSF based products and everyone loathed to work on the Wicket based ones. Finally management decided that enough is enough and ordered the Wicket product to be migrated to JSF as well when people started to complain that they felt being assigned to a Wicket project was like a kind of punishment.
Can you explain why Wicket was so bad for you?
Something concrete?
Note: ignorance of a technology is not a good reason for rejecting a of a technology that is "no Wicket skills" very very bad reason to abominate Wicket.
Can you explain why Wicket was so bad for you?
For me personally Wicket was not bad technology wise. There were developers who did had specific things they disliked about the technology, but the main problem was that a lot of components and support code for JSF was simply available.
In this case it came down a little to the Windows vs Linux argument. I hate to use this argument, since I'm a devoted Linux (and OS X) fan, but the thing is that a lot of software is available for Windows, which simply isn't available for Linux. Maybe BeOS/Haiku is an even better example. The technology may be nice, but there is just very little market adoption.
I remember a small incident where a developer had to use a web terminal for some specific application. For JSF a terminal component is readily available (see http://www.primefaces.org/showcase/ui/terminalHome.jsf). For Wicket, no such dice. The developer had to build something from scratch instead. Now this is just an example, and by itself might not mean much, but as it appeared this happened quite a lot.
In addition to that we have build a small but very handy in house library with a number of components, validators and converters for use with JSF. There is a lot of energy going on there and some cool innovations have made this a breeze to use.
In that regard, in our case, Wicket does trail behind. Nobody seems to be really motivated to build up an elegant Wicket util library, so whenever people have to do some work on the Wicket projects that we have they just miss a lot of the ease of use libs that we have. This is thus not really a technical argument of core Wicket vs core JSF, but more a cultural/social argument.
Something concrete?
Note: ignorance of a technology is not a good reason for rejecting a of a technology that is "no Wicket skills" very very bad reason to abominate Wicket.
I agree with you, and normally I'm just like that. I use Linux and OS X, which sometimes makes my life a little harder, but I use it anyway since I just like the OS better.
In this case however it's just that everyone knows JSF, we have support tools, supports libs, excellent books and are thus very productive with it. Switching completely to Wicket, which basically not a lot of developers really know is not really a boost for productivity. If Wicket was technically far superior to JSF 2.0 (+ Seam 3 soon), then there might be a point in forcing the adoption to yield a better long term productivity. But after using Wicket for a while, nobody here really thinks Wicket is -way- better. Some things are better in Wicket, some things are better in JSF 2.0.
A simple solution would be to migrate to a more suitable platform (if JSF is not required by management).
GWT (or its siblings) or even Wicket/Click would do much better.
It's even better to migrate to a more powerful platform like JSF 2.0. Unless GWT or Wicket is required by management of course, but luckily this is rarely the case. We're currently migrating an app from Wicket to JSF 2.0 and the code looks much better now. New developers get up to speed with JSF 2.0 in seconds and it's a huge advantage that many people that come to work with us already know JSF.
At the time Wicket was nice, but it hasn't really been picked up by the market. None of our new hires had Wicket experience on their résumé and there are very little to no "wicket components" available from external sources. With JSF, we have many, many sources to choose from.
In our company, most programmers liked to work on the JSF based products and everyone loathed to work on the Wicket based ones. Finally management decided that enough is enough and ordered the Wicket product to be migrated to JSF as well when people started to complain that they felt being assigned to a Wicket project was like a kind of punishment.
Augustientje,
Reading what you just wrote, you sound to me like a very good fiction writer. In other words what you just wrote was made up. Who in his right mind would consider working on Wicket a punishment. It's just the other way round. Who in his right mind would migrate a Wicket project to JSF? From the planet where most of us here come from, to be more specific, planet Earth, we just don't do that. We do sane things.
Therefore this begs the question- which planet do you come from? If you are shy to disclose the name then please answer the following questions about the inhabitants of your planet so we could deduce that ourselves.
1. How do they move about- by walking or hopping?
2. How do they talk? Do they sound like people with no teeth?
3. Do they grow hair in their mouth?
3. Do they have huge and rounded jaws?
4. I guess they have only claws, right?
5. How many eyes do they have? People of planet earth have only 2.
Thanks in advance for answering.
Yours sincerely,
Jan (from planet Earth)
Jan,
Wow, I didn't expect my silly comment to stir up such a... fuss? =)
It's okay, I just made a suggestion in my original reply.
It's a free country (and mostly free world, I hope), so you can choose whatever technology you want to be a punishment for yourself. =)
Jan, there's a place for each and every technology. Wicket is a nice framework, but so is JSF 2.0.
The fact of the matter is that JSF 2.0 simply has a (much) bigger market share and a much larger selection of readily available components, and that specifically at our company there are just more people who already have JSF experience.
Nowhere did I say that the core Wicket framework itself is a punishment. It's just that we are primarily an JSF/EJB (Java EE) shop and thus a lot of our internal support code is already available for that. Any other different framework would have faced the same difficulties.
The only semi technical thing I can comment about Wicket is what I said before: it's certainly not bad, but just not so much better that it's worth the trouble to switch to it completely. We're always looking for alternative options and Wicket, *for us*, just didn't provide a huge benefit over JSF 2.0.
Who in his right mind would migrate a Wicket project to JSF?
I think this is a little arrogant towards the hundreds of thousands of people who happily use JSF to build great things. Great that you are so happy with Wicket, but lots of us are very happy with JSF, especially JSF 2.0. There is a lot of vibe in the JSF community, just look at the huge number of component libraries that are currently available.
Although we don't use Wicket where I work, I have heard from friends who
Although we don't use Wicket where I work, I have heard from friends who...
[some part of my response got lost :|]
I have heard from friends who also migrated from Wicket to JSF 2.0. Not perse because Wicket was the inferior technology, but more because JSF 2.0 is a safer and better choice for the future (and is a great tech too).
Although we don't use Wicket where I work, I have heard from friends who...
some part of my response got lost :
I have heard from friends who also migrated from Wicket to JSF 2.0. Not perse because Wicket was the inferior technology, but more because JSF 2.0 is a safer and better choice for the future (and is a great tech too).
What "JSF" are you talking about?
If JSF = components and the standard only standarizes some basic non-AJAX components, what kind of security are you talking about?
Take a look to Woodstock, the JSF implementation of Sun, abandoned before Oracle adquisition.
Take a look to ADF Faces tightly integrated on Oracle's portfolio.
Do you really feel secure and future proof?
Do you really feel secure and future proof?
RichFaces, ICEfaces, PrimeFaces, OpenFaces, BindowsFaces, GMaps4JSF, WebGalileo Faces, Trinidad, QuipuKit, NetAdvantage for JSF, Tomahawk, etc. Lots of non-Oracle options.
Do you really feel secure and future proof?
RichFaces, ICEfaces, PrimeFaces, OpenFaces, BindowsFaces, GMaps4JSF, WebGalileo Faces, Trinidad, QuipuKit, NetAdvantage for JSF, Tomahawk, etc. Lots of non-Oracle options.
All of them providing a different and proprietary set of components.
I wouldn't call this proprietary, JSF simply has an open-source ecosystem which offers alternatives to choose from. Most important thing is JSF 2.0 provides standard APIs for Ajax, Resources and many other things that a component library provider needs, by following standard JSF 2.0 APIs these libraries can work together.
I wouldn't call this proprietary, JSF simply has an open-source ecosystem which offers alternatives to choose from. Most important thing is JSF 2.0 provides standard APIs for Ajax, Resources and many other things that a component library provider needs, by following standard JSF 2.0 APIs these libraries can work together.
Indeed, that's the entire idea behind JSF. It's to UI components what the JVM is to classes. You want such environment to be relatively stable and well defined, and that's exactly what JSF core is. The various component libraries and extensions (that use the JSF APIs for extension) can innovate at their own pace, can be open or closed source, etc.
What we're currently seeing is that JSF is really picking up momentum. There's a lot going on in the JSF world and its relatively easy to get people skilled in JSF. As I mentioned earlier, there just isn't that momentum for Wicket. No matter how nice Wicket may be, there just isn't the momentum. Very few projects are started based on it, and when we get stuck on some thing, there are far fewer people able to help out as compared to JSF.
Do you really feel secure and future proof?
RichFaces, ICEfaces, PrimeFaces, OpenFaces, BindowsFaces, GMaps4JSF, WebGalileo Faces, Trinidad, QuipuKit, NetAdvantage for JSF, Tomahawk, etc. Lots of non-Oracle options.
All of them providing a different and proprietary set of components.
Most of these libraries are open source. People can use them for building a very powerful rich application. In the same time, people have both a powerful free and commercial support.
All of them providing a different and proprietary set of components.
Most of these libraries are open source. People can use them for building a very powerful rich application. In the same time, people have both a powerful free and commercial support.
this information is really useful to programmers
this is complicated
