使用内置的django admin进行一个规模合适的项目是否值得?

如果我理解正确,您希望对所有用户使用django管理,让他们更新站点。
如果这是真的,我想你可能会用不同于它的主要目的的方式使用它,正如你可以从 Django book (重点是我的):

对于特定类别的网站, 管理界面是必不可少的部分 基础设施。这是一个 基于Web的界面, 限于 受信任的站点管理员 ,那 启用添加、编辑和 删除网站内容。

如果您的用户需要更新内容(比如,比如,添加一篇新文章),那么可能没问题。
但是如果你想把它用于任何站点交互,那么我认为用户体验不会那么好。

我认为有一个很好的例子可以说明如何使用管理员,以及何时不应该使用它。 ReviewBoard :在那里,大多数用户操作都是由站点直接处理的,然后只有配置和管理是使用管理员来处理的。

最后,问题是 可用性 . 如果您认为您的应用程序可以有一个不同的部分来管理站点的添加,那么Django的管理站点可能是一个实时的节省程序。在所有其他情况下,也许最好多投资一段时间。

我的公司在Django的基础上构建了一个CMS,它可以处理许多任务(平面页面、博客、仅成员的部分、从YouTube和Flickr等外部网站导入和分析数据、邮件列表、专辑歌曲和艺术家歌词等),到目前为止,我们仍在使用内置的管理。我们有几个非常非技术性的客户经常使用它。

当您真正了解admin.py文件时,您可以用它进行定制。我们只添加了Tinymce和FileBrowser,以使最终用户更容易使用这些方面。

我会说我们正在开发一个画廊模块, 是 不过,需要一个定制的管理员。否则,我会很高兴,也会为Django的管理如此灵活和强大而印象深刻。而且它非常人性化。

这要看情况而定。管理员将允许您自定义相当多的内容,不同的用户组可以访问不同的表,如果您允许他们访问不同的管理界面,甚至可以为他们提供表上可用的不同列集。但是,管理员并没有真正设置为允许您根据用户的授权级别限制其行级访问。一旦您将它们放入一个表中,它们就可以对它们可用的任何对象进行更改。

您可以通过对小部件类型进行子类化来定制您喜欢的小部件(尽管内置过滤器_horizontal和raw_id_admin是必不可少的,并且对于某些数据类型来说,使此任务变得简单!)

所以我想这取决于你说的顾客是什么意思。如果你是指那些雇你来写网站的人(我想我会给他们打电话给客户而不是客户),那么管理员很有可能会很适合你。如果你是指网站的最终用户,我会坚持使用手工制作的django表单。

一般来说,我将django管理视为执行插入、删除和编辑等繁琐任务的界面。所以,我不害怕在很大程度上自定义它(即使这意味着子类化内部django对象并在运行时将其传递回管理界面),但要知道它将要求您读取django源代码(幸运的是,这并不难做到)。

因此,对我来说,使用它与否的区别在于“插入、删除、更新”与数据库表非常匹配的概念,而不是用户技术知识的数量、我信任用户的数量或项目大小。