Разделение разработки frontend в рамках Symfony2

Question

В нашей команде есть разработчики программного обеспечения (PHP, SQL) и веб-дизайнеры (HTML, CSS, JS, Foundation, Bootstrap).

Типичный сценарий: разработчик программного обеспечения реализует бизнес-логику, а дизайн - другой человек.

Проблема: всякий раз, когда есть изменения в дизайне интерфейса, дизайнеры должны отправлять разработчикам новые проекты, они должны отслеживать изменения и изменять источники.

Вопрос: какие инструменты/подходы доступны, чтобы дизайнеры могли работать с шаблонами Twig напрямую и применять изменения в HTML/CSS/JS без помощи разработчиков (без установки Symfony и LAMP, если это возможно)?

Или на более высоком уровне - какова наилучшая практика для разделения разработки бэкэнда и интерфейса в Symfony 2?

Answer 1

Twig относится к контроллерам Symfony для «данных».

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

Если вы используете symfony для предоставления только данных (JSON, основанный на множестве запросов AJAX от front-end), я думаю, что дизайнеры могут работать в одиночку с интерфейсом и имитировать данные JSON в своих локальных установках без использования кода symfony.

Answer 2

Единственная «лучшая практика», которую я мог бы порекомендовать, - поговорить с веб-дизайнерами и понять их потребности.

Поскольку TWIG почти чистый HTML

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

List of Products 
{% for product in products %} 
{% endfor %} 

Как-то я просто не думаю, что будет работать на них.

Я полагаю, что там где-то есть инструмент, который может конвертировать TWIG в настоящий HTML, но что использовать в качестве данных? Если это не соответствует данным о заднем конце, тогда будут возникать проблемы.

Я бы предположил, что вам нужно будет научить ваших разработчиков, как использовать обновление для композитора, а также вашу систему управления версиями. База данных не должна быть проблемой. У вас может быть где-то одна база данных дизайнеров, которая может быть в курсе последних событий. Кто-то еще может установить и настроить стек LAMP,

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

Другой подход - это ядерный вариант. Не используйте TWIG. Ваш задний конец превращается в веб-api и обрабатывает только данные. Никакой back end не генерировал html вообще. Теперь у ваших дизайнеров есть полный контроль над интерфейсом. Бит радикал, возможно, но, похоже, именно так идет отрасль.

Answer 3

Нет никакой «лучшей практики» для разделения разработки бэкэнда и интерфейса в Symfony 2, просто потому, что он использует шаблон MVC, который сам по себе отделяет логику логики от представлений. Все ваши взгляды собраны в одном каталоге, и единственная работа, которую будут иметь ваши дизайнеры, - это отобразить данные. Контролеры и все бэкэнды собираются где-то еще и невидимы для них.

Symfony не является обязательством (хотя это идеальный инструмент для того, что вы хотите сделать прямо здесь), но я бы рекомендовал вам выбрать структуру, которая реализует шаблон MVC, потому что это самый чистый способ разработки, и гарантирует, что ваш код будет долгое время поддерживаться.

Answer 4

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

Решение Out основано на java/javascript, просто мы разработали нашу собственную инфраструктуру для борьбы с проблемой отделения фронта от спины. В настоящее время у нас есть две независимые структуры для этой проблемы: одна для рендеринга на стороне сервера Java, другая - для рендеринга/привязки клиентской стороны с помощью javascript, клиентской структуры MVVM для JavaScript.

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

На втором этапе наши дизайнеры завершат свои работы над независимыми html-файлами без учета логики. Тогда в то же время наши сторонние ребята напишут back-end рендеринг/логику через отдельный источник java/js.

Предположим, у нас есть HTML-файл, как следующие:

<div><input name="name"></div> 
<div><span id="name-preview"></span></div> 

Мы будет выполнять на стороне сервера визуализации с помощью Java следующим образом:

Render.create() 
     .add("[name=name]", "value", user.name) 
     .add("#name-preview", user.name); 

Также мы можем выполнить клиента 2-полосная обвязки javascript следующим образом:

Aj.init(function($scope){ 
    $scope.data = {}; 
    $scope.snippet("body").bind($scope.data, { 
     name:[ 
     Aj.form({name: "name"}), //bind the $scope.data.name to input[name=name] in 2-way 
     "#name-preview" //bind the $scope.data.name to #name-preview in 1-way 
     ] 
    }); 
}); 

Как и в приведенных выше примерах, мы используем общие cs s, чтобы описать, где и как мы хотим отображать/привязывать наши значения.

Фактически, в нашей практике более 90% рефакторинга переднего плана не нуждались бы в помощи со стороны. Даже в левых 10% случаях, когда наши сторонние ребята должны исправлять неудачную рендеринг/привязку, исправление станет очень простым, потому что нам просто нужно изменить целевые селектора css в большинстве ситуаций.

Наконец, хотя мы реализуем нашу инфраструктуру на стороне сервера Java, мы считаем, что ее можно портировать на любые другие языки, такие как PHP, ruby, python и т. Д.

на стороне сервера рамки:

https://github.com/astamuse/asta4d

Клиентская база:

https://github.com/astamuse/asta4js

Answer 5

Или на более высоком уровне - что это лучшая практика, чтобы отделить бэкенд и разработка интерфейса?

Внешняя команда может работать в шаблонах и отправлять вам разметки, а затем разработчики базы данных будут украшать ее данными, то есть как обычно это делается.

НО:

Лучший подход, который вы можете предпринять, чтобы отделить полностью работу «Backend» от работы «Фронтэнд» делает это. :

Создайте свою бэкэнд-логику, чтобы обслуживать данные по требованию (веб-сервис/API), вместо того, чтобы обслуживать представления, отправлять ответ с чистым телом, который содержит только данные в читаемом формате, такие как объекты json.

Затем разработчики frontend могут сделать соответствующий запрос веб-службе, чтобы получить данные и украсить их шаблоны.

Единственное, что вам нужно сделать, это предоставить им URL-адрес, который предоставит данные для шаблона, в котором они работают, и ожидаемый результат/формат, который они будут получать при запросе этого URL-адреса, поэтому они даже не нужен какой-либо сервер, они могут высмеивать ваш ответ во время тестирования/создания представления.

Личное мнение: Я думаю, что даже для простых приложений этот подход замечательный.

Почему?

Если вы создаете свой сервер как веб-службу/API, тогда его было бы легко расширить, в какой-то момент ваше приложение будет использоваться сторонними приложениями или вы просто захотите создать собственную версию мобильного приложения , или что-то еще. Если это так, вам не нужно ничего писать.

Краткая история

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

Приходите , все еще пишу?

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