hi seth, > It's really *intended* for synthetic events, and offers an approach to > writing applications that is entirely based on synthetic events, > versus hard-linking of your app's various classes together.
hmm.. I've had a more closer look to synthetic events. certainly they can be used to achieve what I'm after. but I'm not sure I am completely happy with the solution. synthetic events (like all events) have to have a target element which for a more general class/object interaction might not be useful. of course you can always choose any element even the window element but i think this is not useful. especially adding elements to the dom just to have a target at all should not be the way to go imho. if you need your classes to interact on events/messages there should be a direct way. an element just to carry the event is an unnecessary vehicle. also I really do like the api colin suggested earlier on. it allows you to register many responders (observers) to many messages (events) in one single and compact call. I think this is more useful for this general purpose because it keeps your code clean and structured. instead of having many Event.observe() calls you will only have one Message.Responders.register() call with all callbacks neatly packed into its argument. this is more prototype style I think. (side note: it could be a good idea to have Event.observe() taking multiple observers at once) of course you could extend Object to dispatch events as elements do and directly use your class objects as event targets but then again wouldn't this be over the top? cheers /christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
