Должны ли фреймворки PHP генерировать JavaScript?

Question

Я заметил, что PHP фреймворки; Zend , Cake и Symfony ; похоже, либо генерирует JavaScript, либо позволяет встраивать его как строку в сам PHP. Это хорошая идея? От людей, которые использовали эти фреймворки / библиотеки, какой у вас был опыт работы с помощниками Ajax и JavaScript? Это было легко поддерживать? Это сокращает время разработки?

Answer 1

Нет, это плохая идея,

Сгенерированный javascript обычно означает, что сайт даже не будет функционировать без него (как многие сайты asp.net). Если вы хотите сделать более сложные вещи или улучшить доступность, нет другого пути, кроме как четко отделить HTML от CSS и Javascript.

Разделение Javascript также делает ваш код более понятным, так как вам не нужно, чтобы ваши веб-разработчики на стороне клиента связывались с вашим PHP-кодом и наоборот.

Лучший способ использовать Javascript - сначала позволить php сгенерировать ваш html, а затем в нижней части этой страницы включить ваши файлы javascript и использовать такие функции, как onDomReady. Это также не заставляет вас использовать определенную библиотеку только потому, что ваша инфраструктура использует ее как основу для своего сгенерированного Javascript.

Answer 2

Я бы сказал, это зависит, как и все. Конечно, имеет смысл иметь «умные» виджеты на стороне сервера. Например, виджет, который «знает», как обновлять себя через AJAX, или форма, которая может обрабатывать клиентскую часть и проверку на стороне сервера. Последнее является примером того, что было бы дорого и много времени и ошибок, чтобы переписать скучный код проверки в клиенте. Он не требует ракетостроения javascript, поэтому, пока ваша инфраструктура может работать с ним незаметно, я бы на самом деле посоветовал этот маршрут. Кроме того, фреймворковый код, который также будет обрабатывать GUI (например, ext или что-то подобное), тоже неплохая идея.

Однако, что-нибудь более сложное, пожалуйста, используйте сам Javascript.

Answer 3

Лично мне нравится писать свой Javascript вручную, ненавязчиво, так что мне просто нужно добавить дополнительное событие в document.domReady, например, с правильными параметрами. Эта маленькая триггерная функция затем заставляет мяч двигаться.

Лучшая практика дня:

Сохранение внешнего кода и внутреннего кода. распутать столько, сколько вы можете

Answer 4

Это довольно субъективный вопрос, но лично я бы не хотел, чтобы серверная среда делала это для меня. Лучше сохранять четкое разделение между бизнес-логикой, представлением и поведением пользовательского интерфейса на стороне клиента по ряду причин:

• Больше поддерживаемых приложений.
• Проще тестировать отдельные компоненты.
• Простое сотрудничество. Различные наборы навыков могут работать в разных областях.
• Должно помочь гарантировать, что ваше приложение не использует JavaScript в среде конечных пользователей.

Answer 5

Для PHP не очень хорошая идея генерировать Javascript. Единственный javascript, который я бы порекомендовал экспортировать, это простые JSON-назначения, подобные следующим:

<script type="text/javascript"><!--
  var MyNamespace.info = <?php echo json_encode($info_array) ?>
// --></script>

Это самый простой способ обезопасить информацию PHP и сделать ее доступной для javascript на клиенте. Тем не менее, все остальное должно быть записано в реальных файлах JAVASCRIPT, на которые есть ссылки с тегами в начале документа. Единственное другое появление Javascript из файлов на стороне сервера, которое, я бы сказал, в порядке, это вещи, помещенные в «onclick» и другие подобные атрибуты.

Основанием для этого является то, что Javascript должен быть написан и поддерживаться внешними людьми, которые знают Javascript, и сайт должен быть способен (хотя бы частично) работать без javascript. Нет причин генерировать спагетти встроенный Javascript.

Посмотрите мой PHP-фреймворк PHP On Pie (http://phponpie.com) для примера того, как правильно реализовать это. Он разделяет JS и PHP, за исключением случаев экспорта JSON, как показано выше. Однако он также предоставляет соглашения для легкого взаимодействия между клиентом и сервером через AJAX.

Answer 6

Мой опыт работы с помощниками Javascript и Ajax в CakePHP был очень позитивным.

Они позволили разработчикам на стороне сервера создавать прототипы и создавать функции, которые в противном случае потребовали бы от кого-то, имеющего реального опыта работы на стороне клиента, всего, не беспокоясь о качестве кода JavaScript, который они "пишут" и оставляя настоящих фронт-инженеров свободными, чтобы сосредоточиться на передовых клиентских функциях.

Answer 7

Мне лично нравится писать свой собственный Javascript, поэтому я не хочу, чтобы он был написан для меня, но я не считаю его особенно «опасным» или «вредным», чтобы иметь фреймворки, которые делают это для вас, пока как это правильно сделано. Моя самая большая проблема с ними заключается в том, что большинство из них будет работать столько, сколько вам нужно стандартное поведение функции, но как только вы захотите, чтобы что-то немного изменилось для удовлетворения потребностей вашего проекта, потребовалось бы так много работы, чтобы настроить его. лучше обслужить, чтобы сделать это самостоятельно. По крайней мере, это был мой опыт с автоматизацией JavaScript в CakePHP.

Answer 8

Я думаю, что определенно есть место для сгенерированного javascript. (1)

Причиной номер один для созданного JavaScript является простота обслуживания. Любые зависимости явно кодируются и конфигурируются из самого фреймворка (PHP, ruby, scala, python). Например, если вы перемещаете свои активы или изменяете каталог загрузки, просто обновите конфигурацию и наблюдайте за событиями Just Work.

Нужна проверка ввода на стороне клиента, чтобы снять нагрузку с вашего сервера? (2) Позвольте платформе генерировать правильный код проверки, полученный непосредственно из вашей модели данных для вас. При сгенерированном javascripted заполнении ваша инфраструктура может обслуживать предварительно визуализированные статические HTML-формы из кэша. Это может быть огромным выигрышем, если ваши формы содержат много вариантов выбора и параметров.

1) Предполагая, что клиент решил, что для сайта нормально (более или менее) зависеть от javascript со всеми вытекающими отсюда предостережениями Изящная деградация может быть или не быть возможной или желательной.

2) Вам также нужна проверка на стороне сервера, но вы это знали, верно?

Answer 9

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