Partkeepr: 新版本开发过程

自 2018 年 7 月 20 日以来没有进行任何提交。所以我认为我们不是在讨论下一个版本的 ETA，而是讨论新的主要开发人员的 ETA。 在我们有一个之前，我们肯定不会有任何版本。 但是我很好奇，目前的状态是什么。

最新的项目信息在这里： https :
基本上该项目不再有维护者，但如果有人认真想接受它，这似乎是可能的。

所以@christianlupus是对的，它实际上是 ETA 直到新的维护者。

.

如果没有可靠的项目管理（并且可能在现阶段获得资金），拥有 5 个开发人员可能毫无用处，项目可以通过一两个来生存，唯一产生的问题可能是开发时间。

她指出的一个问题非常明确：问题管理和处理行为不良的人。

该项目可以愉快地与两个开发人员一起生活，即使有健康问题，只要有人进行问题分类和社区管理，开发人员就可以专注于一项任务而不必担心其他事情。

.

PartKeepr 会使用另一个框架，同样的论点也适用，Symphony 并不是真正的小众框架。

是的，它需要知道或愿意学习它的人，就像任何其他框架一样。

是的，它可能是一个小众应用程序，但上下文是要考虑到，如果你知道交响乐，你是否有动力加入一个看起来已经死了的项目？ 可能不是。

.

它真的需要一个先进的现成框架吗？

它并不比另一个更先进，它只是一个框架，是的，您可以使用一个非常轻的框架，但最终您将添加大量扩展或从头开始制作它们以获得相同的结果，甚至更糟糕的是，它不会像“先进的现成框架”那样被记录和测试。

但是以一种很好的方式修复这些变通方法需要大量的重新设计，这可能不适用于 Symphony 框架或任何其他现成的框架。

我们在这里不是在谈论 Win32 应用程序，除非你有一个 POC 来证明它在当前框架下不可行，否则它就是 BS。
重新发明轮子有时可能有效，但这并不是每次都有效的解决方案。

如果您说“交响乐学习曲线太陡峭”，那么定制的东西应该如何更好？

现在咆哮“交响乐很糟糕，除非我们重写所有内容，否则该项目注定要失败”不会使项目进一步发展，在 PR 上工作并与贡献者一起工作是。

.

例如，如果我想要具有级联规范的类别，这些类别也级联到此类类别中的组件（有可能覆盖它们）。 而不是根据组件的类型显示所有组合规范的良好格式化描述。 我应该期待在 Symfony 中工作吗？

不，没有任何框架可以做到这一点。 我认为您对框架是什么有误解。 Categories 的实现是特定于应用程序的，没有通用框架会处理它。

我不认为 Symphony 或其他框架不好。 但就我希望库存管理系统的外观而言，他们不太可能成功。 这不是在谈论 BS，而是对所涉及的复杂性的良好理解。

一个框架与特定的应用程序有什么关系？ 任何框架都不了解应用程序的工作原理。 它提供了一个计划、理念和模型来构建。

附加说明：是的，我仍然需要将存储库访问权限传递给某人，不幸的是，我正忙于清理 PartKeepr UG。 我希望我能尽快解决这个问题

.

嗨，费利西亚，

我对 Symphony 作为框架的理解 - 如上所述 - 是有限的。 但是，例如，如果它通过直接从表、查询中读取来创建 UI 视图，则很难显示以高级方式相互链接的信息。

在这种情况下，阅读 Symfony 提供的内容和不提供的内容实际上可能会更好，而不是做出错误的假设。 Symfony 没有生成 UI 视图，至少在 PartKeepr 中没有。

提议的级联和继承信息很难查询，因此（表驱动）框架可能很难处理，还是我误解了事情？

是的，你误解了一些事情。 Symfony 没有提供这样的东西，也许通过一些 3rd 方包，但同样，PartKeepr 不使用这样的包。 Symfony 主要用于控制器架构、序列化功能（结合使用 API 平台生成 JSON-LD，然后前端可以读取）和所有数据库相关内容的 Doctrine。

请参阅https://wiki.partkeepr.org/wiki/Developers/Architecture

.

嗨，费利西亚，

感谢您的回复。 我编写了很多东西，甚至是早期的网络技术。 但这在理解 PartKeepr 的架构方面相当缺乏。 此外，作为 Windows 开发人员，很难掌握所使用的不同技术。 正如我所说，学习曲线太陡峭。 但潜在的问题仍然有效。 开发目标是什么，使用的技术可以达到这些目标。 不管他们怎么称呼。

使用框架的原因，尤其是像 Symfony2 这样被广泛使用、采用和维护的框架：

• 避免代码重复
• 提高可靠性
• 不要重新发明轮子
• 提高可维护性
• 减少工作

在 PartKeepr 0.1.9 之前，它没有使用除 Doctrine 之外的框架来实现持久性（当时不存在 Symfony2）。 维护是一场噩梦。

PartKeepr 中没有 SQL 注入的原因是因为 Doctrine。 之所以0.1.9之后短时间内有这么多新特性，是因为Symfony2和API平台极低的开发开销。 PartKeepr 在没有我编写零代码来支持它的情况下在反向代理后面工作的原因：Symfony2。 PartKeepr无需任何代码修改即可在nginx上运行的原因：Symfony2。

如果您在理解 Symfony2 的工作方式时遇到困难，没问题：网上有很多资源可以帮助您。

如果 PartKeepr 确实使用了自己的框架，那么即使对于最基本的功能，您也将非常依赖自己。 我最近将 The Bug Genie 视为问题跟踪器，它根本不使用框架 - 一切都是自己编写的。 我提交了不少于 8 个 pull request 来修复我在正常使用过程中遇到的错误。 在遇到了六个错误之后（我在一个月内只使用了该软件大约 30 分钟），我停止使用它。

我认为您可能是回答为什么这个项目几乎没有开发支持的最佳人选。 如果它是可修复的。

我只能猜测：相对较小的用户群，我确实满足了太多的功能请求。 对于大多数用户来说，它确实是开箱即用的，那么为什么这些用户会开始贡献代码呢？

我问自己的问题是：我喜欢参与一个共享项目吗？ 它会从我的经验中受益吗？ 是否有更多人分享我的目标？ 开发人员之间的交互会是什么样子。

除非您愿意学习软件项目和底层技术的工作原理，否则不会太多。 加紧抱怨框架的选择是非常糟糕的第一步。

我不会参与本项目的任何项目或开发协调。

我目前正在尝试更新到 symfony 3.4。 如果我取得一些进展，我会提供更新

嗨@JelleDijkhuizen
你有关于 symfony 3.x 迁移的任何消息吗？ 如果您在这方面做过任何工作，请告诉我在哪里可以找到您的叉子？ 提前致谢！

@martonmiklos ，看起来@adlerweb正在尝试将 PartKeepr 升级到他分支的专用分支中的 Symphony 4 ...... :-)

@ZupoLlask感谢您的

我认为这次讨论很冗长，主要问题已经解决。 见#1059。 所以，我现在将关闭它。