Extending Groovys Swing User Interface in Builder to Build Richer Applications Danno Ferrin, Intelligent Software Solutions, Inc. James Williams, Spatial Networks, Inc. BOF-5110 Speaker’s logo here (optional)

Learn how to customized Groovy’s SwingBuilder to add custom widgets and non-visual components.

Learn how to customized Groovy’s SwingBuilder to add custom widgets and non-visual components.

Not always an enterprise question… BUT WILL IT S C A L E ?

BUT WILL IT

S C A L E

?

Agenda Ways to Extend SwingBuilder FactoryBuilderSupport Overview Case Study: SwingXBuilder

Ways to Extend SwingBuilder

FactoryBuilderSupport Overview

Case Study: SwingXBuilder

Agenda Ways to Extend SwingBuilder FactoryBuilderSupport Overview Case Study: SwingXBuilder

Ways to Extend SwingBuilder

FactoryBuilderSupport Overview

Case Study: SwingXBuilder

Issues of Scale How you extend should be driven by how much the extension is used Magic Nodes bean(), widget(), container() Individual Factory Registration Automatic Bean Factory Custom Factory Builder Suite Example: SwingXBuilder CompositeBuilder <Coming Soon> Single use of particular widgets Multiple uses of a few types Multiple use of a lot of types Multiple uses from multiple suites

Magic Nodes

bean(), widget(), container()

Individual Factory Registration

Automatic Bean Factory

Custom Factory

Builder Suite

Example: SwingXBuilder

CompositeBuilder

<Coming Soon>

Single use of particular widgets

Multiple uses of a few types

Multiple use of a lot of types

Multiple uses from multiple suites

Magic Nodes bean(…) Accepts any object Not added to parent No child content widget(…) Accepts any java.awt.Component Added to parent java.awt.Container No child content container(…) Accepts any java.awt.Container Added to parent java.awt.Container Accepts child content

bean(…)

Accepts any object

Not added to parent

No child content

widget(…)

Accepts any java.awt.Component

Added to parent java.awt.Container

No child content

container(…)

Accepts any java.awt.Container

Added to parent java.awt.Container

Accepts child content

Magic Nodes An instance of the object must be passed in as the argument Attributes are applied as JavaBeans properties Semi-Magic Nodes Most existing nodes can become magic nodes Argument must match node type

An instance of the object must be passed in as the argument

Attributes are applied as JavaBeans properties

Semi-Magic Nodes

Most existing nodes can become magic nodes

Argument must match node type

