Hi Frank, Thanks again for sharing the anecdotes of those projects which used JSF. I fully agree with your observations/comments regarding RAD tools. I work for a software service provider organization and seen the same things happening (for the projects using RAD tools) many a times.
Regarding going for JSF due to componentization, I'm again not sure what additional componentizations JSF does compared to struts. Apart from the fact that JSF does not need a layer like Action Classes, all other components (validator, managed bean, html tag libs etc.) are already there in Struts. May be I'm missing something here. Also, I'm yet to appreciate the real value add event handling mechanism of JSF can bring in a web application scenario. Especially given the fact that all those events (associated with a single http request) would be fired only in a sequential way at server side. I really cannot think a usage scenario of multiple event handler feature of JSF. Even in case of RIAs, I believe what is more required feature is dynamic loading of part of a html page (which is currently the space where AJAX is becoming popular). So any further explanation/example on how you have found this feature of JSF to be useful for RIAs would be helpful for me to understand your point. Regards, Sourav ________________________________________ From: Frank W. Zammetti [EMAIL PROTECTED] Sent: Thursday, July 26, 2007 10:45 AM To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: RE: Is Struts still a better choice over JSF as on today ? On Thu, July 26, 2007 1:23 pm, souravm wrote: > For me so far I don't see any reason why people should go for JSF except > for moving ahead with a standard. As such I don't even see much use of > event handling at UI layer - I always like to keep UI layer simple. But remember that something can be a standard and still not be successful... I wouldn't say that EJBs were unsuccessful, but it's certainly true that people were looking for alternatives almost from the beginning. Witness how quickly Spring gained popularity for instance (note that I'm talking pre-EJB3, which seems to have gotten a ton better). As for event handling on the UI, I do have to disagree there. I think when you start doing a lot of RIA work, event handling is a big consideration. It's one of the reasons I eased up on my JSF criticisms some months ago... while I still think there's better alternatives, it does offer some value in that area, and I think it's an important area. > Now knowing that you have already seen some projects where JSF was used > here are my couple of Qs - > > a) What made them to go for JSF ? I've seen three projects that went with JSF, none of which I was involved in day-to-day development on... with one I know the decision was simply as you said, because JSF is a "standard", and someone thought that was enough of a reason to go with it :) I can tell you that while that project ultimately delivered, it had a ton of pain along the way, more so than if it had gone with something better known, that was the conclusion at the end. I wasn't intimately involved with that project so I don't know all the details, but I do know that some developers I trust said JSF was a headache for them the whole time, even when the learning curve was overcome (that's not necessarily a criticism of JSF mind you, it may well be that it just wasn't the right choice for that particular case). The other two projects went with JSF because the idea of a component-based framework is attractive to many (myself included for the most part). They generally went alright, no huge complaints or anything. I was again not involved in day-to-day development of those, but I didn't hear any big complaints. Interestingly, one of them is now being rewritten using AJAX under Struts 1.2.7 and using a handful of component libraries (YUI, Dojo and APT). The reason for the rewrite: the JSF version had become a pain to maintain (this was a case of the generated code having to be mucked with to get it right, and it turned into a big, heaping plate of spaghetti in the process). This again isn't necessarily a criticism of JSF because it may well be that it just wasn't developed well in the first place, but these are the facts of the case, draw what conclusions from it you may :) The one conclusion I draw from this last experience is that if you use RAD tools and are fortunate enough to never have to mess with the code, JSF is probably no worse than anything else, and probably has some nice benefits. The first time you have to touch the code though, you may be heading down a road you don't want to travel. Me, I don't trust *any* tool to generate code *that* much! > b) What type of RAD tool was used (if at all) ? One of them used no RAD tools at all (interestingly, it was the one that seemed to go the smoothest and isn't be rewritten), the other two used Java Studio Creator. I can't give you any meaningful feedback on that tool though... I've played with it a little, didn't think anything particularly good or bad about it from that admittedly limited experience. I'm very much a text editor kind of guy, so my opinions are frankly tainted by experience hand-coding JSF (which, to be honest, hasn't been all *that* bad really, but I've never done a truly substantial JSF application personally, I've only watched others do so). > Regards, > Sourav Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
