作为开发人员和用户，我仍然是Expression Engine的新手。我面临的问题是，我的很多知识都是由用户传递给我的，这些用户已经找到了通过使用渠道系统完成传统上由开发人员（例如产品库）承担的任务的方法。
我想知道的是，当最好建议客户使用这个以及何时不使用时，人们的意见是什么。
让我举一个例子，一个客户想要一个有可能发生事件的场所的系统。之前的开发人员选择使用会员系统作为场地和会话系统的事件，并编写一些自定义代码，试图将两者编织在一起，特别是因为没有足够的钩子来完成一些后台自动化任务，如查找创建或更新场地地址的长/纬。
我正在接受其他人的工作，但这不是他们的错，而是他们给出的信息，因为他们也是系统的新手。
在任何其他项目中，这将是主要细节类型设置，事件属于场地，我可能会编写2个自定义表格，管理区域中的编辑器通过模块，然后在页面中使用常规自定义代码进行显示和根据信息采取行动 - 这样，我可以控制用户点击提交时发生的事情。
然而，煽动方是Expression Engine的资深用户，并以“哦，只是把它全部放在频道中，然后是这个标签和那个标签等等”的方式指示前一位开发人员。
所以，我是否错过了这一点，或者我是对的，这不适合频道系统，何时应该使用频道，什么时候不使用？
谢谢朋友们。
答案 0 :(得分：0)
这个问题非常假设，每个开发人员都会给你一个不同的答案，因为这完全取决于需求以及EE开发人员如何推动。
从根本上说，ExpressionEngine允许你以多种方式接近构建，没有一个是对与错，虽然有些更容易，有些更难，有些只是简单的愚蠢。
基本上，频道是数据“条目”组 - 这些可以是任何东西。使用您的示例，场地可以是一个频道，其中创建的字段与主题相关（例如位置，大小，价格等）。另一个具有不同字段的事件的频道（例如日期，类型，位置）。
大多数情况下，任何东西都可以插入频道。但是成员详细信息最好保留在本机成员功能中（尽管有一个商业附加组件可以在通道中保存成员数据）。
您可以参考之前的开发人员方法 - 这可能是因为他们使用了第三方加载项，要求将数据分别保存到渠道，或者缺乏对最佳方法的理解。或者只是因为开发人员决定以这种方式接近它！我怀疑最后的开发者然后将一个成员（场地）与一个条目（事件）相关联，以将事件链接到场地。基本EE功能允许相关条目允许您将1个条目与另一个条目（例如Event - ＆gt; Venue）相关联，或者使用优秀的Playa附加组件，因此这种方法实际上不是必需的。
我个人总是将数据存储在渠道中，以及本地会员功能中的人/成员（例如管理员，网站访问者，客户等）。我只构建一个附加组件（利用它自己的表/数据）来存储额外的信息，如果它超出EE可以存储的范围。
答案 1 :(得分：0)
回答你的实际问题（它正在扩展what Stack Overflow questions are supposed be诚实的范围）：你应该为场地和频道使用频道进行事件，而事件条目中的场地字段是一个“相关条目”字段类型链接到场地频道。这是“标准”EE方式，与传统数据库模式最相似。