Так много раз на этом сайте я видел людей, пытающихся делать такие вещи:
<script type="text/javascript">
$(document).ready(function(){
$('<?php echo $divID ?>').click(funtion(){
alert('do something');
});
});
</script>
Я не думаю, что это какая-то модель, в которую люди естественно впадают. Там должно быть какое-то учебное пособие или учебный материал, показывающий это, иначе мы бы этого не увидели. То, что я спрашиваю, я делаю слишком большое дело или это действительно плохая практика?
РЕДАКТИРОВАТЬ: говорил об этом с моим другом, который часто вставляет рубин в свой JavaScript, и он поднял этот вопрос.
Можно ли динамически размещать константы всего приложения в вашем JavaScript, чтобы вам не приходилось редактировать два файла. например...
MYAPP.constants = <php echo json_encode($constants) ?>;
также можно ли напрямую кодировать данные, которые вы планируете использовать в библиотеке
ChartLibrary.datapoints = <php echo json_encode($chartData) ?>;
или мы должны каждый раз звонить AJAX?
php
javascript
web-development
Грег Гуйда
источник
источник
this question will likely solicit opinion, debate, arguments, polling, or extended discussion.
...Ответы:
Как правило, использование языка X для генерации кода на языке Y является плохой практикой.
Попробуйте разделить два языка, сделав данные единственным интерфейсом - не смешивайте код .
В вашем примере вы могли бы улучшить код, используя PHP для заполнения
cfg
структуры, доступной для JavaScript:Таким образом, PHP заботится только о заполнении структуры данных, а JavaScript заботится только о потреблении структуры данных.
Это разделение также ведет к асинхронной загрузке данных (JSON) в будущем.
Обновить:
Чтобы ответить на дополнительные вопросы, которые вы задавали в своем обновлении, да, было бы полезно применить принцип DRY и позволить PHP и JavaScript совместно использовать один и тот же объект конфигурации:
Нет ничего плохого в том, чтобы вставить JSON-представление вашей конфигурации прямо на вашу страницу, как это. Вам не обязательно получать его через XHR.
источник
data-
атрибут в своем HTML. Нечто подобное<body data-cfg="{...}">
.Динамически генерируемый JavaScript - ужасная, плохая практика.
То, что вы должны сделать, это понять, что означает разделение проблем и прогрессивное улучшение.
Это в основном означает, что у вас есть динамический HTML и статический JavaScript (который улучшает HTML).
В вашем случае вы, вероятно, хотите класс на вашем div и выберите его с помощью селектора класса
источник
Самая большая проблема с вашим фрагментом кода - вы упускаете его,
#
чтобы сделать его действительным селектором jQuery;).Я бы сказал, что вам следует избегать включения PHP в ваш JavaScript, где это возможно. Что не так с заменой селектора в вашем
click()
обработчике на класс и добавлением класса к рассматриваемому элементу, если вы хотите, чтобы обработчик был запущен, а не если вы этого не сделаете;Там являются обстоятельства , когда вам необходимо включить PHP в вашем JavaScript; но я должен признать, что это немного и далеко друг от друга.
Один пример - когда у вас разные среды; тестировать, ставить и жить. Каждый из них имеет свое местоположение (в основном изображения). Самый простой способ установить путь так, чтобы он мог использоваться JavaScript, - это что-то вроде;
источник
#
=), но серьезно я согласен, что ваш пример - лучший способ сделать это. Мне кажется более естественным делать это и так. Так почему же мы видим это так часто в тех местах, где это не нужно?$divID = '#' . $element_id_value;
- нет проблем с боссом селектора;)На мой взгляд, это плохая практика, так как вам нужно было бы назвать этот файл нечто.php, а затем вы не могли бы, например, сжать его, не говоря уже о том, что не стоит смешивать содержимое вашего сервера с вашим JavaScript. Постарайтесь максимально ограничить смешивание между PHP и JS.
Вы всегда можете сделать это вместо этого:
И тогда вы можете вызвать эту функцию в php-файле, чтобы сделать эти вещи смешивания как можно меньше.
Делая это (имея большие JS-файлы, а не 2-3 строки, где это не имеет значения), вы можете воспользоваться сжатием JS-файла, и разработчики внешнего интерфейса чувствуют себя комфортно, работая на JavaScript только с моей точки зрения (как вы могли бы написать Python, Ruby и т. Д. Не только PHP - и код может становиться все больше и больше в зависимости от того, что вам нужно там делать).
источник
Я не думаю, что это плохая практика. Если идентификатор, требуемый в вашем JavaScript, является динамическим, другого способа сделать это не существует.
источник
Я бы посчитал это плохой практикой. При размещении динамического содержимого внутри блоков скрипта вы всегда должны учитывать тот факт, что экранирование внутри контекста JavaScript не так просто, как вы надеетесь. Если значения были пользователем при условии, что это не достаточно , чтобы HTML-избежать их.
Шпаргалка OWASP XSS имеет больше деталей, но в основном вы должны принять эту модель:
Затем в отдельном файле .js, связанном с вашим основным html, загрузите этот код:
Причина использования отдельного файла .js двояка:
источник
$.ajax
или аналогичныйНекоторые люди утверждают, что это плохая практика. Не потому что это PHP внутри JS, а потому что это встроенный JS и поэтому не будет кэшироваться браузером для простоты загрузки в следующий раз.
IMO, всегда лучше использовать JSON для передачи переменных между двумя языками, но я думаю, что решать вам.
источник
Я бы сказал, что вообще не делай этого. Однако, если вы хотите передать данные из PHP -> Javascript, мне не безумно будет иметь встроенный блок Javascript, где у вас есть код формы, показанной ниже. Здесь код просто передает данные из php в javascript, а не создает логику на лету или тому подобное. Хорошая часть этого по сравнению с ajax-вызовом состоит в том, что данные становятся доступными, как только страница загружается, и не требуют дополнительной поездки на сервер.
Конечно, другой вариант - создать файл конфигурации javascript из PHP с помощью сценария сборки, который поместит его в файл .js.
источник
Единственное, о чем я могу подумать, это действительно может вызвать проблемы - это когда ошибки PHP настроены на отображение, и это добавляет нагрузку HTML, показывающего ошибку PHP, в ваш JavaScript.
Кроме того, потому что это в скрипте, поэтому он не отображается, и иногда может потребоваться время, чтобы понять, почему ваш скрипт сломан.
источник
Это зависит от того, кем, и если вы спросите меня, да, я считаю это практикой по нескольким причинам. Прежде всего, я бы предпочел иметь код javascript в своем собственном JS-файле, который парсер php не сможет обработать.
Во-вторых, php выполняется только во время сервера, поэтому, если вы зависите от какой-либо переменной в php, чтобы изменить свой javascript, это может работать не очень хорошо. Если есть какой-либо параметр загрузки страницы, которым вы хотите управлять с помощью javascript, я обычно предпочитаю добавить это значение в DOM с помощью php, чтобы javascript мог достичь его, когда и если захочет (например, в скрытом div).
Наконец, только для организационных целей это может стать очень раздражающим. Это достаточно плохо, чтобы смешивать HTML и PHP (по моему мнению).
источник
Содержание PHP в
config
объект данных проходит 90% пути, но лучше всего отделить его полностью. Вы можете использовать RESTful API для запроса только тех данных, которые вам нужны, это немного больше JavaScript, но с некоторыми преимуществами.Недостатки:
скрипт
источник
ТОЛЬКО это не плохая практика, если он используется для инициализации кода javascript (в моих темах WordPress я инициализирую свои объекты javascript с помощью функций php, таких как site_url (), потому что это единственный способ справиться с этим (возможно, мы могли бы использовать запрос ajax для получения JSON, и так ... но это боль в заднице).
Хорошая практика:
новый javascriptObject ("");Плохая практика:
/ * некоторый код * / document.get_element_by_id (); / * некоторый код * /источник