与 Sencha Architect 的预期协作工作流程是什么？答案

【问题标题】：What is the expected collaboration workflow with Sencha Architect?与 Sencha Architect 的预期协作工作流程是什么？
【发布时间】：2012-05-22 14:58:29
【问题描述】：

我开始试用 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 的正确或预期的协作工作流程是什么。

【问题讨论】：

标签： extjs sencha-touch sencha-touch-2 sencha-architect

【解决方案1】：

看了上面的帖子，我还是不敢相信保留煎茶代码存储库中的元数据文件并从元数据生成所有 JavaScript 适用于大型项目。

Sencha Architect 的理念是将代码不保存在 javascript 文件中，而是保存在 JSON 元数据中，并且每当您需要编辑 JavaScript 代码时，您必须使用 IDE 并编辑元数据。 Phil Strong 说：“我们要求您继续使用 Architect 作为您的编辑器，并且使用 Git 或 SVN 与 20 名工程师一起这样做是完全安全的。”。当然，这个工作流程对 Sencha 来说是非常有利可图的，它强制 20 个人使用获得许可的 Sencha Architect，因为要更改一行 JavaScript 代码，开发人员必须使用 Sencha Architect。

当两个人编辑同一个文件时，IDE 会更新元数据。然后他们将文件签入代码存储库，其中一个必须解决冲突，因此开发人员必须合并两个元数据文件，而不是 JavaScript 文件。

除非开发人员使用 Sencha Architect，否则不让开发人员编辑 JavaScript 的整个想法适得其反，因为同一个人可能同时使用他最喜欢的 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 控制器级别也必须从元数据生成的限制是不行的。

【讨论】：

我理解不得不切换回 Sencha Architect 的挫败感。我们无意使用邪恶来强迫您使用 Architect 编辑文件。 Architect 使用的元数据文件允许它知道平面文件永远无法知道的各种事情。
我理解不得不从服务器端编辑器切换回 Sencha Architect 的挫败感。它归结为应用程序构建器与文本编辑器，SA 是前者。元数据文件允许 Architect 知道平面文件永远无法知道的各种事情。有了这些额外的信息，Architect 可以将您的项目从 Touch 2.0 升级到 2.3，并且它可以正常工作。这里的一个例子可能是 click 事件改变了它传递给监听器 fn 的参数的顺序。 Architect 可以在您的项目中更新 1000 个实例，而您永远不必知道此更改。
"Sencha Archtect 添加了额外的步骤，它需要您发布 javascript" 不完全正确，您可以在保存后尝试 app/ 文件夹中的代码，正如我在这里讨论的那样：sencha.com/forum/showthread.php?296277

【解决方案2】：

虽然我非常感谢 Sencha 在创建有用且功能齐全的开发环境方面所做的努力，但我认为 Sencha Architect 还没有为相对较大的项目和开发团队做好准备。

我最初的 Architect 软件对于快速原型设计和设计复杂的 UI 结构非常有用，但话又说回来 - 在你弄清楚你的 UI 元素将在 JS 文件中放置的方式之后 - 通常复制粘贴现有的 JS 代码会更容易和更快.

我认为这不是您要寻找的答案，我只是想分享一下我的想法。

【讨论】：

我在试用这个应用时也有同样的感觉。如果您打算将它用于编码方面而不仅仅是视觉布局，您会变得非常锁定它。在 sencha 网站上，他们说你可以使用任何你想要的 IDE，但我认为这有点误导。因为手动编辑文件会破坏与 Architect 的兼容性。当然，您可以将任何 IDE 用于您自己的 3rd 方库；-)
特别是当 IDE 不支持框架支持的所有功能时，例如配置文件。
您的视图似乎是基于 Ext Designer 的工作方式。您是否尝试过与 Sencha Architect 合作？看我的回答

【解决方案3】：

当我搜索同一主题时，我发现 metadata/ 目录是项目的重要内容，并且所有组件都被分离到它们自己的元数据文件中。这与根级项目文件一起，可能是版本控制的重要部分。 app/ 在保存时会重新生成，可能会从版本控制中排除。

主要的 xds 项目文件包含更通用的引用，并且可能比元数据组件更改的频率更低。但在创建新组件或修改项目/应用级别设置时，它会发生变化。

理想情况下，如果您只签入根文件和元数据文件夹，它应该可以正常工作。

【讨论】：

“它应该可以工作” - 但它没有。想象一下 2 或 3 个不同的开发人员同时处理同一个 Architect 项目。每个开发人员都会添加新文件并编辑相同的现有文件。随之而来的合并冲突绝对是可怕的，我必须同意 Sergey Grigoriev 给出的答案。
通过从项目文件中删除很多杂乱无章的内容，这在很大程度上得到了解决。如果您仍然看到此行为，请发表评论。

【解决方案4】：

使用 Sencha Architect 在具有源代码/版本控制的团队中工作非常容易。一个 Architect 项目都包含在一个项目目录中。里面是由n个部分组成的

项目文件 - 由 Architect 用于打开和维护项目的少量数据组成。这是单个文件，您可以双击打开它
元数据目录 - 包含描述项目所有部分的文件。每个类（控制器、视图、模型、存储、资源）都将其信息存储在自己的文件中。
app 目录 - 包含您创建的项目的 src。每个类都有一个 javascript 文件。
其他根文件 - app.html 和 app.js，它们是您的应用程序的启动板以及预览应用程序时运行的内容。这也是您的 packager.json、app.json 所在的位置。

我描述所有这些的目的是向您展示 Architect 生成的文件与您在您最喜欢的编辑器中手动创建的文件几乎相同。唯一的附加信息是元数据和项目文件。元数据都是 JSON。

现在！！我们要求您继续使用 Architect 作为您的编辑器，并且使用 Git 或 SVN 与 20 名工程师一起这样做是非常安全的。当开发人员进行更改时，它会更改这些文件的元数据和应用程序。

【讨论】：

-1 因为“很容易”纯粹是主观的。正如 Sergey Grigoriev 的回答中所解释的那样，版本控制可能很容易，但在团队中工作并不容易。

【解决方案5】：

我在私信中从 Sencha 向 Aaron 提出了同样的问题。他建议检查整个项目结构，包括应用程序和元数据。它有效，我们在团队中做了一个流程。

【讨论】：