{"id":1533,"date":"2014-11-17T16:49:20","date_gmt":"2014-11-17T14:49:20","guid":{"rendered":"http:\/\/www.ozalto.com\/?p=1533"},"modified":"2014-11-17T16:49:36","modified_gmt":"2014-11-17T14:49:36","slug":"event-driven-programming-with-extendscript","status":"publish","type":"post","link":"http:\/\/www.ozalto.com\/en\/event-driven-programming-with-extendscript\/","title":{"rendered":"Event-Driven Programming with ExtendScript"},"content":{"rendered":"

Several years of using Adobe Flex and ActionScript<\/strong> have used us to Event-driven programming.<\/strong> In other words, get separate\u00a0pieces of code to communicate\u00a0without direct linking<\/strong> to each other. Events can mean UI events<\/strong> (buttons clicks\u2026) or even application related events<\/strong> (menu calls, documents openings). But we want to talk about something else here.<\/strong> We would like to introduce our own event class in ExtendScript.<\/strong> Our goal : script “\u00e0 la Flex”.<\/p>\n

<\/p>\n

Once you get large\u00a0scripts, it’s better to split your code into separate pieces.<\/strong> Once that done you can easily gather them with the “#include” statement. Then you need to maintain communication between those dependancies.<\/strong> For example, you may need to call a function located in dependancy B from inclusion\u00a0A. Of course you can explicitly call some dependancy. Problem is it can be confusing at some point and will prevent your code from being easily reusable.<\/p>\n

As an answer, we propose a custom class that will allow our dependancies to communicate with a maximum of abstraction.<\/strong> We got inspired by EventBroker<\/a>, a work done by\u00a0developmentarc-core. It intends to decouple event communication between multiple classes in an AS3 project. We don’t actually port it in ExtendScript. We designed our own class\u00a0thus sharing the same intention.<\/p>\n

A) Include\u00a0“EventManager”<\/h3>\n

Prior to use it, just include EventManager with the following syntax :<\/strong><\/p>\n

#include 'EventManager.jsinc'\r\n<\/pre>\n
Then\u00a0it’s fully usable.<\/strong> You can now make interact your dependancies with a well known syntax.<\/p>\n
B) Use\u00a0EventManager<\/h3>\n
Of course, before you can react to some events, you need to listen for it. We are about to add a listener<\/strong> for our generic event :<\/p>\n
var eventHandler = function(){alert(\"Event was triggered\")};\r\nEventManager.addEventListener ( \"EVENT_FIRED\", eventHandler );\r\n<\/pre>\n
To fire an event,<\/strong> we will write:<\/p>\n
EventManager.dispatchEvent (\"EVENT_FIRED\");\r\n<\/pre>\n
\"EventManager<\/a>
\nIn order to carry some data,<\/strong> we just need to use this :<\/p>\n
var eventHandler = function(data){alert(data)};\r\nEventManager.addEventListener ( \"EVENT_FIRED\", eventHandler );\r\nEventManager.dispatchEvent (\"EVENT_FIRED\", \"Hello there !\");\r\n<\/pre>\n
To\u00a0remove a listener,\u00a0 <\/strong>il\u00a0suffit d’\u00e9crire :<\/p>\n
EventManager.removeEventListener ( \"EVENT_FIRED\", eventHandler );\r\n<\/pre>\n
C) EventManager &\u00a0ScriptUI<\/h3>\n
Some possible use is within a ScriptUI project<\/strong>. There are internal mechanisms for events handling<\/strong> but we found it useful to add\u00a0EventManager in the\u00a0loop.<\/strong> For one project, we needed very complex UI and nothing good could be got from the LayoutManager<\/strong>, a native process to organize the window. Items weren’t correctly sized or located\u2026A total mess. We came to the conclusion that we should take care of it by our own.<\/strong> So basically, it was to capture the moment where the window would be drawn and ready for edition. As we used separate UI components, all of them would have to listen for the window completion event<\/strong>\u00a0using the native event method onShow.<\/p>\n
var w = new Window('dialog');\r\nw.onShow = function()\u00a0{\r\n\/\/dialog is now open. Do something then.\r\n}\r\n<\/pre>\n
Problem\u00a0: How to reach\u00a0“w”<\/strong>\u00a0within all dependancies ? Global variable?\u2026No way. A function argument?\u2026Maybe. Isn’t that more painful than it need to be ? What if we listen for this event once and for all<\/strong> in the script file contaning the window object (w) and then use EventManager to propagate the event through all dependancies ?<\/strong><\/p>\n
\/\/MAIN WINDOW => window.jsx\r\nvar w = new Window('dialog');\r\nw.onShow = function()\u00a0{\r\nEventManager.dispatchEvent ( \"WINDOW_SHOWN\", w);\r\n}\r\n\r\n\/\/UI COMPONENT => uiComponent.jsinc\r\nvar p = parentUI.add('panel');\r\nvar resizeFunction = function(w) {\r\np.size.width = w.size.width\/2;\r\n}\r\nEventManager.addEventLister ( \"WINDOW_SHOWN\", resizeFunction );\r\n<\/pre>\n
That way, we don’t have to worry about the chain of events propagation and items initialization. Who will be drawn first ? Will my item be accessible at that time ? Etc.<\/p>\n
\"EventManager<\/p>\n
D)\u00a0Conclusion<\/h3>\n
We do no longer script without EventManager. We are not claiming any superiority. We just wanted to share a method of ours with its intrinsic qualities. EventManager has brought us all the smoothness and reactivity we need. We hope you will find it handy. If so, feel free to comment about it below.<\/p>\n
See you soon,<\/p>\n
Download EventManager<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Several years of using Adobe Flex and ActionScript have used us to Event-driven programming. In other words, get separate\u00a0pieces of code to communicate\u00a0without direct linking to each other. Events can mean UI events (buttons clicks\u2026) or even application related events (menu calls, documents openings). But we want to talk about something else here. We would […]<\/p>\n","protected":false},"author":2,"featured_media":1537,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[43,42,5],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/posts\/1533\/"}],"collection":[{"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/posts\/"}],"about":[{"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/types\/post\/"}],"author":[{"embeddable":true,"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/users\/2\/"}],"replies":[{"embeddable":true,"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/comments\/?post=1533"}],"version-history":[{"count":0,"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/posts\/1533\/revisions\/"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/media\/1537\/"}],"wp:attachment":[{"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/media\/?parent=1533"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/categories\/?post=1533"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.ozalto.com\/en\/wp-json\/wp\/v2\/tags\/?post=1533"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}