Yes, my JS architecture contains of single encapsulated modules. Each has
limited knowledge and know only about himself. However, each module is able
to throw events into Sandbox and those events are able to be listened by
other modules. Therefore, I am trying to find the most semantic and easier
way to name those events thrown by modules.
And I'm not sure, that event with a name "drop" semantically explains
itself, because there might be different drops in different modules.
Therefore, I have somehow to clarify at least drop holder to get understand
modules where something has been dropped.
After @Jareks email, I tried to do so:
sandbox.events.say({
name: "onIconDrop",
module: "Left icons holder"
data: {
"id": 3,
"coordinates": {
"x": 25,
"y": 69
}
}
});
When trying to explain module speech in text, looks quite understandable:
"icon has been dropped into Left icons holder".
And here's how another module reads this event:
sandbox.events.listen({
name: "onIconDrop",
module: "Left icons holder"
}, function(event){
// do something
});
However, when saying in a simple language: "current module listens when icon
has been dropped to Left icons holder". And that's a point, that this
expands current module knowledge, what is wrong I think. Wrong, only if we
take modules encapsulated philosophy.
Now I'm really thinking, that event have to contain information not just
about event name, "drop" as an example. Because when you have 10 modules,
and there're several "drop" events said by different modules, you have to
clarify them somehow inside modules, which listens to them?! Otherwise, it's
get messy.
I'm still in doubt!
Nikita Sumeiko
On Mon, Aug 22, 2011 at 3:29 PM, Jarek Foksa <[email protected]> wrote:
>
> Well, there are several approaches to custom events.
>
> I was watching Nicholas's presentation long time ago, but if I recall
> correctly, his idea was to have single messaging bus (represented by
> sandbox object) that could be used for exchanging data between
> modules. In this pattern modules do not know about each other, so you
> can't "subscribe" to events fired by another module, you can only
> listen to the what is coming from sandbox object.
>
> Here is a link to the whole presentation:
> http://yuilibrary.com/theater/nicholas-zakas/zakas-architecture/
>
> On Mon, Aug 22, 2011 at 2:49 PM, Dmitry Pashkevich <[email protected]> wrote:
> > I may have missed the point but I don't think that event name should
contain
> > the name of the module or class that fires them. Because when you listen
to
> > the event you access the object that fires it anyway:
> > myButton.listenEvent('toggle', function() {...});
> > myDndManager.listenEvent('drop', function() {...});
> >
> > So why should I name events like 'DndManager->drop'? Even if you need to
> > dynamically determine the object that fired the event you can always
include
> > the object itself in event parameters:
> > this.fireEvent('drop', this, data)
> >
> > Also, are you trying to implement the pubsub model or the 'regular'
event
> > model where one object directly subscribes to events of another object?
> >
> > --
> > 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]
--
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]
