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