22 параметра в одном вызове?

Как остаться в здравом уме МНЕ?

Сначала нужно в него (здравый ум) придти, а потом уже можно оставаться.

Больше похоже на результат компрессии скриптов.

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

Ты еще binutils/coreutils не видел. ls -la, du -hd1, вот это все.

Может учОные писали, они такое любят. :)

Вот хохма: недавно пришлось попользоваться клиентской js библиотекой sharepoint'а, так там в debug версии все имена переменных заскрамблены, что-то типа «$_15», «$_4» и так далее. Очень весело debugить

как минимум. Это то, что попало в документацию. Да, скорей всего можно указать все одновременно. Или нельзя.

подробности в документации

Человек короткими именами параметров экономил трафик. А может и память на сервере на разворачивание json. Подозреваю что писал это бывший эмбед-разработчик.

А недокументирован потому что в следующей версии его могут просто выкинуть.

Юзать так же как и все остальное юзаешь, 20 параметров не так много чтобы в них путаться. Используй макросы для имен. Ах да, в php же нет макросов, ну что ж, enjoy your aids. Сделай тогда в конце концов функцию, которая приниммает «allow_default» и возвращает «ad».

а в чём проблема собственно? :)

Но ведь жаба и правда многослойная шопипец.

Всё нормально, это же js.

чуваааак.. чувааааак... столь мимо!

wicket жрет столько RAM, как никто более! Там все страницы хранят состояние на сервере, поэтому имеет смысл говорить не просто о странице, а об экземпляре страницы. Один экземпляр страницы, открытый один раз одним пользователем, весит больше мегабайта в RAM (а иногда и все 20, и 40, совершенно не напрягаясь), и пока страницу не «отпустят» и она не соберется GC, она будет продолжать жрать RAM (а в отдельных случаях и CPU). Если сотня человек ломанется пользоваться сайтом на викете, лежащем на обычном железе, случится плохое. Одна контора, у которой сервер онлайн-игры с веб-интерфейсом написан на Викете, ей приходилось из-за этого постоянно покупать самые мощные и дорогие в природе сервера.

дальше, трафик в Викете течет как вода. Это потому, что на все действия фреймворку нужно дернуть сервер, чтобы запустить обработчик на стороне сервера. Потому что на клиенте писать JS там нельзя (за исключением редких и неудобных костылей, описанных в оп посте). Если кто-то хотел бы сэкономить трафик, имело бы смысл подумать вот над этим, а не над размером полей

Используй макросы для имен. Ах да, в php же нет макросов,

апи - на джаваскрипте, какой похапэ? а сервер вообще на джаве, но до сервера все эти имена параметров просто не доходят, на сервере всё другое

Во-первых, там это более-менее обосновано. Ибо замучаешься 100500 раз в шелл вбивать длинные параметры. Это ведь не только для скриптов, но и для конечных юзверей. В случае же кодинга - 2 символа в названии переменной или 20 не так принципиально, потому что один раз написал - и пользуйся (а в нормальных IDE ещё и автокомлит есть). Зато куда важнее потом в этом коде разобраться через некоторое время, чтобы внести изменения. Для шелла write only код - норма.

Во-вторых, у многих утилит есть два варианта имени одного и того же параметра. Если неудобно запоминать короткие имена, можно использовать длинные.

В-третьих, binutils/coreutils пришли из тех времён (и тащат обратную совместимость), когда оперативка была очень дорогая, а процессоры медленные. JavaScript же и так течёт по швам и тормозит на топовом железе, так что десяток-другой байтиков на хранение строки погоды не сделает. Это экономия на спичках.

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

пользуется половина Новосибирска

Успех!

java

В каком состоягнии души был написан этот пост?

В состоянии мрака и безысходности от решения следующей задачи:

1) есть текстовое поле. При его изменении, на сервер шлется оповещение об обновлении.

2) есть кнопка, которая сабмитит форму, где расположено это поле.

Проблема: ты изменил поле и нажал кнопку. Событие об изменении поля отправится одновременно с нажатием кнопки.

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

То есть при обновлении поля, первое нажатие на кнопку просирается. И для отправки форму нужно жать ДВА раза.

Более того, рядом ползет progress bar, и каждое его изменение сопровождается вызовом сервера. При этом в правом верхнем углу на короткий срок загорается идикатор «отправка запроса», такой няшный крутящийся индикатор, как на курсоре загрузки в винде. Но при переключении на себя, этот индикатор тоже на короткое время крадет фокус.

И есть еще факторы того же толка

ИТОГО: кнопка отправки формы может сработать только с четвертого клика по ней!

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

Эм, Ajax отправка спасет отца русской демократии?

var form = document.createElement('form');
var textarea = document.createElement('textarea');
var button = document.createElement('button');

form.appendChild(textarea);
form.appendChild(button);
form.addEventListener('submit', onSubmitFormAction, false);

function onSubmitFormAction(e) {
     var xhr = new XMLHttpRequest(),
         fd  = new FormData(),
         foo = function () {
             if (this.readyState !== 4)
                 return;
             if (this.status === 304) {
                 console.warn(this.statusText);
             } else {
                 // ответ от сервера: this.responseText;
                 // адрес сервера: this.responseURL
                 // очищать textarea и все остальные поля придется вручную textarea.value = '';
                 // либо просто обновить / прыгнуть на какую надо страничку через document.location.href
             }
         }

     fd.append('text', textarea.value);

     xhr.onreadystatechange = foo;
     xhr.open('POST', '/action.php', true);
     xhr.send(fd);
}

