My comments embedded. Regards, Sourav
-----Original Message----- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, July 30, 2007 7:20 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 Mon, July 30, 2007 9:39 am, Ted Husted wrote: > On 7/29/07, souravm <[EMAIL PROTECTED]> wrote: >> 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. Ted is spot-on with his comments, and I'm in the same situation: most of my development is Intranet-based, the network is rarely the bottleneck (although it's more interesting when your previously internal application is now accessed remotely by clients, which happens often enough in my line of work). <Sourav> I've gone through his mail. Me too agree with him completely. I wanted to mention though with regard to what you said about event handling and bandwidth... you mentioned you had some VB experience, so think about that experience and answer this question: when some user event occurs, what winds up happening a large percentage of the time in a typical app? Let's say the user clicks a button... what does the code behind that button do? Does it just do some simple UI thing like enable another button? Or is it more times than not hitting a database and doing some processing? <Sourav> In my experience it is always a mixed thing. However, with a thick client application the advantage is you can even cache much of data at client side. So even some business logic related calls need not go to server side always. This is an important question because, at least in my experience, it's more times than not some database call and some processing. In that case, there's not as much difference between that and a well-designed webapp, *especially* if your using AJAX (and remember JSF offers AJAX capabilities too, so it's not either-or). The simple UI events can be handled entirely client-side in a webapp too, making that difference not very great either. <Sourav> Regarding JFS and AJAX. I'm bit confused. Are you saying JSF out of the box provides AJAX like partial page loading support (then it is something which I was missing so far in my JSF understanding)? Or do you mean a JSF application can also use AJAX (which I understand) so you can use best of both worlds in an application. As far as bandwidth goes, I've done a decent amount of analysis comparing an AJAX-based application to a typical webapp and have found that the overall bandwidth usage is actually less with an AJAX app most of the time. Now, where you can definitely run into issues is in too many connections to the server, and the delay in tearing down and creating those connections each time. However, as with most things, better design work can alleviate these issues to a large extent. I'm not of the opinion that we should push business logic onto the client, but there *is* a lot of processing that people typically do on the server that you can do on the client and still maintain a good design, and that helps. <Sourav> Do you think JSF's design paradigm encourages/helps doing lot of things at client side (wherever it makes sense efficiency wise)? My take is it does otherwise. The interesting thing I've found over the last year is that mindset is more important than technology (not exactly a revelation, but it was reinforced)... with the application I described earlier, I lead a team of developers who didn't have any experience with AJAX, and it took probably 6 months to get them thinking differently... they were used to doing non-AJAX webapps, so just one example, they decided for one portion to stash a bunch of stuff in session. All along I was telling them it wasn't a good idea, better to keep that stuff client-side (yes, I could have pushed things and had it done my way, but that's not the way you respect your team IMO)... now, they got it working using session, but they've come back around and admitted it would have been a lot easier to not use session. But that's just a mindset thing: if you don't trust the client (to some extent), and you aren't used to thinking client-side, you make those types of decisions. I doubt there's any difference there between JSF, Struts or anything else. There's nothing inherently wrong with that mindset by the way, it's just that in this day and age of richer clients, it can lead to decisions that, while not technically wrong, aren't optimal either. <Sourav> Agreed fully. Frank --------------------------------------------------------------------- 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]
