Продолжая вчерашнюю напыщенную речь , этот выпуск должен (надеюсь) стать немного более сочным, если я смогу разобраться, куда он идет.
Во-первых, уже есть хорошие отзывы о последней части (спасибо!), В большинстве случаев это Алан ;
Я могу сказать вам, что, работая с SOAP, различными уровнями RPC и простыми синтаксическими анализами GET / POST / XML, в большинстве случаев RPC имеет тенденцию отнимать много времени. Это замечательно для первых 3 тестовых вызовов, но по мере роста проекта это точка, где она не работает, как ожидалось. Затем вы вводите один из худших кошмаров в аду для отладки.
Когда приходит javascript (особенно если вы рискуете жизнью и здоровьем, пытаясь заставить работать реализацию MS), гораздо легче придерживаться основ .. KISS / POST / GET / strings и XML по мере необходимости …
Также интересен аналогичный, но альтернативный подход Данна Лундквиста к тому, что Javascript Serializer делает с атрибутами script src; манипулирование атрибутом с использованием DOM, который он описывает здесь .
Что случилось с Javascript
Возвращаясь к мысли прошлого времени: «Сейчас 2004 год. Кто-то, должно быть, уже решил это раз и навсегда» (проблема в том, как перенести свежие данные с сервера на страницу, которая уже загружена), подумайте Стоит попытаться понять (догадаться), почему «вещи» не продвинулись дальше.
Подумайте, что отправной точкой здесь является вопрос «что случилось с Javascript?», Что действительно является загадкой.
Если вы действительно внимательно посмотрите на спецификацию ECMAScript (короче говоря, ECMAScript == Javascript) и сделаете серьезный анализ с достойной реализацией, такой как Mozilla, вы можете сделать потрясающий вывод — как динамический язык, дизайн превосходен.
Хотя Javascript, как правило, применяется только для очень специфической цели сценариев браузера (так что есть масса проблем, которые его дизайн никогда не должен был включать), вы могли бы разумно спросить, почему Perl или PHP не созданы так чисто. Попробуйте это в PHP, например;
try { eval( someJsInThisVar ); } catch ( e ) { alert ( "Syntax error "+e+" in "+someJsInThisVar); }
… или, как я уже говорил, добавление новой функциональности к фундаментальным объектам, таким как;
String.prototype.toPHP=function() { var s = this; return 's:'+s.length+':"'+s+'";'; };
Поэтому, если мы говорим, что Javascript на самом деле довольно хороший язык программирования, почему бы не использовать его более широко. Сегодня кажется, что он все еще вынужден добавлять случайные простые уловки на веб-страницу, хотя члены комитета W3 называют его худшим изобретением (хороший ответ на это здесь, кстати).
Дуглас Крокфорд в значительной степени подводит итог этого на «Самом непонятом в мире языке программирования» . Я бы также добавил, что синтаксический анализ XML упоминает причины, о которых упоминает Дуглас — DOM часто не самый простой способ сделать что-то — Javascript нужен собственный синтаксический анализатор SAX (хотя вы можете найти здесь чистую реализацию Javascript), парсер pull и что-то вроде Simple XML IMO.
В конечном счете, освоение Javascript сводится к здравому смыслу для разработчиков — в прошлом было слишком легко тратить бесчисленные часы на написание и отладку Javascript во многих браузерах. Часы, которых можно было бы избежать, перенеся больше на сторону сервера, где у вас есть среда, которой вы могли бы доверять. Лишь немногие были достаточно жирными (или безумными), чтобы выполнять тяжелую загрузку с помощью Javascript.
Я говорю в прошлом, потому что я думаю, что Mozilla изменила это — у нас теперь есть реализация, которой мы можем доверять, плюс такие инструменты, как Venkman, чтобы помочь (примечание: в настоящее время я считаю, что модульное тестирование избавляет от необходимости отладки — кажется, jsunit быть о лучший выбор для Javascript).
Сегодня, если вы сначала напишете для Mozilla, последние реализации Microsoft JScript окажутся достаточно близкими, и для правильной работы потребуется лишь небольшая настройка. Там случайные ааааааааа! как это;
Foo.prototype = { x: 1, y: 2, }
IE (в прошлый раз, когда я смотрел) не любил эту вторую запятую (должен был получить, если у меня с груди).
Подключение сервера и клиента
Мой фундаментальный взгляд на клиентскую сторону всегда был «я предпочитаю эту серверную сторону». Отчасти моя мотивация сводится к тому, что делает Дуглас Крокфорд; историческое недоверие к Javascript. Но это начало меняться на Мозиллу.
Но есть еще один, более важный момент, который заключается в том, чтобы делать действительно интересные вещи с Javascript, что я не видел в деталях.
Если я создаю динамическое приложение, которое в первую очередь относится к серверной части, это уже достаточно сложная задача — добавление еще одного уровня логики в Javascript на стороне клиента требует кошмаров (как указывает Алан).
Большая проблема IMO — возможность взлома — если я внесу изменения на стороне сервера, слишком легко случайно сломать сторону клиента. Это потому, что я, как правило, буду развивать их более или менее независимо.
Хотя очевидно, что между ними существует определенная связь, встроенного соединения нет, поэтому изменения на стороне сервера не обязательно будут отражены на стороне клиента.
ломкость
Возвращаясь к более ранним пунктам, оценивая различные методы получения дополнительной информации со стороны сервера, не перезагружая всю страницу, подумайте, что ключевым моментом в оценке их относительной заслуги является возможность взлома (чтобы еще больше злоупотреблять английским языком). Если вы вносите изменения здесь , каковы шансы, что вы что-то там сломали?
Принимая кадры GMails + интенсивный подход Javascript к задаче (в одночасье у меня есть аккаунт — большое спасибо за предложения!), Я считаю его очень ломким. Это может не быть проблемой для Google, у которого есть персонал, чтобы сделать это правильно, но большая часть отношений между элементами на стороне сервера, с точки зрения пользователя, глубоко укоренилась на стороне клиента. Возможно, наивный вопрос, но как скажется, например, изменение имени GET-переменной на стороне сервера?
Подобные мысли приходят мне в голову, когда я думаю о Livesearch . Насколько легко было бы создать и управлять сложным приложением на основе того же подхода? Это не значит, что это невозможно, но я предполагаю, что Кристиан обслуживает клиента отдельно от сервера . И сервер использует классы CSS, которые определены здесь . С одной стороны, Livesearch является воплощением KISS . С другой стороны, действительно ли зависимости между различными независимыми объектами (Javascript, CSS и PHP) действительно присущи сложности?
Итак, я думаю, что вопрос сводится к тому, как получить изменения на стороне сервера, чтобы распространять чисто на стороне клиента?
Урок от SOAP
Думаю, у SOAP есть одна (но не более) функция выкупа. И на самом деле это определяется не самим SOAP, а WSDL . WSDL означает, что доступ к такой службе, как служба WhoIsGoingToBePresident Дитриха Аяла, с помощью PEAR :: SOAP можно сократить до всего лишь одного ;
getProxy(); getProxy();
$ Prediction = $ Predictor-> whoisgoingtobepresident ();
echo ‘Kerry:’. $ Prediction-> kerry. ‘
«;
echo ‘Bush:’. $ Prediction-> bush. ‘
«;
WSDL обеспечивает точное определение сервиса до точки, где клиенты для сервиса могут быть сгенерированы и использованы, просто зная URL-адрес документа WSDL. Вам не нужно заботиться о базовой сети или о кодировке данных, необходимой для ее передачи по сети.
Что касается вчерашних разглагольствований, то о механизме и полезной нагрузке позаботились без необходимости думать о них. Все, что осталось, это популяция — отображение данных в визуально привлекательной форме. Если там изменится удаленный сервис, конечно, он сломает ваш пользовательский интерфейс, но вам нужно будет только подумать о том, чтобы сделать правильный вызов RPC и настроить способ отображения результата.
На мой взгляд, соединение серверной и клиентской сторон веб-приложения должно быть таким простым. В то же время, есть только реализация SOAP Mozilla , и в прошлый раз, когда я попробовал, это не было приятным опытом. Также SOAP в основном означает «раздувание», IMO — слишком сложная задача для этой проблемы. Мы не заинтересованы в том, чтобы предоставить всему миру доступ к веб-сервису — мы заинтересованы только в том, чтобы Javascript говорил на стороне сервера для одного приложения.
Поколение Javascript
Другой способ, как я вижу, состоит в том, чтобы исключить посредника (WSDL) и заставить серверную часть генерировать Javascript, настроенный для обратной связи с сервером, оставляя только население, о котором нужно думать (где мы, вероятно, хотим некоторого уровня человеческое изобретение ради красивого дизайна).
В целом, генерация Javascript, который отражает что-то происходящее на стороне сервера, может быть хорошо выполнена.
Например, PEAR :: HTML_QuickForm отлично работает, когда дело доходит до проверки. Если вы укажете правило проверки формы на стороне сервера, например, регулярное выражение, требующее буквенно-цифровых символов, QuickForm также может встроить то же правило, что и Javascript, в выходной HTML, сохраняя пользователю перезагрузку страницы, прежде чем обнаруживать, что они допустили ошибку. Вам, разработчику, не нужно думать о Javascript — он генерируется автоматически. Измените регулярное выражение в PHP и Javascript, чтобы отразить его.
Мы использовали аналогичную технику в (обязательный плагин) WACT с
Затем в PHP вы можете загрузить тег со списком элементов для автозаполнения против like;
$Page = & new Template('/form.html'); $CountryInput = & $Page->getChild('countries'); $CountryInput->setAutoCompleteList($listOfCountries); $Page->display();
В какой-то момент вы столкнулись с Javascript.
Итак, как нам применить генерацию кода полезным способом для извлечения данных со стороны сервера на страницу, которая уже загружена?
Принимая во внимание SOAP / WSDL, я считаю, что лучше всего создать клиент Javascript, который заботится о механизме и полезной нагрузке и должен вызываться только разработчиком.
Чтобы избежать длительного обсуждения, я думаю, что это должно работать более или менее с точки зрения разработчика, работающего с ним.
Если у меня есть класс PHP, как;
class UserAdmin { function & listUsers() { return new DBC::NewRecordSet("SELECT * FROM users"); }
function deleteUser ($ username) {
$ sql = "УДАЛИТЬ ИЗ пользователей, ГДЕ username = '". DBC :: escape ($ username). "'";
вернуть DBC :: execute ($ sql);
}
}
Вы должны быть в состоянии зарегистрировать его с помощью генератора сценариев Javascript, возможно, что-то вроде;
$Generator = & new Javascript_Generator();
if (isset ($ _ GET ['class']) && $ _GET ['UserAdmin']) {
echo $ Generator-> generate ('UserAdmin');
}
Все, что это порождает, я могу вызвать непосредственно в Javascript, например;
Это не так просто - нужно определить обратные вызовы, если мы хотим использовать асинхронные вызовы к удаленному серверу, и я не обсуждал «слушатель» PHP, который отвечает на запросы типа «listUsers».
Но это основная идея. Сгенерированный клиент Javascript построен с использованием отражения из класса, который я определил в PHP. Другими словами, я могу работать с объектом в Javascript, который ведет себя в соответствии с определением класса PHP. Механизм и полезная нагрузка «невидимы» для кода, который я пишу на PHP и Javascript - это просто вопрос заполнения пользовательского интерфейса данными. Надеемся, что потенциальная «ломкость» намного ниже, и изменения можно быстро распространить на Javascript.
Во всяком случае - вот где я, надеюсь, возглавляю эту вещь - время сейчас не позволяет. Может быть, его нужно застрелить, прежде чем он станет длительной тратой времени. Я, конечно, хотел бы услышать лучшие идеи (или еще лучше; что вы уже сделали это).
Более удаленный Javascript
Заканчивая, чтобы дать Джейсону еще кое-что посмотреть;
- XML для скриптов серверных прокси ; больше трюков с атрибутом script src и очень чистой реализацией (часть очень классной библиотеки Javascript).
- JSRS ; использует сгенерированные Javascript iframes. Если я правильно понимаю, очень круто, так как фреймы никогда не добавляются в документ, просто используются для извлечения удаленных данных.
- Удаленные сценарии с Javascript, IFrames и PHP (статья)
- Blueshoes JSRS - кажется, является вилкой из JSRS, связанной выше, которая использует WDDX.
Что-нибудь еще?