############### stark组件 ################
""" 这个stark组件是非常神奇的 1，独立的一个组件 2，没有model 3，没有views """
############### stark组件 ################
""" stark组件站点类 这个是一个重点类，应该是研究这个组件的起点 做了几件事 1，模仿admin，利用了单例模式， 2，模仿admin，可以对每一个表进行注册 这一步参数就是模型类，视图类，传递过来， 3，模仿admin，可以做第一层的路由分发，利用了django自带的url模块 生成/app/model/，这种格式的url，这是启动程序就生成的， """
############### stark组件 ################
""" stark组件默认处理视图 这个非常重要，是核心 第一，返回列表页面，这是最为复杂的， 1，数据 2，表头 3，表内容 4，查询 5，过滤 6，action 7，分页 8，添加按钮
第二，添加页面
第三，编辑页面
第四，删除页面
这四个页面都保留了定制，可以自己指定模板
处理第二级的url，这才是拼接最终的url
"""
############### stark组件 ################
""" stark组件处理视图 1，每次处理视图都会校验权限，看是否有添加按钮，删除按钮，编辑按钮， 把这个封装起来，每一个视图类都继承这个权限类， 每一个视图类，都继承默认的视图， 所以这个地方用到了多继承的知识， 2，默认视图中每一个小的功能都封装成为一个函数， 在真正的处理视图类继承默认视图之后，重写这些函数，达到定制的功能， """
############### stark组件 ################
""" stark组件，option类 这个类用来处理筛选， 1，指定字段，这种一般就是一对多的字段，或者多对多的字段， 2，可以定制是否支持多选， """
############### stark组件 ################
""" 如何不用stark组件是如何开发的？ 1，我需要研究一下博客项目， 然后博客项目和crm项目比较就知道如何开发了， 使用stark组件和使用admin组件开发后台有什么优势？ 1，django 的 admin其本意是一个简易的数据生成工具， 主要用于项目初期阶段进行简单的数据管理，比较有局限性 如果业务复杂些，admin可能就没有办法实现了 最大的问题是很不灵活并且是难以定制。 包括页面定制 url扩展，页面扩展 菜单管理，权限管理， Django admin 一般是用来给超级管理员实现一些基础的增删查改的， 不建议给用户使用。但是目前项目中，有部分给用户使用的功能很类似 Django Admin 中的 ModelAdmin ， 也就是把 Model 中某 Field 列出来查看、修改、新增。 若是自己写 View 的话，比较重复，或者自行实现一个 ModelAdmin ？ 还是通过定制 Django admin 的 template 来实现较好？ 如果比较追求用户体验的话建议自己写， Django Admin 深度定制很麻烦， 自己写，不用自带的 admin ，开发前期可以用用。 给用户做是个巨坑，本来目的就是做个方便开发的后台原型，到后来你得 hack 很多东西，唯一的好处是吃透文档 如果给用户用，千万别用 admin ，现在我正在填坑，还被别人在身边墨迹。因为你写前端交互的 js 已经打了无数个 patch,一团乱糟糟的 问题是，我问到的每个人都持反对意见，他们认为 admin 只限于超级用户，很不灵活并且是难以定制。” —来自 Reddit 的 andybak 2，stark组件集成了bootstrap，更好的定制页面， 扩展url，扩展页面， 所有的功能，菜单，页面，都能他通过stark组件来集成进来， 这才是真正的后台，使用admin就没有这么好扩展，定制， 二者都是这样，开发curd重复工作而且麻烦，所以两者都可以节省curd的时间，专注于业务实现， 对xadmin来说，可能你能读懂他的源代码后，会觉得，嗯，也是不错的 """
############### stark组件 ################
############### stark组件 ################
############### stark组件 ################
############### stark组件 ################
############### stark组件 ################