Comments on: The Joy of Writing Swing Frameworks http://benzilla.galbraiths.org/2007/04/30/the-joy-of-writing-swing-frameworks/ Ben is Vice President of Mobile Engineering at Walmart.com, where he works closely with his long-time friend Dion Almaer. Wed, 25 Jan 2012 19:56:40 +0000 hourly 1 http://wordpress.com/ By: Glenn Vanderburg http://benzilla.galbraiths.org/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2886 Wed, 02 May 2007 13:30:34 +0000 http://galbraiths.org/blog/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2886 True properties might solve this particular case, but they wouldn’t solve the general problem.

]]> By: Brendon McLean http://benzilla.galbraiths.org/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2891 Tue, 01 May 2007 21:20:46 +0000 http://galbraiths.org/blog/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2891 Spot on. I’ve run in the same thing many times. As a rule, I always add addFocusListener delegate methods to all my compound components which simply delegate the call to the textfield.

]]> By: Mikael Grev http://benzilla.galbraiths.org/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2890 Tue, 01 May 2007 20:40:28 +0000 http://galbraiths.org/blog/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2890 If Java had proper properties this wouldn’t be an issue. I mean properties that can reference complex objects, such as an embedded JTextField, wich properties itself can be drilled down to and set/unset, and so on..

Swing was made for flexibility without considering tool-ability. This can only be fixed with a refactor to Swing 2.0. It wouldn’t take much effort compared to rewriting a new GUI toolkit, but it would solve so many problems.

Cheers,
Mikael

]]> By: Glenn Vanderburg http://benzilla.galbraiths.org/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2889 Tue, 01 May 2007 17:46:51 +0000 http://galbraiths.org/blog/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2889 Language support for expressing contracts is one way to approach this kind of thing, but there’s another way that isn’t as widely used as it should be.

If you’re building a library that’s meant to be used and extended by third parties, write a set of abstract unit test classes that test for adherence to the contract. This is usually pretty easy to do. Then recommend that people extending your classes or implementing your interfaces (including your own group, of course) use those tests. A new testcase that extends the abstract one and overrides setUp is usually sufficient, and then all of the inherited tests will be run against the subclass or new implementation.

—Glenn

]]> By: Ben Galbraith http://benzilla.galbraiths.org/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2887 Mon, 30 Apr 2007 21:52:22 +0000 http://galbraiths.org/blog/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2887 Anjan: It absolutely does. There’s a ton of room for productivity frameworks on top of Swing in the marketplace.

]]> By: Anjan Bacchu http://benzilla.galbraiths.org/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2888 Mon, 30 Apr 2007 21:46:43 +0000 http://galbraiths.org/blog/2007/04/30/the-joy-of-writing-swing-frameworks/#comment-2888 hi ben,

does this NOT give scope to someone who wants to write the next onTopOfSwing framework, like say, spring RIA ?

And, like RodJohnson, if someone writes a decent book about that framework/library, then writing swing apps becomes a lot more easier.

BR,
~A

]]>