Каков ожидаемый рабочий процесс совместной работы с Sencha Architect?

Я начал судебный процесс над Sencha Architect, и чем больше я использую его, тем больше вопросов приходит на мой взгляд для его фактического использования осуществимости в среде разработки, один из самых больших вопросов у меня есть

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

app/models|components|views/Model1.js  <- In charge of developer one
app/models|components|views/Model2.js  <- In charge of developer two.

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

Ответ 1

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

Основной файл проекта xds содержит более общие ссылки и, вероятно, будет изменяться реже, чем компоненты метаданных. Но это изменится при создании новых компонентов или изменении настроек уровня проекта/приложения.

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

Ответ 2

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

Идея Sencha Architect заключается в том, чтобы сохранить код не в файлах javascript, а в метаданных JSON, и всякий раз, когда вам нужно отредактировать код JavaScript, вам нужно использовать IDE и редактировать метаданные. Фил Стронг сказал: "Мы просим вас продолжать использовать" Архитектор "в качестве вашего редактора, и это с 20 инженерами совершенно безопасно, используя Git или SVN.". Конечно, этот рабочий процесс очень выгоден для Sencha, он заставляет 20 человек использовать лицензированный Sencha Architect, потому что для изменения одной строки кода JavaScript разработчик должен использовать Sencha Architect.

Когда два человека редактируют один и тот же файл, IDE обновляет метаданные. Затем они регистрируют файл в репозитории кода, и один из них должен разрешать конфликты, поэтому разработчику необходимо объединить два файла метаданных, а не файлы JavaScript.

Вся идея не позволить разработчикам редактировать JavaScript, если они не используют Sencha Architect, не контрпродуктивна, потому что тот же человек может использовать свою любимую IDE для разработки Java и JavaScript, или для Python и JavaScript. Выполнение как клиентского, так и серверного программирования в одной IDE быстрее, чем переход между двумя IDE. Реальность большого проекта заключается в том, что у вас есть несколько команд по всему миру, которые работают с разными IDE, у вас также может быть краткосрочный проект, реализованный подрядчиком, который также имеет свою любимую среду IDE.

ExtJS - хорошо спроектированная среда, вам не нужен SenchaArchitect для изменения одной строки кода JavaScript.

При кодировании в JavaScript я сохраняю свой файл JavaScript и обновляю браузер и сразу вижу изменения. Sencha Archtect добавляет и дополнительный шаг, он требует, чтобы вы публиковали javascript (генерировать JavaScript из метаданных), и чем больше проект, тем дольше задержка. Часто мне приходится модифицировать файлы JavaScript в процессе производства, иногда меняя одну строку, устраняем проблему, опять же, я должен использовать Sencha Architect для повторной генерации этой отдельной строки из метаданных.

Я использую Sencha Architect только для быстрого прототипирования, а затем сгенерированных файлов в репозиторий кода и продолжаю редактировать JavaScript вручную. При таком подходе я могу использовать систему управления версиями, чтобы просмотреть историю JavaScript. Если я проверил метаданные JSON на VCS, то у меня не было бы истории JavaScript, у меня была бы история метаданных JSON, которая несовместима.

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

Ответ 3

В то время как я очень ценю усилия Sencha в создании полезной и полнофункциональной среды для разработчиков, я не думаю, что Sencha Architect вполне готов к относительно крупным проектам и группам разработчиков.

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

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

Ответ 4

Работа с командой с контролем источника/версии довольно проста с Sencha Architect. Проект "Архитектор" заключен в каталог проекта. Внутри него состоят из n частей

файл проекта - состоит из небольшого количества данных, используемых архитектором для открытия и поддержки вашего проекта. Это единственный файл, который вы можете дважды щелкнуть, чтобы открыть его.
каталог метаданных - состоит из файлов, которые описывают все части вашего проекта. Каждый класс (контроллер, представление, модель, хранилище, ресурс) имеет информацию, хранящуюся в нем в собственном файле.
каталог приложения - состоит из src проекта, который вы создали. Файл javascript для каждого класса.
другие корневые файлы - app.html и app.js, который является стартовой панелью для вашего приложения и что запускается при предварительном просмотре вашего приложения. Это также то место, куда будет идти ваш packager.json, app.json.

Точка зрения, описывающая все это, - показать вам, что файлы, созданные Архитектором, в значительной степени идентичны тем, что вы создали бы в своем любимом редакторе вручную. Единственной дополнительной информацией являются метаданные и файл проекта. Метаданные - это все JSON.

СЕЙЧАС!! Мы просим вас использовать Архитектор в качестве вашего редактора, и сделать это с 20 инженерами совершенно безопасно, используя Git или SVN. Когда разработчик вносит изменения, он изменяет как метаданные, так и приложение для этих файлов.

Ответ 5

Я задал тот же вопрос Аарону из Сенча в личном сообщении. Он предложил проверить всю структуру проекта, включая приложение и метаданные. Это работает, мы сделали один поток в нашей команде.