Является ли эхо-код JavaScript обоснованным на основе серверной логики, считающейся вредной?

Как это:

 setSomeStuffUp();  doSomeOtherStuff();  breakSomeStuffDown();  

Нашел что-то вроде этого на работе – с шаблоном (Smarty), поэтому он выглядит немного чище, но не сильно! Также перекликается с некоторыми переменными шаблона, используемыми для таких вещей, как селектора jQuery и другие небольшие неприятные биты.

Каков правильный способ сделать это? Загрузите данные, которые необходимо использовать для логики в JS, как JSON через AJAX? Атрибуты данных HTML?

Что-то в нем просто пахнет плохо, плохо, плохо.

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

Плохая практика использования языка X для генерации кода на языке Y.

Попробуйте «развязать» два языка, например:

  

Таким образом, PHP только заботится о заполнении структуры данных, и JavaScript только заботится о потреблении структуры данных.

Повторяющиеся параметры конфигурации и некоторый код инициализации javascript с сервера в общем не звучат слишком плохо, но если такие fragmentы js-injection-from-server повсюду, то вы правы, это уродливо, по крайней мере, потому что такой код трудно управлять.

Просто попробуйте централизовать все виды инициализации и сделайте все остальное в статически определенной клиентской логике JavaScript.

UPD. @ Оскар Хара говорит о том же и дает хорошую иллюстрацию. Но часто даже таких случаев можно избежать, если серверная логика предоставляет данные для обработки JavaScript через HTML (в конце концов, для этого и предназначен HTML).

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

Созданный сервером HTML:

 
  • Лично я использую PHP в JS во многих случаях. Иногда приходится заполнять переменную данными JSON, идентификатором страницы или что-то в этом роде. Насколько мне известно, PHP предназначен для написания кода, который появляется на странице, а JS предназначен для взаимодействия с пользователем, когда контент есть.

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

    В ответ на то, что самый чистый способ сделать это, было бы, если бы это было большой сделкой … Я бы создал отдельный JS-файл с этим кодом, а затем использовал сервер, чтобы включить этот отдельный файл, если это необходимо. Опять же, я этого не делаю, но я думаю, что это будет выглядеть самым чистым в шаблоне.

Если вы хотите действительно разобраться, вы можете запросить HTML-страницу файла .js в сочетании с идентификатором сессии или другим индикатором того, кто они есть, управлять вызовом .js как вызовом PHP, динамически строить JS на основе того, что требует их сеанс, а затем выводить его обратно в браузер в виде файла .js.

Но это большая работа.

Если вы хотите что-то, что пахнет меньше, у вас есть дамп PHP или JSON-строка в конце вашего файла:

 var cfg_string = "{\"username\":\"Norguard\", \"new_messages\":[......]}"; // client $cfg_obj = array(); // whole lot o'PHP $json_encoded_cfg = json_encode($cfg_obj); echo "var cfg_string = {$json_encoded_cfg};" //server-side 

А потом разобрать его, в клиенте для дополнительной безопасности …

… или просто создать карту в шаблоне:

 $cfg_string = "var dataMap = {"; foreach ($cfg_obj as $key => $val) { // print key:val all pretty-like, // handle commas (ie: no trailing comma at the end), indent with tabs or spaces // if you want, count the number of items so that the object closes ({}) // without any newline operator, if there are no config settings } echo $cfg_string; 

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

Если все, что вы делаете, это передача данных с серверного языка на код JavaScript, то все в порядке. Там много пакетов CMS.

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