autocomplete light配置xadmin使用时一记小坑

昨天又有一个同学反馈，跟着视频写代码，一样的代码，但是为啥我这的autocomplete light就不生效。第一个同学反馈我以为是autocomplete light的版本问题，再次有人反馈，那可能是哪不太对劲。

说句题外话，默认情况下的django admin或者是xadmin，在外键字段的渲染上都是一个坑。当外键的数量过大，那页面的加载速度真是“杠杠滴”。

出错现象

先说下版本：xadmin-0.6.1 autocomplete light-3.2.10

错误提示：

你要是搜的话多半能发现这是版本问题，但是你看了看autocomplete light里面用到select2是一个挺新的版本，而报错的这个版本是3.x的版本。

autocomplate light和xadmin都是用select2这个js库。

问题原因

其实稍微仔细点排查的话，会发现错误的这个js是xadmin加载的资源，而不是autocomplete light加载的资源。这看起来有点奇怪了，我这里没出问题，但是其他人那里一样的代码会出问题。

首先的原因可能就是我们的版本不一样。But，确认后发现版本一样。

那么就是另外的原因，有细微的差别。于是我看了下network里面js的加载顺序，我这里是先加载autocomplete light的select2的资源，然后再加载xadmin自己的。

而其他人那边刚好相反，所以问题在这。实话实说，这种远程口头指挥排错的方式确实很有局限性。因为我不确定对方的代码到底是怎么写的。即便是跟着我的视频写出来的。(虽然可以从github上copy源码，但我还是强烈推荐自己跟着视频敲，遇到的问题越多，经验才越丰富）。

课程中有讲过INSTALLED_APPS的顺序会导致同名资源的加载顺序，测试了下发现不是同名资源。那么就是另外的问题。

仔细思考下Django admin部分或者说xadmin的部分是如何渲染页面的，它怎么知道把Charfield渲染为Input标签，把TextField渲染为Textarea标签？另外这些标签所依赖的资源，比如css和js，是怎么组织的？

在Django的源码中，有这样的一个概念（:-) 我自己总结的）—— 自治。

什么是自治呢？通俗来说就是高内聚，翻译成大白话来说就是能自己搞定的事就别麻烦别人。所以从更大的粒度来看，Django项目的每个APP都应该是自治的，避免相互依赖。

继续说回到问题，我们知道Django的渲染出来的资源是依据这个model或者modelform定义的field中的widget，那么对于我们遇到的问题 —— js资源的加载顺序，原因就是字段的加载顺序。

在Django的源码中: django/forms/forms.py的BaseForm.media的代码能够查看field的组织顺序：

让出问题的同学在这加上两个print之后，能更好的发现问题。

解决方案

上面的fields的来源也是有点复杂，这里不过多展开，不过解决方案很简单，就是在form的Meta中自定义fields，像这样:

保证autocomplete light字段在其他的带choices配置的字段之前。不过，这样的解决方案会限制你页面的布局，比如你可能就像把那个字段放到autocomplete light的字段之前，怎么解决？

上面也说到了，INSTALLED_APPS的配置顺序会影响静态资源的加载顺序，所以，根据路径在你的app里面配置同样目录名称的资源，来进行覆盖。

总结

最终其实发现这个同学的form和adminx的代码跟我的一样，但是model中字段定义的顺序不同，所以导致这个问题。不过对于遇到这样问题的同学来说，如果能搞明白原因，是很有帮助的。

- from the5fire.com 

文章转载来自：

保证autocomplete light字段在其他的带choices配置的字段之前。不过，这样的解决方案会限制你页面的布局，比如你可能就像把那个字段放到autocomplete light的字段之前，怎么解决？

上面也说到了，INSTALLED_APPS的配置顺序会影响静态资源的加载顺序，所以，根据路径在你的app里面配置同样目录名称的资源，来进行覆盖。

总结

最终其实发现这个同学的form和adminx的代码跟我的一样，但是model中字段定义的顺序不同，所以导致这个问题。不过对于遇到这样问题的同学来说，如果能搞明白原因，是很有帮助的。

- from the5fire.com 

文章转自：https://www.the5fire.com/