From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by hurricane.the-brannons.com (Postfix) with ESMTP id C94C67862B for ; Mon, 10 Mar 2014 05:28:36 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id bnsj1n0080bG4ec5BoTJfw; Mon, 10 Mar 2014 12:27:18 +0000 Received: from eklhad ([107.5.36.150]) by omta03.westchester.pa.mail.comcast.net with comcast id boTJ1n00N3EMmQj3PoTJxX; Mon, 10 Mar 2014 12:27:18 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Mon, 10 Mar 2014 08:27:19 -0400 Message-ID: <20140210082719.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394454438; bh=sihnH/ef7SyN/JJFIYQgfjtcIG4F6JMs2u9qlZezExI=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=H1iWXBfOjnaaUBYzaaAGNe0KQz1fKdvoYNteDzSYQQp9JwBZ498zaRHT6NHosMHjq vGVG6iAGOlQATch8O3LdyPl8mST9+5GFXiUwXMWuAaA1dhI/LHIl39O6MkwlVCem/2 HOWmlNlzF7D2bklBS6MhNRggkHpJRbGUrg/DTN4AEpZCil1Xne6dWgo+c1x5RTCnMH lPrb9lep245NboveIYmHlzIorBlsG/GwDOke/yhMxmv/+FcLh7n3DL/KmX8tuEQjW4 ctNIbOcj/3QBirINd08/EolsvI7+0AZbZnHdSVh8mKgNTDGOKQvob4TqDYArnPe0x4 gNFgW9xy8TN3Q== Subject: [Edbrowse-dev] Setters and Post Scan X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 12:28:37 -0000 A setter is a function that is called when a variable is set, to perform some sort of side effect. Setters will always be needed. Example is the URL class. If an object o is URL, and you set o = "http://foobar.com:1234/whatever.html" that has the side effect of setting o.protocol = "http" o.port = 1234 o.host = "foobar.com" o.data = "whatever.html" And setting document.cookies to a string puts a cookie in your cookie jar. Did you know that? http can set cookies for you in the header, in the usual way, but js can also look at and set your cookies. All this is implemented now, because lots of websites use it. Like any spare time project, I've been driven somewhat by expediency, what do I need to do to access my favorite sites? It's not a great way to program but there it is. Another setter that isn't implemented, and maybe should be, is the selectedIndex in a pick-one select list. This is a dropdown menu where you pick one item. In js there is an array called options[], an array of Option objects. options[0] is the first option, option[1] is the second, and so on. So when you pick an option in edbrowse I do two things: field.selectedIndex = 3 field.options[3].checked = true But if for some reason javascript did one, I should do the other as a side efect. If it set field.options[4].checked = true then I should set field.options[3].checked = false field.selectedIndex = 4 Or if instead js set field.selectedIndex = 4 then I have to update the checked fields. I guess this is uncommon, because I haven't run into it, and thus haven't implemented it. The interesting thing here is this cannot be done by a post scan. I can't scan the tree of objects after the fact and figure it out. I see that selectedIndex and options.checked are inconsistent, but I don't know which one is right. Thus setters will always be needed. But should they be used to update the edbrowse buffer? That's an interesting question. I do this only once, so far, look for javaSetsTagVar in jsloc.cpp. This is for standard text fields. Perhaps you entered $35, and js cleans it up to $35.00 to include the cents. The modified string has to be reflected back in your text buffer. This is done now with the value setter, and it works. In the last line of jsrt, the calc button to calculate the size of your text buffer, it sets a field value in javascript, and that is pushed back to the edbrowse buffer. Add some text to buffer 2, switch back to buffer 1, and push again. But should we be doing most of this work with setters, or with a post scan? The fact that js could completely rearrange the page, new paragraphs new links new tables etc, makes it likely that we will move away from setters and towards a post scan for these things. Step through the input fields, and aha, price.value is now "$35.00" It use to be "$35", so change it in the buffer and notify the user. Setters could in theory update line 27 5 times, giving you 5 messages "line 27 has been updated", whereas a post scan would see that line 27 was different and print that message once. All this is coming to the fore as I think about rebuilding an option list that was changed by javascript. You live in Michigan; here are the doctors you can pick from in your state. It happens all the time. Doing this by setters would be a nightmare. Very intrusive code, which we are all trying to avoid. And it would almost certainly have bugs, or be hard to maintain. The post scan however steps through the option tags that I have, and the js options in field.options[], and compares them. If they are different I rebuild the tags and notify the user that the menu has changed. I'm not at the stage of writing any code yet, still designing, still thinking out loud. And If I post these thoughts then you can comment and we can all move forward together. Yes, Jean from debian got back to us and I think he's going to checkout our latest and try to build it and see if he can determine the problem on his end. It's a puzzle. Karl Dahlke