Hi, Here is a list of bullet points I compiled on "JSF when compared with Wicket":
– Not really OO components, more of XML tags than Java – Added complexity of JSF-EL and mixing JSP-EL if applicable – faces-config.xml : synchronize multiple files for navigation, page-centric, string expressions not type-safe – Poor separation of concerns / "preview-ability" (in core JSF spec) – General consensus that for practical use you have to supplement with non-standard extensions -e.g. Facelets, Spring WebFlow etc. – Hard to unit test – Hard to debug / step-through – More dependence on tooling / IDE support – Mixing components from multiple vendors problematic especially with AJAX – Generated HTML is typically verbose – Creating custom components is much harder – Slow evolution as it is a specification, now JSF 2.0 is being discussed… I had this as a back-up slide in a presentation recently (which I ended up having to use because of all the questions :) You can find the presentation here if you are interested, it is more to do with comparing Wicket with action / JSP based frameworks, but may help: http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/ Thanks, Peter. On Wed, Aug 6, 2008 at 11:44 PM, Igor Vaynberg <[EMAIL PROTECTED]>wrote: > On Wed, Aug 6, 2008 at 2:13 AM, nlif <[EMAIL PROTECTED]> wrote: > > Prior to posting here, I googled a bit, and found a > > few forum-threads and blog posts on this topic, but most are from 1-2 > years > > ago and in framework years, this may be considered obsolete. > > actually, imho, this is one of wicket's biggest advantages over jsf. > jsf is a standard so it moves very slowly. wicket is a much more agile > project and moves much faster. > > > Also, supposedly JSF has a larger selection of 3rd party components > compared > > to Wicket. Is this true? how often do you find yourself rolling your own > > components and how hard is it to do so in Wicket (and I mean > > non-trivial-good-looking-Ajax-enabled stuff). > > actually i find myself creating components all the time, because it is > so damn easy. trivial and non trivial, because wicket uses composition > it is not that much harder to create components with complex > interactions. > > sure, jsf has plenty of components out there that offer high level > things like data grids, etc, but so does wicket. the difference with > wicket is this: > > the other day i created a productlink component for our application. > it is a simple component that builds an anchor that takes the user to > the product page. it also adds proper css class based on whether the > product is for sale or not and whether it is in or out of stock. > > so now anytime someone needs to link to a product they simply do > > add(new ProductLink("link", product)); and attach it to <a > wicket:id="link">whatever</a>. the productlink can be embedded inside > any other component just as easily and have any other component > embedded in it as well. > > i dont think jsf folks would bother creating anything so fine-grained, > because although it is very useful there would be too much overhead > and pain involved. > > the problem is that jsf approaches web application development with a > few roles in mind: the application developer and the component > developer. the component developer is a smarter person that > understands the intricacies of jsf. in wicket we do not assume the > separation of roles, so our programming model is consistent and is > optimized towards component creation. > > my two cents > > -igor > > > > > > Many thanks in advance. > > > > > > > > > > -- > > View this message in context: > http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847208.html > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
