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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

Это не очень хорошая идея для 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 inline.

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

Ответ 8

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

Ответ 9

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

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

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

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

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