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). 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? 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. 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. 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. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
