Re: [Edbrowse-dev] Render

[Adam Thompson <arthompson1990@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]

On Fri, Feb 28, 2014 at 11:43:09AM -0500, Karl Dahlke wrote:
> 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.

Yeah, I can see how this'd work.

> 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.

Hmmm, I wonder if we want to try and keep it away from javascript specifics, i.e.
develop a generic DOM structure which we can then plug into with js or whatever.

[snip]
> 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?

How'd this work with forms, event handlers and all the associated machinary?

> 
> 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.

Hmmm, I can see the thought process here,
and I was thinking along the same lines a couple of days ago.
However, the more I think about it the more I think it's potentially not the
best direction for edbrowse since it places a lot of dependancy on something
beyond our control, i.e. the stability or otherwise of a js library.
I also wonder if this'd work in terms of browsing a web page without js, or one which defines its own render function.
Before you ask, I'm fairly sure with the increasing amount of js-driven
gui-style webpages, I could find at least a few
pages with a render() call already.

The kind of model I propose is one inwhich html parsing becomes the creation of
these generic objects, which are also created by javascript (but not stored in
the js universe apart from via wrappers),
and then rendered using a render function called when the tree is updated
(using an update function etc).

I'm fairly sure this'd be possible, and probably simplify things.
In addition there'd be no more rooting required in this system than in the existing
one (object properties go into a list, or hash map,
and are heap rooted on creation etc).
As I said, this needs more thought, but would also mean the failure case becomes
a function which goes through the tree destroying all the js data and then
destroys the context.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]