From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 9D4A578B9D for ; Thu, 13 Aug 2015 20:34:20 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-06v.sys.comcast.net with comcast id 4Tdu1r0012EPM3101Tdu18; Fri, 14 Aug 2015 03:37:54 +0000 Received: from eklhad ([IPv6:2601:405:4002:b0a:21e:4fff:fec2:a0f1]) by resomta-ch2-07v.sys.comcast.net with comcast id 4Tdu1r00B0GArqr01Tdugp; Fri, 14 Aug 2015 03:37:54 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20150813200725.GE993@toaster.adamthompson.me.uk> User-Agent: edbrowse/3.5.4.1+ Date: Thu, 13 Aug 2015 23:37:54 -0400 Message-ID: <20150713233754.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=1439523474; bh=TqWLWY51SdMgtJwpJxMlBFrdK+FESzJ7r9G5H2xwM1Q=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=VuuHJNBD1aaabWNDrZlK6Zf0uMkTO1tn+59MlpH9orXINKyQiAXOhD99GcvcDqoY+ hRqYsy5+f9QkeJ7+Wk7tAPyPPi3medwVDeBED6S+ZgHvOYu9QUc/MIJhQjqkw9qIdZ KxXHIzO0skPQCaasb+qcoOrdU4QYp8Nyx4LUcSYGmev8vhTYEpR6Ph4OkToATMe51o RiOO7t6/BjQq8h0t4aM796ys9BGfGqbKPj9o1uGpMyQ0DyunBIuvgJlsyixet28cfm tUlVzSmdLOTTSxzUW/TGzFlzsqap+HKBksek6IvZUqv3izYY7bgx4QFwYBq+bJqtVy RxtDikuGVXExA== Subject: [Edbrowse-dev] tidy5 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: Fri, 14 Aug 2015 03:34:20 -0000 > In terms of an architecture I'm thinking of aiming to have the DOM as an > abstraction which can be used by both the rendering code and the js. Thus: > html is parsed into a node tree which is converted to our DOM objects > These objects are exposed to js via wrapper objects in the js world such that > any changes js makes are automatically passed through to the DOM > The renderer renders the DOM automatically on page load, > with support for re-rendering on a user command (with some sort of > notifications for js induced changes) > Form fields are altered in the DOM, which may or may not trigger a re-rendering Yes this can cause a rerender, example onchange or onselect code, as exercised by the regression tests in jsrt. > Any re-rendering would be partial, i.e. > only the changed segments of the DOM are re-rendered This sounds like a diff between the old dom and the new, but it's easier to just rerender and then diff the old buffer against the new, and then report the lines that have changed, which is how edbrowse works today. Realize that a small change in dom could change the buffer on down the page, even into dom elements that have not changed. So I think you always want to just call render() and then diff the two buffers. Maybe even a diff library we can use, if not /bin/diff itself. These are minor points; and you are definitely on track. This is where we need to be. Karl Dahlke