Based on all related answers, I decided to agree with Laurie's definition:
...the event naming should be based on the semantics of what happened, not
> on what module noticed it happen
Therefore, started to name my events with a more descriptive way, like this:
- onServiceDrop
- onServiceSaved
- onModalProcessCompleted
- onModalProcessStarted
- onUserRegistered
And so on… I hope there will be no matched events names in the future, but
event if there will be, I am protecting myself with checking data object
keys and values inside each module listen event function.
sandbox.events.listen({
> name: "onServiceDrop"
> }, function(event){
> var data = event.data;
> if (data.key1 && data.key2){
> // only than I'm doing an action
> }
> });
Therefore, I feel quite safe with that approach!
- - -
Nikita Sumeiko
On Mon, Aug 22, 2011 at 8:13 PM, Laurie Harper <[email protected]> wrote:
> On 2011-08-22, at 1:38 PM, Scott Sauyet wrote:
> > Laurie Harper wrote:
> >> If you start using 'internal' identifiers in your events, your
> >> sandbox is leaking. Why go to the trouble of hiding the object
> >> types and decoupling everything if you're just going to couple
> >> it up again by exposing implementation details in string
> >> identifiers?
> >
> > I think it's simply a matter of namespacing shared keys in a publish-
> > subscribe registry. It's not a matter of exposing implementation
> > details.
>
> There's a difference between an event descriptor that says 'secret code
> entered', one that says 'secret code was typed in using a keyboard', and one
> that says 'entry of secret code was detected by the "keyboard" module'...
>
> In other words, the event naming should be based on the semantics of what
> happened, not on what module noticed it happen.
>
> > Of course your modules should be decoupled as much as is reasonably
> > possible, but a namespacing scheme like Jarek described ("keyboard-
> >> onSecretCodeEntered") seems reasonable. You don't have to know
> > anything about the keyboard module to listen for such events. For all
> > you know there is no module named "keyboard", but, through the
> > sandbox, you can listen whenever something generates this particular
> > event. The namespacing is not central, but it makes it easier. For
> > example, in an application that represents some card game, it's really
> > nice to be able to distinguish "deck->draw" events from "screen->draw"
> > ones.
>
> Those are both examples of semantic event descriptors; I agree that
> namespacing your events makes sense. You just need to be sure you're using
> something that describes what happened, not how it happened or where it was
> detected.
>
> Tying event names to the name of the module generating them makes it
> impossible to switch modules out, thus defeating the objective of decoupling
> modules. Being over-specific with event names also reduces your flexibility;
> what if you want to add support for entering a secret code via a bio-metric
> device? The word 'keyboard' in the event name is suddenly kinda dubious...
> Use a namespacing scheme that reflects *just* the semantics you want to
> capture.
>
> L.
>
> >
> > -- Scott
> >
> > --
> > To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/[email protected]/
> >
> > To search via a non-Google archive, visit here:
> http://www.mail-archive.com/[email protected]/
> >
> > To unsubscribe from this group, send email to
> > [email protected]
>
> --
> Laurie Harper
> http://laurie.holoweb.net/
>
> --
> To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/[email protected]/
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/[email protected]/
>
> To unsubscribe from this group, send email to
> [email protected]
>
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
