From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by hurricane.the-brannons.com (Postfix) with ESMTP id 4986C78311 for ; Fri, 28 Feb 2014 08:44:13 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id XoRR1n0050SCNGk59sj9Ao; Fri, 28 Feb 2014 16:43:09 +0000 Received: from eklhad ([107.5.36.150]) by omta09.westchester.pa.mail.comcast.net with comcast id Xsj81n00W3EMmQj3Vsj8Mc; Fri, 28 Feb 2014 16:43:09 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Fri, 28 Feb 2014 11:43:09 -0500 Message-ID: <20140128114309.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=1393605789; bh=S7z+FA4SvbOX59EyWSMee2YLAD5gi6N6FE53Qm06Mqg=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=tsFoLBWCYa9k1aVhXcvuzhT83j/VB+FOGHxPpt2IoCbUdd5VUGEpx1DVdOgBt2g+3 kZG2Mvj7aC12D2hTciUTHebdyKcDPPlMG+L9070rBPEiYrHC9h8g04XOcYAtRixWef gz4VFPSBOdoZNnhz/alBObz98nbdoq4dDMSD0EGd/SWX2B8nGMOrImHz4zcuUJWxo3 rDBPEjtGoi+oXajtSND+SIvr3cP9O9nGQ22CjPMnVOdbalfYF0Nnewxr92Cd4pBLKr UXLE3Vl4KjMK8PsOIl2Cf2q84dhv2ScfCcyj93Ywx17q5N6d50Cq6tdsTmhqgmoDCm 7eKQDIPfVfgyQ== Subject: [Edbrowse-dev] Render 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: Fri, 28 Feb 2014 16:44:13 -0000 Well this is thinking ahead to future versions of edbrowse, with some of the anticipated redesign. I'm thinking out lout if you will. We want to build a tree of javascript objects, first built from html, then perhaps modified by javascript functions, or even onclick or onchange code as you interact with the web page. Then a render function traverses this tree and builds the text buffer that you read. This render function is called after every javascript invokation, because you never know what javascript might do. Add new paragraphs, tables, build new option lists, etc. This is where we are headed, and I was almost tempted to start writing render.cpp, which would not interfere at all with anything going on now, just a separate file with a function not currently called, but intended for use in the future. I was going to copy html.cpp to render.cpp, and create the same text buffer, but not from html tags, rather from the tree of javascript objects. So I would step through the members of each object, and if it's a text object paste the string into the growing buffer, and for some other object like a form descend into that object and do the same thing recursively, generating tags and/or text as we go. So I start to picture thousands of lines of C++ code stepping through object members, and rooting object pointers and rooting strings etc, and then it hits me. A great idea! Write render() as a javascript function, not in C. Then just execute render() entirely in javascript. Use document.write to crank out the text buffer, and postprocess it at the end to break up long lines just like we do today. No rooted object pointers, no rooted strings, it just runs. And it runs the same way even if we switch to another js engine some day. Completely portable. So render.cpp is mostly a long string that is the render() function in javascript, and I just pass it to the js engine for execution, then the resulting document.write string is the text buffer. Pretty slick, eh? As time permits I may start to outline this javascript render function. This requires some conventions about the object tree, paragraph objects, text objects, etc; any enhancements we need to make to dom, but all this has to be settled no matter how we do it. Render() will be a nontrivial, recursive javascript function, but much cleaner and easier than the C counterpart would be. Karl Dahlke