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

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



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

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.



Не могу чего-то придумать по этому поводу. А как вы выкручиваетесь?
  • Вопрос задан
  • 2541 просмотр
Пригласить эксперта
Ответы на вопрос 5
У меня лично, ID элементов (как и сами элементы) являются неприкосновенными, дизайнеру дозволено менять только стили этих элементов.
Ответ написан
Комментировать
@rowdyro
Решение задачи сильно зависит от контекста.
Например теперь у вас 2 вещи которые может переименовать дизайнер, и надо следить за их соотвествием.

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы