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