у фреймворка свои собственные идеи об аяксе. Втупую послать xhr не получится хотя бы потому, что фреймворк не посчитает это за активность, и через пару минут страница «протухнет» и пересоздастся, а всё что ты там назапускал - соответственно, исчезнет.

кроме того, ты просто не можешь вот просто так пойти и написать на странице вот такой скрипт. При написании страницы кажется, что это XHTML, но на самом деле это не так. Все твои тэги script будут выброшены при рендеринге страницы. Но там есть свои способы таки приклеить его, не в HTML, нужно на сервере отнаследоваться в прямо в джаве от класса страницы, и вклиниться в rendering lifecycle

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

правильный для Wicket способ это всё-таки никогда не писать ничего своими руками на JS. То что генерит Wicket - существует, остальное можно считать - не существует

При его изменении, на сервер шлется оповещение об обновлении.

и что нельзя обработчик убрать? или он критически важен?

Ой, самое главное то забыл:

var form = document.createElement('form');
var textarea = document.createElement('textarea');
var button = document.createElement('button');

form.appendChild(textarea);
form.appendChild(button);
form.addEventListener('submit', onSubmitFormAction, false);

function onSubmitFormAction(e) {
     
     preventDefault(e); //останавливает стандартное поведение браузера
     
     var xhr = new XMLHttpRequest(),
         fd  = new FormData(),
         foo = function () {
             if (this.readyState !== 4)
                 return;
             if (this.status === 304) {
                 console.warn(this.statusText);
             } else {
                 // ответ от сервера: this.responseText;
                 // адрес сервера: this.responseURL
                 // очищать textarea и все остальные поля придется вручную textarea.value = '';
                 // либо просто обновить / прыгнуть на какую надо страничку через document.location.href
             }
         }

     //форму лучше разбирать вот этой штукой во избежании ошибок: https://gist.github.com/bullgare/5336154
     //но если в форме только одна текстарея, то можно как в первом варианте оставть, только 'text' заменить на то что там должно быть
     for (var i = 0, data = serialize(form); i < data.length; i++) {
         fd.append(data[i].name, data[i].value);
     }

     xhr.onreadystatechange = foo;
     xhr.open('POST', '/action.php', true);
     xhr.send(fd);
}

function preventDefault(e) {
     if (e.preventDefault)
         e.preventDefault();
     else
         e.returnValue = false;
}

фрейморк нагенерил на странице дохреллион своего собственного JS кода, и в какой конфликт он вступит с тем, что ты руками

Ни в какой не вступит, в остальном я что то не понял - зачем форма релоадится?

Да, критически важен. Вся логика работает на сервере, на клиенте только гуй. Если на сервер не послать сообщение с информацией об обновлении поля, то коду будет казаться, что оно не изменилось. Т.е. отключить его можно, но это будет равносильно удалению поля с формы.

Ты что ни разу быдлокод не писал?)

Гляди как это устроено. На сервере есть обрабатывающий код, на котором написана вся логика приложения. Там классы на джаве, но это неважно, точно так же можно было бы сделать на любом пхп. Для этого кода никакого веб-приложения нету, он написан так, как будто бы это обычное оффлайновое приложение: есть класс формы, в нем есть поля-элементы управления типа кнопок, и все обработчики событий тоже написаны на сервере. За кадром фреймворк генерит из этого веб-страницу и связывает все элементы на веб-странице с объектами в оперативной памяти сервера. Такой вот прокси получается. Совершенно каждое действие в браузере приводит к репликации состояния в зеркальное отражение формы на сервере. Если ты поменял значение поля - на сервер отправится сообщение «поле поменялось». И только потом серверный код обработчика кнопки сможет увидеть это новое значение. И наоборот, если ты поменял какое-то своейство поля TextField на сервере, сообщение об этом улетает на HTML-клиент. Поэтому форма релоадится постоянно на совершенно любое изменение.

Дибилизм какой то.
А как это в HTML то устроено? Все равно же на полях значит события висят, которые на сервер сообщения посылают.

Ну нет другого пути просто у браузера, у него есть внутренняя дефолтная логика и браузер api для js чтоб гибко всем эти добром управлять.

Как остаться в здравом уме МНЕ?

Выкинуть этот фреймворк.

Это вообще легально?

Я думал хуже pre-mvc аспнета ничего нет. Однако ж...

а я думал что ничего дебильнее ASP.NET WebForms нету. А тут вон оно что...

ха, +1)

На терминале PDP-11 очень туго нажимались кнопки. Поэтому в юниксе команды такие короткие - cp, mv, ls (экономия двух букв!), а в Си - фигурные скобки вместо привычных в те времена begin и end. Ныне это все прекрасно сочетается с очень_длинными_именами_переменных и жабовским заворачиванием класса в класс, чтобы можно было заворачивать в класс когда ты заворачиваешь в класс.

Я понял, что основной посыл поста: «Apache Wicket: нiколи знову!».

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

Одна контора, у которой сервер онлайн-игры с веб-интерфейсом написан на Викете, ей приходилось из-за этого постоянно покупать самые мощные и дорогие в природе сервера.

Playtox?

NDA не одобрит указания таких точних сведений :)

так тебе ж поди нужно викетом генерить только статические страницы. Типа вместо шаблонизатора. Такое использование в общемто норм. (зачем использовать аякс вебфреймворк для генерации жс как no-js статический шаблонизатор - опустим для ясности).

Но вот ты попробуй поюзать его именно так, как он задумывался, во всей полноте динамического интерфейса, вот здесь он раскроет все глубины [дичайшего ада]