Hi Here is the list of reasons why choose MyFaces as JSF implementation. Note this is my personal point of view. After read this, is your choice to decide which one take for your next web project.
- Community over code: MyFaces community counts with a lot of folks with outstanding knowledge on JSF. Suscribe to user and dev mailing lists are the best way to know what's going on, receive feedback and know other people interested in JSF. This is an important consideration, because sometimes you can find a bug or need to ask something to somebody about JSF. - Innovation happens on MyFaces: MyFaces is not just a JSF implementation, it host other projects (Trinidad,Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ....) that provides additional functionality not provided by JSF implementation itself. - MyFaces uses Maven, so edit the code or rebuild it is as simple as open any maven project with your IDE. Note that most IDEs has built-in support for maven. - MyFaces Core is tested everyday against MyFaces UI component libraries and Add-ons/Extensions. Many of these projects are compatible with both MyFaces and Mojarra (because they are build on top of JSF standard), but you should note that those projects helps MyFaces Core to keep code in good shape, because all those projects test against MyFaces Core, and if there is a bug, it is handled more quickly (because everything is handled "in home"). I think the previous reasons are enough to convince anyone to use MyFaces core. But there is a lot of additional "technical" reasons to take into account too: - MyFaces Core is "OSGi" friendly: It provides some SPI interfaces to deal with special setups, when you need more control over classloading. A lot of good stuff has been put in this area. - MyFaces Core generates code using myfaces-builder-plugin: these project is a maven plugin that with myfaces-builder-annotations provides a jsf development kit to create multiple artifacts (components, converters, validators, client behaviors) and handle all documentation related in an easier way, minimizing the number of files you need to handle. It uses java annotations to feed all related information, and each myfaces jar using this tool has a myfaces-metadata.xml which contains all meta-information required to build each bundle. This tool can read composite component definitions and build an integrated documentation with your normal components, converters or validators. - MyFaces Core has better compatibility with facelets 1.1.x: Sometimes it is easy to find some use cases with combinations of c:if, ui:include, c:forEach and other tags that causes problems when they are upgraded to JSF 2, because it has some problems with partial state saving. Just set org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS web config param to true and org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE to true, and a special mode will be activated.No c:if tags or c:forEach or ui:include broken anymore, because some parts of the tree are marked to be restored fully, just like on JSF 1.2. - MyFaces Core composite component feature is built on top of facelets template client mechanism: special care has been taken to ensure tags like ui:composition, ui:decorate are correctly resolved, even inside composite components and other complex cases. No "component relocation" is used for implement cc:insertChildren and cc:insertFacet like in Mojarra, so that means state will not get lost inside composite components. This issue in Mojarra is really serious, but people are working there to get it fixed. - MyFaces state manager takes into account multiple window cases: Since 2.0.7 and 2.1.1, a new web config param org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION was added. This param is only applicable if state saving method is "server" (= default). Indicates the amount of views (default is not active) that should be stored in session between sequential POST or POST-REDIRECT-GET if org.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION is true. For example, if this param has value = 2 and in your custom webapp there is a form that is clicked 3 times, only 2 views will be stored and the third one (the one stored the first time) will be removed from session, even if the view can store more sessions org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION. This feature becomes useful for multi-window applications. where without this feature a window can swallow all view slots so the other ones will throw ViewExpiredException. - MyFaces server side state saving does not use a buffer to place javax.faces.ViewState token: Before 2.0.7 /2.1.1 and on Mojarra, a buffer is used to store temporally everything before the end of the first found form. Then and algorithm replace javax.faces.ViewState token with the state and the output is flushed. MyFaces uses a clever strategy to that prevents use that buffer when server side state saving is used, reducing memory consumption over requests. MyFaces Core cache EL expressions when necessary: this will be a new feature proposed for 2.0.8 and 2.1.2 (not available yet but you can try on a snapshot), and in few words that means no EL expressions will be created if is not necessary. This have an important impact on memory comsumption and speed. - MyFaces Core provide uncompressed versions of javascript files: when project stage is development, you can set org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS web config param to true and the base javascript files will be used instead the compiled bundled jsf.js. If it is false, by default the bundled jsf.js but uncompressed will be available. That makes easier find ajax bugs, which usually tends to be difficult to solve. - Many other performance improvements has been done to keep myfaces code running in good shape. There are more reasons to use MyFaces Core, but I hope the previous reasons should be enough to convince your colleagues. regards, Leonardo Uribe 2011/8/23 Gerhard Petracek <[email protected]>: > hi al, > > you already named some of them. some others can be found e.g. at [1] > > regards, > gerhard > > [1] http://wiki.apache.org/myfaces/tss_article_draft > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > 2011/8/22 junk mail <[email protected]> > >> Hi guys, >> >> I hope you are not going to kill me to post this subject here, but I don't >> find strong arguments to convince my colleagues to continue using myfaces >> implementation of JSF rather than mojarra. >> One of my colleagues is implementing a pilot application based on mojarra >> while I'm doing another pilot application using myfaces, we came to a >> moment >> where we need to stick to one impl. otherwise it would be too difficult to >> maintain both afterwards. >> My major argument right now is that the myfaces community is very active, >> that the bug fixing timeframe is really short and that we used myfaces on >> other internal applications (but for JSF 1.2) >> >> Do you see another good arguments or can you point me out to a discussion >> about it? >> >> Thank you >> >> Al >> >
