RAD - Case Study Version 2

Mark Wieder mwieder at ahsoftware.net
Mon Mar 27 13:26:29 EST 2006


David-

Monday, March 27, 2006, 2:01:22 AM, you wrote:

> I looked at your example and the ISM stack I have developed is *VERY*
> similar to your mc2_libDispatcher. The only main difference I can see
> is that I have a secondary Message/Event ID which I call a "Kind".  
> This is to allow you to have more than one copy of the same event.

Obviously I can't paste the whole library in here, but yes, the
approach is very similar. Not sure why you need the "Kind" property.
The tuple of sender-message-observer should uniquely identify and
event, no?

> There is also a difference in the way in which your example actually
> uses the Dispatcher, you do your "Listening" or "Registering" at the
> Stack level, which means you have to change the Stack Script when you
> add a control to the stack:

The two lines of code I listed were the *only* changes anywhere. I
cheated and put them into a "Register" button for testing, but they
could have gone into the openStack handler. Interesting idea, though -
I'll have to take a look at your code again. You're saying that the
objects register themselves? Hmmm. That sounds like it's breaking the
Loosely-Coupled Objects pattern. My main goal was to ensure that
controls don't need to know where their events are coming from. Drag
and drop, then connect the dots.

> This means you are hardcoding control names into the stack. I *could*
> do it this way too, but in order to allow objects to be pasted and  
> duped in a stack and have them just work without changing any other
> scripts, I do the "Register" at the control level.

Got it. You change the script of the object when you paste it in. I
went the other way, allowing the objects to be pasted without any
changes. I think I avoided a lot of the pitfalls you're finding. But
the approach sounds equally valid.

> Other than that the concepts are identical!

Yep. The big difference, I think, is that extracting the event
dispatching into a library means that you can instrument a control to
be an event generator with one line of code and you can likewise
instrument a control to receive events with just a setProp handler.
And then the objects are totally reusable.

-- 
-Mark Wieder
 mwieder at ahsoftware.net




More information about the Use-livecode mailing list