Как запустить 2 и более аякса, чтоб второй запустился когда ВЫПОЛНЕНИЕ первого завершится и т.д.
?

можно конечно запускать при выполнении:
if (req.readyState == 4){                
   if(req.status==200){  

Но такой вариант не хочу использовать, т.к. кол-во запусков аяксов заранее не известно, хочется сделать более универсальное, отправить массив параметров и получить последовательное выполнение аяксов.

на чистом javascript?

(2) Да скрипт в файле ajax_tooltip.js
есть скрипты которые прописаны в PHP и меняются, но аяксовый скрипт хочу чтоб был на чистом javascript

а по порядку запустить разве не прокатит? или они асинхронно вызываются?

(4) второй добавляет данные в форму которую вернул первый аякс. Бывает так что первый затормозил, а второй уже выполнил и вернуть (вставить) данные ему некуда.

в общем случае как-то так:

req.onreadystatechange = function() {
if(req.readyState == 4) {
  /** тут новый запрос **/
}}

(6) да так умею, и так работает.
Хотелось сделать более универсально.

х.з. наверно попробую сделать скрытый атрибут который будет заполнятся первым аяксом, и чтоб второй аякс его проверял, если этот атрибут заполнен то значит первый аякс уже отработал и можно запускать второй, и т.д.

(7) что мешает стандартный ajax-вызов завернуть в функцию и в callback'е вызывать ее рекурсивно? Если хочется массив с параметрами, то вобщем тоже решений больше чем одно. Прямо в лоб - передаешь в функцию массив с параметрами вызовов и индекс, по условию выполнения в callback'е заново вызываешь ту же функцию с новым значением индекса.

Что-то типа:

function ajax_chaining(params, step) {

    req = $.ajax(params[step]); //псевдокод, создаешь объект XmlHttpRequest любым удобным способом.
    
    req.onreadystatechange = function () {
        if (req.readyState == 4) {
            
            /* действия с результатом запроса */

            if (step+1 < params.length && some_statement) {
                ajax_chaining(params, step+1);    
            }
        }
    }
}


То есть задача решаема, но мне кажется это плохое решение. Раз уж сервер знает как отрабатывать эту цепочку вызовов, может ему сразу все параметры и отгрузить? Оправданным решение на клиенте может быть только в случае очень длинной цепочки с большим количеством данных.

(8) На самом деле, цепочка вызовов нужна только тогда, когда новые данные для передачи на сервер появляются в процессе обмена с сервером - то есть "зверь" что-то "мышнул" на форме - запрос полетел на сервер, а "зверь" продолжает "мышковать", и новые запросы собираются в буфер, чтобы быть отправленными на сервер сразу после окончания обработки предыдущего запроса.

Ну, ещё полезно почитать про Web-Socket и как оно должно работать, чтобы иметь двунаправленный канал.

Создать объект, на каждый вызов. В нем одна из переменных хранит нужный колбэк, другая переменная содержит указатель на следующий объект. В этом объекте метод, работающий по схеме (6) по завершению метода вызывается похожий метод из следующего объекта.

Объекты инициализируем в массив

(9) ну для описанной ситуации цепочки ajax-запросов имхо плохой выбор. WebSocket да, ну или что-то из костылей типа socket.io. ajax'ом очень накладно

Как вариант - задействовать jQuery с его аяксом, у него уже есть готовые callback'и для успешного, неуспешного и любого завершения запроса...

А повторное использование объекта xmlhttprequest, насколько я помню, никто не отменял - и в случае keep-alive запрос в том же канале пойдёт.

(13)  long-polling/comet же, это туда же, в раздел костылей к socket.io.

(7) рекурсивный вызов универсальнее и логичнее в этом случае.
Если форма добавляется в DOM можно отследить это событие через DOM MutationObserver.

вот статья на тему http://habrahabr.ru/post/202366/

Да, позже размышляя пришел к выводу, что рекурсией будет правильнее.

(7)>>Раз уж сервер знает как отрабатывать эту цепочку вызовов, может ему сразу все параметры и отгрузить?

Надо попробовать и так, вроде должно не сложно получится. Передать параметры и ID куда это должно будет вставлено. Сервер обработает, вернет, я останется только подставлять данные.

Картинка реализации проясняется.

(16) если логика немного сложнее, чем 200 строк кода и три функции, то, возможно, имеет смысл подумать о Pub/Sub.

Рекурсия прекрасно отрабатывает, все что хотел получил.

Всем спасибо.

(16) Если в ответ сервера включать информацию о том, что с ответом нужно сделать, то можно смело отправлять пакет запросов, если нет, то придётся писать парсер ответа, который разнесёт части ответа в вызывающие функции.
В принципе, написать не сложно, но делить один ответ на несколько - непросто.