Ironic Wolf

In Ruby Inox Part 4: Property I described I would like to see properties in a GUI toolkit. Since then I worked hard to stabilized the code and the module Property profited from the experience gained by rethinking the way of the Actions module should work.

Basic Usage

The usage scenario didn’t change, as short introduction for the new readers, let me show you an example:

	class Widget
		includes Properties
		properties {
			title { type String; readwrtie; default "New Widget" }
		}
	end

	class Button < Widget
		def initialize
			title.default = 'Button' # change the default setting
		end
	end

	b = Button.new
	b.title = 'Hello' # assignment by operator
	b.title # returns  => 'hello'
	b.title 'foo'  # assignment by parameter
	b.title # returns => 'foo'

Inheritance

Like the actions module, the properties are partially inheritance friendly. Later modification by the parent class at the class level are not reflected across the hierarchy.

Subclassing made easy

I had troubles myself in keeping the code clean as every subclass has less or more the requirement to provide its own values for a given property. Ruby attr_accessors has less baggage than the ideal property I want. The default properties method should be guaranteed to always behave as expected.

So I introduced two methods that can be overridden by the subclass: set_>property_name< and get_>property_name<. So in the last example the Button class can provide its values without touching the default methods.

	class Button < Widget
		def initialize
			title.default = 'Button'
		end

		def get_title
			@osx_button.title.to_s
		end

		def set_title(a_title)
			@osx_button.setTitle(a_title)
		end
	end

Upcoming

Notification of change. In a fictional widget class with a property called f.ex frame, the first thing I needed was an action to notify me when the frame was changed.
The quick solution; I have overwritten the set_frame method just for the sake of being notified that the frame was changed. I saw myself repeating that pattern for other properties, all over the place.

The next evolution of the properties module should check if the class is using the actions module. In that case creates a default changed action, like title_changed(new_value). So we can take full advantage of the Action module and simple define title_changed!(value) to get the work done and not use the setters/getters for update purpose.

Ruby Inox on GitHub

This file is part of the Ruby Inox project. Inox is a work in progress and this file might not be up to date. The status and latest files are available on GitHub

Related posts:

1. Ruby Inox Part 4: Property Last time, we took a look at Actions. A standard...
2. Ruby Inox Part 3.1: Actions Here is a short update for the Ruby Inox Part3:...
3. Ruby Inox Part 6: Widget We are steering toward a graphical user interface. In this...
4. Ruby Inox Part 3: Actions Here is the pursuit of a series of related articles...
5. Ruby Inox Part 7: Native Originally this article formed one article with Ruby Inox Part...

Tags: cross language, Inox, Inox Property, module, oo model, Ruby, Ruby Inox, Ruby Inox Property

This entry was posted on Thursday, May 21st, 2009 at 3:37 pm and is filed under Ruby. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.