Re: [Edbrowse-dev] $ object in javascript

[Kevin Carhart <kevin@carhart.net>]

Hi all

I have time to work on it this week.  I'd love to have one or more 
threads onlist or offlist or even hop on an IM client, to figure it out. 
Any working-method is ok with me.  What I have usually observed is that 
jquery is a wrapper around 
various integral DOM manipulations which would live either in startwindow 
or jseng-moz.cpp.  A lot of these, we have.  Maybe some others, we don't 
have.  Any missing method makes behaviors fail.  Jquery code is fairly 
readable when you are in a version that is not minified.  You will have 
various methods defined in a jquery.js file, so you're sitting there 
reviewing the JS code, and the $ object has various calls available with 
fancy seeming names invented by the jquery authors, but the code that 
constitutes that call simply wants to do open DOM things: insertBefore, 
appendChild, the usual. I think we have most of what it wants and I think 
we are fairly far along.

A related question is AJAX.  jquery and AJAX are two different things, but 
jquery has the keywords 'get' and 'post'.  jquery provides developers with 
the ability to retrieve things inline with minimal work for them.  Ha - 
this just means that the burden has been moved around to us, the people 
responsible for the browser's XMLHttpRequest.  So this is a second kind of 
thing.  Some of the failed sites we are seeing relate to pages that want 
to call $.get or $.post.

This happened in the radio caroline page.  The $ object has a set of 
functions (call them functions, methods, calls.. it may not be appropriate 
to use OO terminology for javascript, but since what I've been exposed to 
is a mess of both, I sometimes say 'methods' - sorry about this!), and 
this set of functions includes get and post.  The JS code that constitutes
$.get and $.post, itself wants to take advantage of an XMLHttpRequest 
implementation which the browser is responsible for.  We have code for 
this in startwindow.  It is not truly asynchronous, but there are a ton of 
pages which are using an inline HTTP request but don't take advantage of 
asynchronous timing.  Their pages don't require it- they might just have 
something like a list of days, or an enumeration of items that the 
web visitor can click on, and for each one that you click on, it plops the 
results into one iframe.  So it's a little bit of an extraneous use of 
AJAX, but I think it occurs a lot.

So at the risk of being a little repetitive, I'll lay this out again: what 
kind of problem are we facing when site behaviors don't work?  Of four 
possibilties (jquery wants DOM, jquery wants XHR, non jquery issue 
involving DOM, non jquery issue involving XHR) I think it is some of each 
of all four:

(1) jquery calls that want DOM calls.  DOM calls not implemented.  Note 
that this could include all kinds of CSS!  I have worked on things like 
"getComputedStyle".  It expects style stuff to be available and this could 
be a blocker.  A missing method is a missing method, even when edbrowse is 
ultimately going to not care and throw it out.

(2) jquery wants get or post.  Get/post wants our XMLHttpRequest. 
Something goes wrong along the way and the DOM tags to be retrieved 
inline do not 
make it back through all the hops from javascript back to edbrowse proper 
where a non-developer user could enjoy it.  It's possible that the ajax 
works great and the resulting DOM changes actually do happen but don't 
make it out of javascript.  The chokepoint could be early or late, but a 
chokepoint 
anywhere would mean that edbrowse users wouldn't get the benefit YET.
Some kinds of chokepoints might be easy for us to fix and some might be 
difficult, and it might be hard to differentiate the cause of the problem. 
I think we can do it though - the good news is that this has actually 
succeeded sometimes!  Something magically changes in place, in edbrowse.
Maybe you are clicking on different days in the pirate radio schedule, and 
the 'results' iframe is properly receiving a new piece of text.
(And that is when we would present the user with a notification that something 
changed on certain line numbers.)
It's not out of reach that we could get this going.  It just means that 
several gears need to work together and none can fail:
edbrowse, to third party page code, to page code's jquery code, to page 
code's jquery's GET/POST, to startwindow's XHR, to our native XHR in 
jseng-moz, leap off to the internet via curl, to native XHR, back 
to startwindow XHR, back to page code's jquery, back to page code.  The 
page code now has some tags and some instructions.  The instructions run 
on the tags, and the tree changes, as represented in javascript.  Perhaps 
a target iframe just 
changed its innerHTML.  Now the edbrowse side-effects process brings it 
back to edbrowse proper, and the edbrowse rendering of the target iframe 
suddenly has new information.  The notification fires.  There are a lot 
of hops but potentially very groundbreaking, and we are partway there 
already.

(3) Some page that doesn't use jquery could use a piece of DOM 
manipulation, also unrelated to ajax, that we haven't implemented yet. 
This is a third option.  Behavior fails.

(4) Some page that doesn't use jquery could instantiate XMLHttpRequest 
directly in a handmade JS function.  Something goes wrong along the way 
maybe, and behavior fails.

I think there is a lot of fertile territory and I'm optimistic.  How do 
you think we ought to work?

Kevin