> 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 _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
