А как Вы осуществляете взаимодействие модели на стороне сервера с клиентской?

Question

[Vampiro]

Добрый вечер. Сижу вот, смотрю на код. И Терзают меня смутные сомнения, что я что-то делаю «не так». Код по сути своей довольно простой.



Есть страничка, на ней есть

input type="text" id="login" <br>

запускается ajax, который формирует ответик вида

$("#login").html("test");<br>



Не пойдет, подумал я, ведь завтра-послезавтра ушлый дизайнер подправит шаблон, переименует id, и я получу "а-та-та" за неработающий код. Сказано — сделано.

Делаю на клиенте функцию

updateLogin = function(text){<br>
 $("#login").html(test);<br>
}<br>

ну и в ajax-скрипте на сервере вставляю текстовую константу в код. Получается вот такая шняга:

$answer = "updateLogin(".$text.");";<br>



Вроде как я дал свободу дизайнеру, но осадок остался…

во-первых, что ему мешает переименовать функцию в шаблоне? Ничего.

во-вторых, само формирование строки в коде вызывает у меня непреодолимое желание нажать Ctrl-Y.



Не могу чего-то придумать по этому поводу. А как вы выкручиваетесь?

Answer 1

[Виталий Желтяков]

У меня лично, ID элементов (как и сами элементы) являются неприкосновенными, дизайнеру дозволено менять только стили этих элементов.

Answer 2

[Rowdy Ro]

Решение задачи сильно зависит от контекста.
Например теперь у вас 2 вещи которые может переименовать дизайнер, и надо следить за их соотвествием.

Лучше вообще отделять контроллер(сервер) от отображения(клиент). Заберайте с сервера просто данные, напримре в jsone, а потом уже на клиенте решайте куда их засунуть.

Comments

[denver]

Поддержу, неправильно для ЯП возвращать код. Надо возвращать данные, а уже кто их получает — делает с ними что хочет. Об этом AJAX, но сейчас более актуален AJAJ или AJAH.

[Vampiro]

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

Представьте, что я хочу закрыть какое-то окно у пользователя на сайте, или переставить значение на часах в виджете на сайте. Что-то вроде remoteDesctop, но в рамках сайта. Понятно, что если пользователь запрашивает текст — надо ему отдать текст и он сам его вставит. Но если инициатором действия является сервер? =( Или, точнее — другой клиент с другим открытым окном сайта… Понимаете, о чем я теоретически? =)

[Rowdy Ro]

Если у вас аякс, то инициатором всегда идет клиент, он спрашивает что-то у сервера, сервер ему отвечает. Например, дай мне команду что надо выполнить, клиент выполняет.

Смотрите в сторону json-rpc или websockets, но там все равно какой-то rpc надо прикручивать.

Очень плохо передавать на клиент чистый js — завтра сделаете приложение для айфончика, и ничего не надо переписывать на стороне сервера — просто корректно обрабатывайте команды.

Answer 3

[Wott]

в этом есть три вещи — html, javascript и сервер. между ниим есть интерфейсы: html должен иметь определенные именованные узлы и структуру DOM что бы JS код правильно его менял на реакцию пользователя, а сервер должен принимать и отвечать JS в определенном формате данные. Понятно что интерфейсы менять просто так нельзя, поэтому единственным выходом является зафиксировать необходимые для интерфейса вещи и не разрешать их менять без подтверждения заинтересованных сторон.

Comments

[Vampiro]

Это гладко, когда небольшая команда и небольшой проект. Но при рефакторинге, любое изменение в js-коде превратится в ахтунг по поиску его вызовов в серверной части, к которой js-щики не имеют доступа =(
Но идея с Интерфейсами реально хороша в плане документирования. Надо подумать на эту тему, спасибо.

Answer 4

[denver]

Не буду перебивать rowdyro, отвечу здесь.
Всё еще смутная задача, но если я правильно понял, то у вас есть функции на клиенте которые влияют на оформление (а если функций нет, а влияние есть, то лучше их создать как вы правильно решили. Верно, лучше они будут в том же слое, в котором влияют. Иначе дольше искать кто влияет). То что их могут переименовать несущественно, главное чтобы человек мог легко найти и переименовать еще в тех местах они фигурируют. #login ищется хуже, чем #_API_login, да и нет смысла так именовать каждый потенциально затронутый элемент, а вот переименовать updateLogin в myAPIUpdateLogin лучше — это легко грепается. Последний штрих — вместо вызова функции всё же возвращать отдельно имя функции и параметры:

$answer = json_encode(array(
  "func" => "myAPIUpdateLogin",
  "params" => array(
    $text,
  ),
);

Так по крайней мере абстрагируетесь от ошибок экранирования, да и формализируете свой пока неформальный js API.

Comments

[Vampiro]

Так мне не очень нравится, что русский текст уходит к клиенту в мозгодробящем \u04ХХ-виде. + довольно сложно сформировать условия в запросе. Сюда не вставить никакие «if» или «for» =(

[denver]

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

[denver]

if / for должны быть в updateLogin(), иначе будет неявноя (но прямое) влияние на верстку из контроллера, и вытекающие из этого проблемы — неявность, сложный рефакторинг, сложность обработки ошибок.

Answer 5

[balloon]

верстка: если существует вероятность того, что дизайнер будет завязываться на id/class, то Вам следует завязываться на аттрибуты, которые дизайнер точно не должен менять. Для input — это аттрибут name, тогда селектор будет вида $('input[name="login"]'). Для div и подобных можно привязываться к недизайнерским классам + подселекторы.

server — javascript : я за json в ответах :) поэтому я бы с сервера присылал json вида {login: 'habr', field: 'value'} и на клиентской стороне обходил его и апдейтал присланые поля $('input[name="' + field + '"]').html(value)

Comments

[arXangel]

А так же можно использовать MVC фреймворки или библиотеки вроде knockout.js. И конечно же, json — наше всё.