On Fri, Feb 28, 2014 at 03:01:35PM -0500, Karl Dahlke wrote:
> > Hmmm, I wonder if we want to try and keep it away from javascript specifics,
> 
> I don't think you can, really, we always have to support javascript,
> in whatever its form and syntax and semantics, we're always in there,
> in the heart of it,
> so why not write render in the language that we know we have to support,
> stepping through all the objects that we know we have to have
> corresponding tags for.
> I don't see the advantage of transmuting all this to another tree in another
> home-grown language and then transmuting it back as necessary
> to work with javascript.

I wasn't thinking in terms of a home-grown language exactly,
more an expanded concept of our existing html tags.

> Also the tree is mostly made for us already.
> The form object contains an element array.
> This array holds the input tags.
> Each input tag has a value and checked field and default,
> and if it is a select, it has an array of options,
> and each option has a checked field and value, and so on,
> all that tree structure is there in javascript,
> and has to be there or we aren't doing our job,
> so render can just trace it as a javascript function.
> The only thing we need to add is a text object.
> If there is nothing on the web page but hello world,
> no tags, no nothing,
> we would have to invent a <P> paragraph tag or some such
> to hold the text.

We're basically going to have to parse the page,
wrap things in new tags then hope they don't break the existing html if any.

> So yes some tweaking on our part,
> but I do think much of the tree is already built in js and has to be so
> and will always be so, so why not live in that world
> when translating the tree back into a text buffer to browse.

Primarily because I know of no way of protecting this js render function from
being zapped by an unfortunately crafted page.
At the moment if js does stupid things and breaks the js dom that's not nice 
if it completely destroys our method for rendering the buffer that's
not only difficult to debug but also means you end up with an empty page.

> > How'd this work with forms, event handlers and all the associated machinery?
> 
> I mentioned that forms already build a fairly substantial tree
> of javascript objects for us.
> It's all in place today.
> And so do tables, with rows under tables and elements under rows,
> and so on.
> I think I implemented tables rows and cells as a js tree.
> I was supppose to.
> Anyways, an event handler is a function under a tag,
> which becomes a js function under the corresponding object for that tag.
> Just another leaf on the tree.
> Nothing special here, just another member of that object.
> And I already do this today for onsubmit onreset onchange onclick.
> So again the js tree is already there.
> We have to traverse it, and it's easier to traverse in js itself
> then in any other outside language such as C.

I agree that this is the easiest option,
but I'm still unsure how robust this'll be and also how this plugs into the
existing machinary. For example how will the i and g commands work?

> > it places a lot of dependancy on something
> > beyond our control, i.e. the stability or otherwise of a js library.
> 
> Well I'd be writing render() in javascript itself, not dependent on any library.
> As long as there is a call to
> executeJavascriptCode(const char *code)
> then we're ok.
> 
> The language of js, i mean for loops and if statements etc, isn't going to change.
> The objects in the js tree might change, but probably expand in a backward compatible way,
> and guess what, we have to support all those changes anyways.
> From html to objects and the semantics of those objects,
> from start to end.
> And render would have to support the new objects and tags,  whatever language it is written in.
> So it would be easiest if it was written in js where the tree lives.
> I'm thinking so anyways.

I guess I'm not saying that theoretically this isn't a nice idea,
but I'm really worried how reliable this'll be and how it'll cope with the
insanity that one sees on the web. In addition,
what happens to our ability to render the buffer when js blows up
mid-execution, before we can render things and the context goes away?

Also, how are you going to make this function called every time js does anything?

Cheers,
Adam.