[Edbrowse-dev] Render

[Karl Dahlke <eklhad@comcast.net>]

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