From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) by hurricane.the-brannons.com (Postfix) with ESMTPS id E5CE378F0E for ; Tue, 13 Jan 2015 04:36:16 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-03v.sys.comcast.net with comcast id fQZP1p0054ueUHc01QZg1p; Tue, 13 Jan 2015 12:33:40 +0000 Received: from eklhad ([IPv6:2601:4:5380:4ee:219:21ff:feb9:ba8d]) by resomta-po-03v.sys.comcast.net with comcast id fQZf1p00E08MP5701QZg6W; Tue, 13 Jan 2015 12:33:40 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.2 Date: Tue, 13 Jan 2015 07:33:39 -0500 Message-ID: <20150013073339.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=q20140121; t=1421152420; bh=RDp/0HyD1PnZBo4l7CfsupR3EVhtsVSdR5rWb2CFwtY=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=aRwkOyXjbQTjmWn2BPJqj4Il4d8/7tLXHUZuRDdr1P6TPf87YtMhkZWo4+ZmRtZwz CaZP4DN3kIC9TfzE0U51+UKryD5FXiDShvZBJ/fnZQCQYqXeWOAzoZR/n5A12c0OqA y4GHwKHh/mB5iPO+w0PZpEQy05Y4+yed9U4q26E/Whx8cVkyO4H1wInUhpTlupyPNB sQkBq/X289XXtcK0vJf5vxs9zfmQLMkN5g8ZfA0n0LgclLb670G+e68BsAChHvbEI3 twRp216ykCzlnjv340HDBUFtQoS7xEsSseGuZmj26vDfPbXZM2Y5Z5sr//Aa+bEmJK +98UFa8tlhSyw== Subject: [Edbrowse-dev] $kids$ X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 12:36:17 -0000 As you know, an html tag like
generates a corresponding object in the js world, but for the most part, these were disconnected and isolated objects. In reality, the tags between and
, and not between other nested tags, are the children of
, and their objects should be children of the form object. I've taken a step towards this. Many html tags, not all of them, maybe should be all of them, or maybe not, like
which has no closing
, anyways, many of the tags now generate a js object and an array beneath called $kids$. This array holds the objects for the tags between and . Finally we begin to build the js tree corresponding to the html. And functions like appendchild and insertBefore make sense, since there is a tree for them to work within. There was a choice in implementing appendChild. I could write the function once and then add it to every node object created, write it natively in C as a method to each of the dozen classes of html tags, or make it a prototype for each of the html tag classes. The first seems error prone, trying to remember to add that function to each instantiated object after the fact, and the second is truly ugly because it lives in the js world, which will depend on the js library we are using, or even the version of that library. I'm trying to keep jseng.cpp as small as possible. It shouldn't have dom stuff in it. So I chose the third, prototypes in startwindow.js. And it's realy easy! form.prototype.appendChild just pushes its object onto this.$kids$. It's maybe one or two lines of code. Now I'm hoping more websites will work, sort of. That is, they won't error out. But if js really starts creating new html objects, new tables and paragraphs and anchors and sections, we won't see them because the modified js tree is not rerendered. This is something I probably can't do in increments. "Gee, we added a button to the form, let's see where I need to paste that into the existing edbrowse buffer." I'm already doing too much of that. No - this will have to wait until we, as a matter of course, rerender the tree after each js operation and compare the new text buffer with the old to see what has changed. But anyways, $kids$ is a start. Karl Dahlke