{"id":146,"date":"2020-12-16T23:52:56","date_gmt":"2020-12-16T21:52:56","guid":{"rendered":"http:\/\/www.mbarsinai.com\/blog\/?p=146"},"modified":"2021-04-10T20:22:09","modified_gmt":"2021-04-10T18:22:09","slug":"panelmatic-101-reprint","status":"publish","type":"post","link":"https:\/\/www.mbarsinai.com\/blog\/2020\/12\/16\/panelmatic-101-reprint\/","title":{"rendered":"PanelMatic 101 (Reprint)"},"content":{"rendered":"\n

Long long time ago, I can still remember, how I used to do Java Swing applications for living. Swing has a lot of strong points, and I really admire its design and architecture. When one needs to make a desktop application in Java, it still rocks. Of course, Swing is not bereft of annoyances. One of these is creating panels with complex layouts.<\/p>\n\n\n\n

To my pleasant surprise, I had some Swing-related projects recently. So I revived an old open-source library of mine, which was originally hosted on Kenai.com (yes, that was that<\/em> long ago). It was called “PanelMatic”, and it enjoyed a mild success back then.<\/p>\n\n\n\n

So, PanelMatic is back<\/a>. It’s using Java 11, it’s on GitHub<\/a>, and it’s on its way to<\/s> Maven Central. Below is an slightly modified intro that was published originally at Java.net (yes, that was that<\/em> long ago).<\/p>\n\n\n\n

\n\n\n\n

PanelMatic 101<\/h2>\n\n\n\n

Every Swing developer knows this feeling: you’ve got the design of a UI panel. It’s the ‘right’ design. It ‘works’. It’s what the user would expect. Hell, it’s even what you would expect had you been the user. But it is going to be an awful lotta’ coding to lay it out in Swing – even before you take into consideration issue like panel re-sizing and localization.<\/p>\n\n\n\n

Some developers nest numerous panels to get it working. Some try to “fake it” using the null<\/code> layout (please, don’t). Others try to fit everything into a single panel and use the GridBagLayout<\/code> – this involves quite a bit of trial-and-error, as can be seen in this<\/a> documentary. Some even turn to graphical UI builders, which does not support dynamic panel creation, and whose designs are hard to maintain.<\/p>\n\n\n\n

I’d like to suggest a slightly better solution: PanelMatic.<\/p>\n\n\n\n

\"\"
Figure1: Sketch => Code => GUI<\/figcaption><\/figure>\n\n\n\n

PanelMatic allows swing developers to create common UI panels with ease. Panels are built top-to-bottom (or, more precisely, on the page axis). There is an intuitive connection between the way the code looks and the way the created panel will look. Components can be added to the panel with a label and\/or an icon (lines 3-7 in Figure 1), or alone (line 9). By default components stretch to occupy all the space they get, but this can be changed using modifiers (lines 9, 10). L_END<\/code> (stands for “line end”) and GROW<\/code> (stands for “grow”) are statically imported constants, and are in fact full-blown objects that implement the BehaviorModifier<\/code> interface – so you can create your own modifiers if you need ’em. Client code can add headers (lines 2, 8) and flexible spaces (not shown). The default implementation uses a pluggable component factory to create all the extra components involved (e.g. JLabel<\/code>s), so you can customize them when the defaults won’t do.<\/p>\n\n\n\n

As you’ve probably guessed, panels are built by builders that are obtained by invoking a static method on the PanelMatic<\/code> class. PanelMatic is designed around an API\/SPI approach – all the client code gets to hold is an interface, so the implementation can be changed without affecting client code at all. Builders are pooled, so you don’t have to think twice before asking for one. You can create your own implementation – just implement the service provider interfaces, and point the PanelMatic<\/code> class to it. This can be done either by code or via a system property.<\/p>\n\n\n\n

So this is PanelMatic. Use it to create common UI panels quickly, and use your freed up time to go to more meetings and catch up on some quality powerpoint presentations. <\/p>\n\n\n\n

We could stop here, but we’d be missing half the fun.<\/p>\n\n\n\n

Beyond Layout<\/h3>\n\n\n\n

PanelMatic’s approach to building UI panels allows for some surprising improvements over normal layout-based code. Here are some of my favorites.<\/p>\n\n\n\n

Customizers, or Listening to All Components<\/h4>\n\n\n\n

Components are passed to the builder, and eventually get added to the produced panel. But before they are, they pass through a chain of PanelMaticComponentCustomizer<\/code>s, or “customizers”, for short. Each builder has two customizer chains – one that applies to all the panels it builds, and one for the current panel being built. The latter is disposed after the get()<\/code> method is called. Customizers have a customize<\/code> method, which gets an returns a JComponent<\/code>. This allows client code to apply uniform customizations to all components in the created panel, or in the application in general. These customizations can be used for, e.g:<\/p>\n\n\n\n