############### 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组件 ################