Processing Layers
I’ve been really interested watching the success of John Ressig’s Processing.js.
So much so, it’s inspired me to dust off and release a small processing project which didn’t really have a place in life. I call it Processing Layers.
The Problem
Processing is a domain specific language based on Java. It contains a lot of Java idioms, including packages, objects and classes.
However, it is also aimed at non programmers.
The programming model is contained in a separate IDE, and re-use is only through using libraries.
Sketches are supposed to self-contained, and are not really designed to be re-used.
But, suppose you have a particular favourite way of setting up a sketch, or you’ve crafted a nice lighting configuration so you can drag around the light source with your mouse. Or you’ve got a nice head-up display with the debug information that you find useful. And now you want to use it again in another sketch.
The only way at present is to add a new library, or just copy/paste the code into a new sketch.
A Solution
Enter Layers. This small project is designed to try and re-use sketches. You can download it from here.
This is what layers are for. They are supposed to make re-use of existing sketches easier. Each sketch you already have can be decomposed into one or more layers.
With a handful of layers, making new sketches should become easier: you can compose most of the functionality using a stack of layers, and then add any remaining functionality with a new layer.
The screenshots here show layers derived from the Directional demo and RGB Cube.
But the coolest thing is that the user can toggle each layer on and off at runtime.
Discussion
Any one familiar with the GOF Design Patterns will recognise this pattern.
This is composition over inheritance. Layers are a proxy for PApplet, which pass simply pass through any calls by the layer to the real PApplet.
The PApplet works in the same way it always has, but the sketch – MultiLayerPApplet – is a reusable base class which
• collects Layers
• for each method that the user can implement, simply iterate through each layer, calling the corresponding method.
This is really just a special case of composite pattern – special in that the class that inherits from PApplet isn’t a layer, so you can’t add an instance to itself; I suppose that makes it not really a composite – you can only add leaf nodes to the composite node.
Caveats
So, is this interesting? Maybe.
Is it useful? Currently, in its current form you need to be developing Processing in Java mode.
Difficult to compile
Processing compiles its source code into Java source code, before using the Jikes Java compiler into Java bytecode.
One of the transformations is to wrap the source code in a class definition, which ends in “extends PApplet“. For example the first line of LayerOne.pde sketch compiles to a class which starts:
public class LayerOne extends PApplet
To use LayerOne as a Layer, it should inherit from Layer, and then be added to the a MultiLayerPApplet.
Difficult to run
Processing sketches can be deployed as an applet. However, in its current form, layers can’t be deployed in the same way.
I’ve provided a small application to make it at least usable in your own development.
Extensions
- Is this possible to do as a processing library?
- Could layering be a viable extension mechanism? What would layer development look like?
- If this is interesting enough and can’t be added as a library, how easy would it be to make the core use it?
Technorati tags: processing.org, java
