Hi Frank, Thanks again for the detailed response.
I think I've got your points. Yes I'm aware of Swing/VB technology and that analogy helped me a lot to understand the perspective. However, I'm still not very sure whether the design approach of Swing/VB is a right fit for a scenario where the underlying technology is http. They are good for a thick client scenario where most of the event handlings happen in client machine (except the events which has to communicate with server). So though design/development wise the component framework may help a lot (after the initial learning curve), efficiency wise how the things will perform (and of course lost of it will depend on the vendors implementation of JSF specification) is a big question to me. Regards, Sourav -----Original Message----- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, July 26, 2007 9:25 PM To: Struts Users Mailing List Subject: Re: Is Struts still a better choice over JSF as on today ? souravm wrote: > Regarding going for JSF due to componentization, I'm again not sure what > additional componentizations JSF does compared to struts. JSF is inherently a component-based framework, meaning you aren't really thinking in terms of pages, your thinking in terms of components of a "view". Struts doesn't really offer this, although S2 gets closer to it in many ways (and yes, there's some JSF support in S2 is you want it, although I'm not too familiar with it myself). > 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. I think your looking at the pieces and comparing them rather than looking at the overarching paradigm of one framework vs. the other. The distinction has been diminished a bit with S2, but it's still there. A component-based approach means your looking at individual elements that make up a a particular view and thinking in terms of the interactions the user can have with each. You don't think in terms of state transitions, you think in terms of events. With Struts, it's about state transitions. The user submits a form and transitions to a new application state entirely. I'm throwing AJAX out of this for the moment of course :) > Also, I'm yet to appreciate the real value add event handling mechanism of > JSF can bring in a web application scenario. It's the ease, in theory, that it provides, and the fact that your inherently thinking along those lines, rather than shoe-horning it in. That's the value-add IML (in theory!) > 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'm not quite sure what you mean by that... > 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. It's not just about partial page loads, although that's clearly a big part of it. As I was describing before, it's more about the approach to developing the application. Are you familiar at all with Visual Basic? If so, let me try and make this analogy... working with JSF is more akin to developing in VB than in Struts because your creating a given view that is a collection of components, and then determining what events each component can trigger, and coding for them. When you write a VB app, you aren't typically thinking in terms of this form leads to that form which leads to another form (unless your talking a wizard flow, but that's a specialized case). With Struts, it's always about a transition from one view to another, from one form to another in VB, triggered by some user input (again, putting AJAX aside for the moment). The VB paradigm, is frankly more logical to most developers. It's more like Swing too if you think about it. Now *with* AJAX in the mix, and with client-side component libraries coming fast and furious, a lot of what made JSF potentially attractive has, again IMO, been significantly diminished. People have realized that you don't need the full JSF stack, so to speak, and you can do components without JSF too, so maybe it's not as valuable. Now, JSF still provides value there because it gives you a standardized component model, something that is sorely lacking in client-side component libraries these days (i.e., Dojo widgets and YUI widgets and APT widgets aren't generally compatible, and certainly aren't designed to some common pattern). That's kind of what's happened in Struts land too... there's been a bit of a melding of the component paradigm and the non-component paradigm, largely with AJAX as the catalyst. > 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]
