Just to add a few things to this list. I took a good look at JSF/Seam/EJB3/JPA stack about a year ago.
- People say JSF has a rich ecosystem (Trinidad, ICEFaces, MyFaces, SEAM, Facelets, etc.) but the downside to that is that you won't have one forum to go to in order to get framework help. Contrast that with this mailing list, which according to Nabble is the 3rd most active "Java Software" mailing list (next to Netbeans.org and Java.net). - The JSF processing lifecycle is an ugly beast. Worse, you have to know the lifecycle if you're building something stateful (SEAM-managed conversations). Try building a wizard pattern with forward/back and validations using SEAM/JSF, you'll see what I mean. - You'll want to use SEAM if you go with JSF, and you'll want EJB3 if you want to go with SEAM. Out-of-container testing and hot-deploys are not easy with EJB3, and this will significantly slow your code/debug cycle. - You'll also have a hard time using Maven (which is great once you get it going) if you go with Seam/EJB3. - Anything that is standards based has the drawback of slow progress, and will be roughly 1.5 years behind the state-of-the-art. (Compare JPA vs Hibernate.) - If "adhering to standards" is a core argument for using JSF, ask yourself, after using non-standard add-ons (widget libraries, Facelets, SEAM) if you're truly adhering to standards at that point... - Anyway, Struts is the de-facto standard for web development, not JSF or anything else by a long shot. David Bernard-2 wrote: > > Short version of my experience, last year I created a project with > Seam+Facelets+JSF+EJB3/JPA+jBPM. I was optimist JSF is a standard with 2+ > years old, lot of providers,... > * JSF : I tried to mixed components from several provider, Trinidad, ADT, > MyFaces, Ajax4JSF,... it was a nightweird and time lost (lost of > incompatibility in the configuration, rendering,...) > * JSF : I try to create my own components (and read " Pro JSF and Ajax: > Building Rich Internet Components"), very complex : Request lifec cycle, > extensions points, lot of xml to write and keep sync > * JSF : sometime nothing appends due to exception or reject in the dark > zone of the request life cycle, so don't forget to display "messages" on > every page > * JSF : some basic widget (select) always need hack to work > * JSF : create nasty/crapy html, with lot of form, javascript, div : > difficult to debug > * Seam : lot of good idea, need to understand Injection and Outjection, > need to be carefull of scope (request, conversation, session, application) > of In/outjection > * Seam : some features didn't work with third party JSF components > * Seam : required EJB > * Facelets : nice, helping information on failure, templating, > tools/facilities to create simples components > * jBPM : nice GUI to design workflow and pageflow => lot of getter/setter, > lot of xml, not easy to test/mock > * documenation : too many source > > After 3 month, I switch to : > * Spring instead of Seam + full EJB3 > * hand code instead of jBPM > * session instead conversation scope (spring doesn't support > conversation/continuation natively) > And keep JSF(Facelets+Ajax4JSF+MyFaces), JPA(Hibernate). > > About Spring + JSF, you had 2 choice > * every Bean (from spring) could be accessed from a JSF page > * only bean declared into an xml file could be accessed > > About html preview : > * facelet allow to use regular html tag with attribute like wicket, but > it's an option, and lot of components need to have child component with > special tagname and every/lot of component add tag when > it's rendering (runtime) => css from static page template need to be > changed. > * facelet like wicket allosw to define fragment, displaying page with > fragment or fragment alone isn't very usefull. (note : I use fragment as > general term, not in the Wicket terminology) > > Result : I was pretty happy with the final solution but lot of xml to > maintain. > It's quicker to start wth JSF than Wicket, but when to start to customize > and use none basic widget,... welcome to hell (of configuration, > documentation,...) > > WARN: it's a 2006 experience. I've not used JSF extension/preview from IDE > > /david > > robert.mcguinness wrote: >> ...to tell you the truth, it impressed the developers but I didn't get >> that >> feeling from the top brass. I am pretty sure we will move towards >> Seam/JSF/Facelets (we have a presentation on that tech next week given by >> another developer) since it is "standard". >> >> Has anyone here worked with the Seam tech? All the examples I have seen >> (including Facelets) is nothing but tag soup with scriptlets in the page >> (albeit small). The configuration for a Seam project seems like a pain >> and >> was also told that the JSF/Seam/Faclets jsp pages can be previewed in a >> browser (something I thought was so clever about Wicket html pages...and >> I >> was under the impression that Wicket was the only tech that allowed true >> separation of concerns; allowing the web designer to work independenly of >> the programmer with no duplication of work between the two). Maybe I'm >> blind to Wicket and I'm overlooking Seam and the techs related to it? >> >> I've worked with Freemarker and Struts before and Wicket feels like >> "natural" web development. I thought I covered all the great concepts >> about >> Wicket: Ajax, Templating, Inheritance, Reusable Components, OO >> Concepts…etc… >> >> Bah…just venting. I’m going to have to win the votes of the developers. >> I’ll keep everyone posted. Thanks amigos! >> >> - rm3 >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Presented-Wicket-to-my-Company...-tf4532130.html#a12947458 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
