From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (mailfrom) identity=mailfrom; client-ip=8.23.224.61; helo=out.smtp-auth.no-ip.com; envelope-from=kevin@carhart.net; receiver= Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.61]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 2328C779AA for ; Sat, 9 Dec 2017 22:37:15 -0800 (PST) X-No-IP: carhart.net@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from carhart.net (unknown [99.52.200.227]) (Authenticated sender: carhart.net@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id 3F6F3568 for ; Sat, 9 Dec 2017 22:39:21 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id vBA6dHEg028271 for ; Sat, 9 Dec 2017 22:39:17 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id vBA6dHLn028267 for ; Sat, 9 Dec 2017 22:39:17 -0800 Date: Sat, 9 Dec 2017 22:39:16 -0800 (PST) From: Kevin Carhart To: edbrowse-dev@lists.the-brannons.com In-Reply-To: <20171105115426.eklhad@comcast.net> Message-ID: References: <20171105115426.eklhad@comcast.net> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Edbrowse-dev] what is dispatchEvent and is it needed? X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 06:37:16 -0000 Since we started talking about events, I felt like I needed to reacclimate myself with whether there is a point to some of these functions with Event in their name. Currently the first occurring runtime error in one of the sites we're testing on, xqsuperschool.org, involves dispatchEvent. But what does it do? I looked it up and found out. The flavor of why dispatchEvent is used is a little like calling raise() in code. It's like you're simulating something. So the role for dispatchEvent would be if you want to call an event handler from elsewhere in the code. If there is a button1 with a handler on click, the users might click the button and the handler code would run. But if you want to trigger that code and you want to do it "the right way", you do it via interacting with that element. So you call dispatchEvent(button,"click") and you have done just what your user would have. An MDN page says "Such events are commonly called synthetic events, as opposed to the events fired by the browser itself." It reminds me of OO. You're reaching the handler code by addressing it through a published way of reaching it. It reminds me of public and private members, and that type of flavor. I suppose it would come up in the context of testing. Also in the edbrowse code itself we have had situations where, I don't know, you're writing one DOM method, and you call another DOM method from within that, because it's already been tested and is as good a solution as revisiting the lower level stuff. So based on this information, I think dispatchEvent is good solid functionality and once I get it together, I'll send some code. Kevin