This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Eventful Stuff Feed Title: Travis Griggs - Blog Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml Feed Description: This TAG Line is Extra Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Travis Griggs - Blog

The idea is that, having symbols for event names embedded throughout your object makes it kind of hard to tell what it can do. Sure, there's eventsTriggered, but that doesn't tell you how they usually get triggered. So a protocol such as 'my events' is created. For example:

MyClass methodsFor: 'accessing'
foo: aBar
	foo := aBar.
	self triggerFoo: foo.

MyClass methodsFor: 'my events'
triggerFoo: aBar
	self triggerEvent: #foo with: aBar

In this way, I can quickly browse the events triggered (they're embedded in the method names) AND how they're usually triggered (i.e. with or without an argument). I didn't do this at first; I found keeping track of what events were possible was a pain. Having adopted this convention, I find things much easier to keep track of.

Do you use strong event checking, or weak? Did you know you can turn it on or off? By default it's off. Let's say your class triggers an event called #activated. You're coding along a couple of days later and you want to subscribe to that event. You remember its name basically, but memory being what it is, you remeber it as #activating, minor spelling difference. You hook it up. And then you try to figure out why your code isn't working. It's not working because you setup a handler on an event that's never going to happen. There's a class side method called ambivalentEventChecking which you can override to false (it's a double negative sort of thing). Doing so is very handy. It causes the subscribee to check its known events before setting up a handler. This keeps the above situation from happening. I always override ambivalentEventChecking to return false. I wish the default were set to true, er, uh, false.

Finally, I wonder if others are aware of the EventModels package in the Open Repository? This is basically a modularization of a piece of the Pollock framework. Pollock spawned the creation of things similiar to those found in the existing VisualWorks ValueModel heirarchy, but based around triggered events and kind of clean room implemented. Sames did a pretty good job. You don't need to use Pollock to find these alternate ValueModel thingies handy. I use them in quite a few places. The idea behind factoring EventModels away from Pollock was to allow people to begin using them independent of whether they're using the Pollock Widgets Framework or not. It also allows one to begin to incrementally prepare existing applications to be Pollock-ized. One of the nice things about the ObservedValue, is that it triggers a different kind of event both before AND after it changes. The old framework didn't send out the before notifications.