Magic Nodes Example bean(model, propertyChanged: { panel.repaint() } ) widget(new JXMonthPanel(), selectedBackground:Color.YELLOW) container(new JXTitlePane(), title:&quot;Demo”) { // whatever you would add in the JXTitlePane }

bean(model, propertyChanged: { panel.repaint() } )

widget(new JXMonthPanel(),

selectedBackground:Color.YELLOW)

container(new JXTitlePane(), title:&quot;Demo”) {

// whatever you would add in the JXTitlePane

}

Individual Factory Registration First, what are the characteristics of the Widget? Well behaved JavaBeans? No-args constructor Bean can be fully configured via properties Complex Beans/Objects Only constructors with arguments Some features configured only by constructor Example: JFrame, JWindow, JDialog owner Non-JavaBeans style properties/configuration

First, what are the characteristics of the Widget?

Well behaved JavaBeans?

No-args constructor

Bean can be fully configured via properties

Complex Beans/Objects

Only constructors with arguments

Some features configured only by constructor

Example: JFrame, JWindow, JDialog owner

Non-JavaBeans style properties/configuration

Individual Factory Registration Well behaved JavaBeans may use registerBeanFactory(…) All lifecycle methods are automated No fancy processing Child nodes added via JComponent.add(child [,constraints]) Some common cases handled based on widget type JTable, Layouts, JScrollPane, java.awt.Window Complex Beans/Objects must use registerFactory(…) Must implement groovy.util.Factory May extend groovy.util.AbstractFactory newInstance(builder, name, arg, attrs) is the only unimplemented method

Well behaved JavaBeans may use registerBeanFactory(…)

All lifecycle methods are automated

No fancy processing

Child nodes added via JComponent.add(child [,constraints])

Some common cases handled based on widget type

JTable, Layouts, JScrollPane, java.awt.Window

Complex Beans/Objects must use registerFactory(…)

Must implement groovy.util.Factory

May extend groovy.util.AbstractFactory

newInstance(builder, name, arg, attrs) is the only unimplemented method

Builder Suite Logical progression from creating factories How? Subclass the SwingBuilder Do factory loading in instance methods Call those methods from the Constructor SwingBuilder factories may be over-ridden SwingBuilder factories may be renamed – getFactories().each {k, v -> registerFactory(&quot;j&quot; + k, v) }

Logical progression from creating factories

How? Subclass the SwingBuilder

Do factory loading in instance methods

Call those methods from the Constructor

SwingBuilder factories may be over-ridden

SwingBuilder factories may be renamed –

getFactories().each {k, v -> registerFactory(&quot;j&quot; + k, v) }

Builder Suite But what if I want multiple suites? JideSplitButton JXMap JRibbon Ways to Add more than one suite Manually add via magic nodes Manual add factories after construction Hand roll a custom suite This can be burdensome…

But what if I want multiple suites?

JideSplitButton

JXMap

JRibbon

Ways to Add more than one suite

Manually add via magic nodes

Manual add factories after construction

Hand roll a custom suite

This can be burdensome…

Composite Builder Coming Soon Won’t be in Groovy 1.6 core The Idea Declare a builder that is a composite of other builders Have each builder use a common Binding Allow children of one builder to nest inside another Widgets from different libraries Nesting non-GUI Widgets tree() { rootFolder { treeNode(); treeNode(); treeNode(); } }

Coming Soon

Won’t be in Groovy 1.6 core

The Idea

Declare a builder that is a composite of other builders

Have each builder use a common Binding

Allow children of one builder to nest inside another

Widgets from different libraries

Nesting non-GUI Widgets

tree() { rootFolder { treeNode(); treeNode(); treeNode(); } }

The Vision def builder = new CompositeBuilder( SwingBuilder, ogb:ObjectGraphBuilder, jx:SwingXBuilder, jide:JIDEBuilder, fl:FlamingoBuilder, nodeName: randomFactory ) builder.jxframe { flribbon { editActionsGroup, saveActionsGroup } jidepopup(visible:false) { … popup contents … } }

def builder = new CompositeBuilder( SwingBuilder, ogb:ObjectGraphBuilder, jx:SwingXBuilder, jide:JIDEBuilder, fl:FlamingoBuilder, nodeName: randomFactory ) builder.jxframe { flribbon { editActionsGroup, saveActionsGroup }

jidepopup(visible:false) { … popup contents … } }

The code as of Today Called ‘UberBuilder’ Available on SVN (only for the brave…) https://svn.codehaus.org/groovy/trunk/groovy/modules/griffon/ GUIBuilder is an auto composite of a few builders SwingBuilder SwingXBuilder JIDEBuilder GraphicsBuilder Not quite soup yet…

Called ‘UberBuilder’

Available on SVN (only for the brave…)

https://svn.codehaus.org/groovy/trunk/groovy/modules/griffon/

GUIBuilder is an auto composite of a few builders

SwingBuilder

SwingXBuilder

JIDEBuilder

GraphicsBuilder

Not quite soup yet…

Agenda Ways to Extend SwingBuilder FactoryBuilderSupport Overview Case Study: SwingXBuilder

Ways to Extend SwingBuilder

FactoryBuilderSupport Overview

Case Study: SwingXBuilder

First some Terminology nodeName( argument, attr : value, attr2 : value) { … } Node Syntactically a method call, but it represents a widget or bean Argument The un-named method argument for the node As of Groovy 1.5 there can be only one Attribute Any named parameter in the node Names cannot be duplicated – enforced by the Compiler Child Content The closure after the method Usually executed by the builder

nodeName( argument, attr : value, attr2 : value) { … }

Node

Syntactically a method call, but it represents a widget or bean

Argument

The un-named method argument for the node

As of Groovy 1.5 there can be only one

Attribute

Any named parameter in the node

Names cannot be duplicated – enforced by the Compiler

Child Content

The closure after the method

Usually executed by the builder

Factory Lifecycle

Delegate Closures Some steps can be intercepted without a Factory addPreInstantiateDelegate, addPostInstantiateDelegate, addAttributeDelegate {FactoryBulderSupport builder, Object node, Map attributes -> … } addPostNodeCompleteDelegate {FactoryBulderSupport builder, Object parent, Object node -> … } Delegates handle all nodes No picking and choosing, each closure must handle every call Some built-in tasks done via delegates Handling of constraints: attributes Handling of id: attributes Handling of bind() and attributes

Some steps can be intercepted without a Factory

addPreInstantiateDelegate, addPostInstantiateDelegate, addAttributeDelegate

{FactoryBulderSupport builder, Object node, Map attributes -> … }

addPostNodeCompleteDelegate

{FactoryBulderSupport builder, Object parent, Object node -> … }

Delegates handle all nodes

No picking and choosing, each closure must handle every call

Some built-in tasks done via delegates

Handling of constraints: attributes

Handling of id: attributes

Handling of bind() and attributes

Agenda Ways to Extend SwingBuilder FactoryBuilderSupport Overview Case Study: SwingXBuilder

Ways to Extend SwingBuilder

FactoryBuilderSupport Overview

Case Study: SwingXBuilder

SwingXBuilder Google Summer of Code 2007 project James Williams – Nova Southeastern University, FL Proof of concept for SwingBuilder extension First Groovy builder in 100% Groovy SwingBuilder later ported to Groovy

Google Summer of Code 2007 project

James Williams – Nova Southeastern University, FL

Proof of concept for SwingBuilder extension

First Groovy builder in 100% Groovy

SwingBuilder later ported to Groovy

Summary SwingBuilder extension is easy Choose your extension method based on frequency of use FactoryBuilderSupport FTW Look to SwingXBuilder to see how it’s been done

SwingBuilder extension is easy

Choose your extension method based on frequency of use

FactoryBuilderSupport FTW

Look to SwingXBuilder to see how it’s been done

For More Information TS-5098 Friday at 12:10 in EP 305 Covers more of the SwingBuilder basics not covered here Groovy http://groovy.codehaus.org/ Builders mentioned in this presentation http://groovy.codehaus.org/Swing+Builder http://groovy.codehaus.org/SwingXBuilder http://groovy.codehaus.org/JideBuilder http://groovy.codehaus.org/JideBuilder Groovy Swing team blogs http://jroller.com/aalmiray http://www.jameswilliams.be/blog http://www.shemnon.com/speling

TS-5098

Friday at 12:10 in EP 305

Covers more of the SwingBuilder basics not covered here

Groovy

http://groovy.codehaus.org/

Builders mentioned in this presentation

http://groovy.codehaus.org/Swing+Builder

http://groovy.codehaus.org/SwingXBuilder

http://groovy.codehaus.org/JideBuilder

http://groovy.codehaus.org/JideBuilder

Groovy Swing team blogs

http://jroller.com/aalmiray

http://www.jameswilliams.be/blog

http://www.shemnon.com/speling

Danno Ferrin, Intelligent Software Solutions, Inc. James Williams, Spatial Networks, Inc. BOF-5110 Speaker’s logo here (optional)