One of the main reason incorrectly-written Swing apps are bad is that people do work on the event disptach thread (EDT). They'll have some event handler which loads and parses the file right within the event dispatcher itself. If the file can load and parse in 0.05 seconds, fine, but if it takes 0.5 seconds or 1 second or longer, you have a frozen GUI during that time and people start repeating all those things they say about Swing. Anyone who is a real Swing developer moves all that work over to a thread, often one that is written with the friendly SwingWorker class, that lets us do the work and then do more stuff on the EDT (where GUI draws are safe) after the work is done.
The exact same problem comes up in Web applications. You get a request from the user to do a batch update. Wrong: do the batch update within the session bean or servlet that is called during the request. It may not look wrong because during testing, when your table has only 100 rows in it, but when it has 100,000,000 rows on the live system, the response to the browser will time out. What's the JBoss / Seam equivalent of a SwingWorker in this case? Should I create an MDB and queue up the job on it? That seems obvious. It would be cool if there were something as small and light-weight as the SwingWorker though, espeically if it could send "I'm working on it" updates back to the GUI. This seems to be one of the areas of web app building that isn't built out yet or properly understood by a lot of developers, the way SwingWorker is built out for Swing developers. Or else I've totally missed it in the tutorials I've read. I am a newbie to Seam and JBoss so that's very possible. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024919#4024919 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024919 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
