@freakxx #47

错别字:
convert_gmt_to_local_time

covert -> convert

python

def covert_gmt_to_local_time(timezone, now=None)


函数直接写死的话，假如遇到上海，又得写一个，遇到广州又得写一个；

@shengchao #8

未免过于武断.


===========

可以考虑做一个计数器放在执行体里

65 = 13 * 5

做个 5 分钟的任务，

当 N % 13 = 0 执行

厄尔尼诺

@BingoXuan #6
习惯了 self 和 super 这一套后, 在 py 接受不来 this.

而且从设计来说，好的统一习惯总归是好的。

this 的指代是很不明确的，前几天还跟同事吐槽了以前一种很丑的 js 写法：
var that = this.

@fourstring
突然翻到这主题

这个是可以读写一致的，并且可以打开字段，

我之前写过几个版本的这玩意。

还写过递归的版本，反 Nested 存储到复层。


---------------

从源代码角度来说，serializer 也是一个 field，

你继承 PrimaryKeyRelatedField （ HyperlinkRelatedField ）后改写他的 to_internal_value 和 to_representation，就可以实现了你的需求。

字段调用大概长这样子
items = ObjectRelatedField(
...
serializer_class=ControlItemSerializer
)

实际上就是丢一个渲染的 serializer 进去 to_representation。

拆成 2 个部分

记录的话用信号机制，用 init 事先 copy （性能的话会有损耗）
搜索关键词 django signal field change
参考
https://stackoverflow.com/questions/36719566/identify-the-changed-fields-in-django-post-save-signal
https://stackoverflow.com/questions/1197674/actions-triggered-by-field-change-in-django


记录访问操作，考虑做一个中间件
流过 process request 或者 view request 做一下记录
搜索关键词 django middleware log
参考
https://djangosnippets.org/snippets/428/
https://stackoverflow.com/questions/862522/django-populate-user-id-when-saving-a-model/12977709#12977709

感觉可以试下这种方式

做一个 register decorator，然后可以指定 urlpatterns, 然后按照 path 的写法，在修饰器实现 path 注册。

然后类内部函数还是走 action 那套，或者同样实现的功能。

感觉整体会更漂亮一些。

@hollizhao #16

哈哈哈，作为 drf 吹，感觉还是要吹一波 django rest framework。

都玩过，当年也是狗书开始玩 flask。

主要看你最终要走哪方面。

----

django 这边好处就是结构清晰，你接受了它的理念，整个架构就挺清晰。
后面也可以从 django rest framework 直接走 web 开发，找工作也可以。

玩 flask 的话，我感觉中间会比较难受，也可能走偏，因为 flask 整体来说比较“散”，风格和结构可能走偏。
但好处就是，玩框架的乐趣在里面。

今年晚些时间再来买。

去年买过，质量挺好的，也挺好吃。

对于 django 来说，有一个很重要的东西叫，reusable。

app 的划分标准来说，也可以说是按照这个标准去做。

----

所以你可以有一个叫 auth 的 app 来包含 user，perms 和 groups。

也可以单独各自写 user，perms 和 groups。

----

> 因为我看 Django 的一个 Project 是一个 Website，而一个 Website 通常来说，是每个功能都要用到同一个数据库的，如果划分成 APP，岂不是要跨 APP 读取 Models 文件了？

这种情况，其实一个业务 app 就够了，如果你的业务不复杂的话。

如果再复杂一些，你可以建个 file app 专门做文件管理；
再做文章和活动的 app 单独管理不同的业务；

最后通过 user 来勾连起来不同的 model，如果有需要的话。

然后通过 config 的 urls 来勾连不同 app 的 url。

插个眼。

以前也想实现这么一个以字段为基础的，但一直没想到比较好的方式。

卫人嫁其子而教之曰：“必私积聚。为人妇而出，常也；成其居，幸也。”
其子因私积聚，其姑以为多私而出之，其子所以反者倍其所以嫁。其父不自罪于教子非也，而自知其益富。今人臣之处官者皆是类也。(《说林上》)

@ivydom #9

https://imgur.com/2atR83M

导航条这里的分类;
然后进到文档里的分类，感觉相对来说，sdk 和 api 和 quickstart 混在一起了？


我可能只是想看下有什么 api 我可以调用，不关注语言，这个时候很那找到一个 “ api 接口大全”字样的链接去查看；
然后当我要用 sdk 的时候，也没有一个比较好的参考；

---------------

| API 之类的你觉得还缺少哪些呢？

这个主要是关于接口设计，不过可能属于个人观点，不足参考；

api 我看到的是这个链接
graphql https://docs.authing.cn/authing/sdk/open-graphql
我感觉相对怎么说呢，这更像是 “联调”接口，可能需要把参数拆分更细些（从描述上），来让接口显示更简单一些；