Comments on: Thoughts on an MVC framework for Swing http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/ Sam Newman's blog Fri, 21 Nov 2008 23:23:48 +0000 http://wordpress.org/?v=2.6.3 By: Sam Newman http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-186 Sam Newman Thu, 19 Feb 2004 12:23:35 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-186 From looking over the Wiki pieces detailing integration of Spring (http://wiki.opensymphony.com/space/Spring+Framework+Integration) and Pico (http://wiki.opensymphony.com/space/PicoContainer+Integration) with WebWork 1.4, it seems they can be used as the Action respositories as opposed to WebWork itself. If the same applies for XWork, then assuming you can get a third party IoC framework integrated the problem of registering actions in a seperate file goes away as you register them there (reading between the lines of the XWork wiki I get the impression that XWork attempted to use Pico internally to provide IoC features a while back, but I might be wrong). From looking over the Wiki pieces detailing integration of Spring (http://wiki.opensymphony.com/space/Spring+Framework+Integration) and Pico (http://wiki.opensymphony.com/space/PicoContainer+Integration) with WebWork 1.4, it seems they can be used as the Action respositories as opposed to WebWork itself. If the same applies for XWork, then assuming you can get a third party IoC framework integrated the problem of registering actions in a seperate file goes away as you register them there (reading between the lines of the XWork wiki I get the impression that XWork attempted to use Pico internally to provide IoC features a while back, but I might be wrong).

]]> By: Jon Tirsen http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-185 Jon Tirsen Thu, 19 Feb 2004 11:59:44 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-185 Jason, the most annoying thing with XWork is that you have to define your actions and their bindings in a separate XML file. Definining things in XML files was very trendy a couple of years ago but I've moved away from it completely and I also notice a lot more people doing that aswell. The problem with XML files are that it's not a very powerful language, you don't get compile time checking and it's hard to get it to work really well with refactoring IDEs. With the birth of JDK 1.5 metadata I suspect that the Java community will completely move away from XML based stuff within a couple of years. Jason, the most annoying thing with XWork is that you have to define your actions and their bindings in a separate XML file. Definining things in XML files was very trendy a couple of years ago but I’ve moved away from it completely and I also notice a lot more people doing that aswell.
The problem with XML files are that it’s not a very powerful language, you don’t get compile time checking and it’s hard to get it to work really well with refactoring IDEs.
With the birth of JDK 1.5 metadata I suspect that the Java community will completely move away from XML based stuff within a couple of years.

]]> By: Sam Newman http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-184 Sam Newman Wed, 18 Feb 2004 15:07:03 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-184 Point taken Kevin. I'm going to see if XWork will let me do what I want - if not, I'll either try and change it so it can or look elsewhere... Point taken Kevin. I’m going to see if XWork will let me do what I want - if not, I’ll either try and change it so it can or look elsewhere…

]]> By: Kevin Dangoor http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-183 Kevin Dangoor Wed, 18 Feb 2004 14:32:26 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-183 The problem with making a framework that works with both web and Swing is that the interaction models are different. The web is (generally, unless you're doing fancy javascript) based on discrete requests which result in complete new page output. Swing can (and should) have all sorts of things (big and small) that can happen on a single screen. There is undoubtedly a whole bunch of code that can be shared between Swing and web implementations of an app. I'm just saying that you don't want to sacrifice Swing interactivity by using a framework suited for the web. The problem with making a framework that works with both web and Swing is that the interaction models are different. The web is (generally, unless you’re doing fancy javascript) based on discrete requests which result in complete new page output. Swing can (and should) have all sorts of things (big and small) that can happen on a single screen.

There is undoubtedly a whole bunch of code that can be shared between Swing and web implementations of an app. I’m just saying that you don’t want to sacrifice Swing interactivity by using a framework suited for the web.

]]> By: Sam Newman http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-182 Sam Newman Wed, 18 Feb 2004 13:29:21 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-182 The MVC used within Swing can be considered to be very localised - that is one MVC instance is used within the scope of getting a table to work, another within the scope of a combobox etc. They help seperate content from presentation within a very small scope, and by and large work well. They do nothing to help seperate your GUI layer from any backend business processing. I see the GUI layer including JTables TableModels, which are used to create commands. These commands are sent and processed by the next layer, which responds by telling the GUI layer to change (e.g. display error message, display this view etc). The MVC used within Swing can be considered to be very localised - that is one MVC instance is used within the scope of getting a table to work, another within the scope of a combobox etc. They help seperate content from presentation within a very small scope, and by and large work well. They do nothing to help seperate your GUI layer from any backend business processing. I see the GUI layer including JTables TableModels, which are used to create commands. These commands are sent and processed by the next layer, which responds by telling the GUI layer to change (e.g. display error message, display this view etc).

]]> By: Rafael Alvarez http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-181 Rafael Alvarez Wed, 18 Feb 2004 13:10:51 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-181 Food for though: Why is that all MVC implementations seems to use the Command pattern? If you look into the Swing model there are complete MVC implementations (JTable comes to mind) WITHOUT commands. Food for though: Why is that all MVC implementations seems to use the Command pattern? If you look into the Swing model there are complete MVC implementations (JTable comes to mind) WITHOUT commands.

]]> By: Sam Newman http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-180 Sam Newman Wed, 18 Feb 2004 10:20:05 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-180 Excellent - thanks for the link Jason! Excellent - thanks for the link Jason!

]]> By: Jason Carreira http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-179 Jason Carreira Tue, 17 Feb 2004 21:36:06 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-179 You just decribed XWork: http://wiki.opensymphony.com/space/XWork XWork is a generic Command Pattern implementation that is used as the core of WebWork2. You could define your Actions in an XML file, decoupling your screens from the classes which they execute, and get the power of Interceptors, type conversion, validation, etc. XWork already has the concept of a generic Result Interface. In WebWork, this can be a dispatch to a JSP or a redirect, or JasperReports to generate a PDF. In a Swing wrapper on top of XWork this could be a refresh of the current screen or telling it to show a new screen. Shouldn't really be that difficult. You just decribed XWork:

http://wiki.opensymphony.com/space/XWork

XWork is a generic Command Pattern implementation that is used as the core of WebWork2. You could define your Actions in an XML file, decoupling your screens from the classes which they execute, and get the power of Interceptors, type conversion, validation, etc. XWork already has the concept of a generic Result Interface. In WebWork, this can be a dispatch to a JSP or a redirect, or JasperReports to generate a PDF. In a Swing wrapper on top of XWork this could be a refresh of the current screen or telling it to show a new screen.

Shouldn’t really be that difficult.

]]> By: Sam Newman http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-178 Sam Newman Tue, 17 Feb 2004 21:12:30 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-178 Thanks for the link - I'll look into that. Thanks for the link - I’ll look into that.

]]> By: Whatever http://www.magpiebrain.com/blog/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-177 Whatever Tue, 17 Feb 2004 21:07:53 +0000 http://www.magpiebrain.com/2004/02/17/thoughts-on-an-mvc-framework-for-swing/#comment-177 http://scope.sourceforge.net/ http://scope.sourceforge.net/

]]>