MJExtension
MJExtension copied to clipboard
CoderMJLee
mj_setKeyValues处理嵌套的子模型没有处理空数据
对于嵌套的模型,子节点下模型原来有值,赋值的数据中某些字段没有值,使用mj_setKeyValues赋值后,原来有值的字段因为被新数据直接覆盖,会出现空值
理想情况:子节点下新值为空,老值有数据,应该不覆盖沿用老值
具体情况可以看图中parent.name和child.testUrl
那遇到需要全部覆盖的要怎么处理 遇到一个需要覆盖, 另外一个不需要覆盖的又怎么处理
这里你应该自己实现, 而不是使用 mj_setKeysValues, 这个方法不应该这样用.
如果想自定义那么就自己实现一个.
那遇到需要全部覆盖的要怎么处理 遇到一个需要覆盖, 另外一个不需要覆盖的又怎么处理
这里你应该自己实现, 而不是使用
mj_setKeysValues, 这个方法不应该这样用. 如果想自定义那么就自己实现一个.
1.如果需要覆盖,为什么不用类方法初始化?你这个是实例方法,不就是用来改写对象属性吗?
2.退一步说, mj_setKeyValues按你的说法是会覆盖老值的,为什么在mj_setKeyValues:context:方法的mj_enumerateProperties回调中,要判断value值是否为空,为空直接return?覆盖不应该是判断新值为nil,把老值置nil吗?对应到issue中的截图,parent.name赋值后应该为nil才对.同一个方法,父子节点效果不一致
3.归根结底是在赋值操作时,采用KVC,对MJPropertyType不属于Foundation框架时没有单独进行判断,而是在父节点逻辑中判断子节点不属于Foundation,通过mj_objectWithKeyValues:context:直接alloc了一个新的子模型,把新的模型直接赋值,未考虑嵌套情况
在第二张图中对子节点模型类型进行判断,再走一遍mj_setKeyValues中的逻辑就能够达到这个目的
虽然这个是开源项目,难免有不那么完美的地方,但还是希望各位大佬能够好好维护,目前已替换为YYModel
直接close issue可能看起来好看,但是问题并没有解决,望共勉
- 首先, 这是一个内部方法, 对外的 API 为文档中描述的那些, 这个方法并没有在文档中提及, 你在不了解内部逻辑的情况下不应该使用.
- 再者, 你要使用内部方法, 那么内部方法是有其特殊实现逻辑的, 不是为其他通用逻辑而设定的
- 你是 Issue 的发起人, 你有权再开 Issue,
关闭它并不是可能看起来好看, 是因为觉得 "你利用你的聪明大脑, 使用了内部特殊方法, 达成了你要的特定目的, 而又在需求变化后, 不能实现你特殊目的来这里质疑内部方法是否有问题." 这个问题并不是 SDK 的问题, 而是你想要 SDK 的私有方法对外使用的问题.
这里再次声明下, 这个私有方法是针对新创建类(由公开 API 调用)进行的赋值方法, 并没有考虑到要给外部已经有值的类赋值这类情况, 你如果想要实现你的特殊逻辑, 建议你自己写一个公开方法.
千人千面, 各有需求, 不能为了你的一己需求修改逻辑. 试想今天你来要求这个需求, 明天他来要求那个需求, 那么到底要哪个需求?
-
是否对外API有无明确标明?如果不对外,放umbralle.h让外部调用?
-
同上,不知道为什么一样的问题你那聪明的大脑要写两遍
-
我不开issue是因为你解不解决这个问题我根本不在乎,来提issue是想让这个项目更加完善,为什么YYModel性能更高更兼容,可不是因为随意的文档和不规范的代码,乐于接受各种建议是拉开与这个项目的差距的原因之一
从你第一次回答就可以看出,这个项目的私有方法并没有那么私有,代码也没有那么规范,如果不想外部调用,请放好你的接口,完善你的文档和Readme,不要出了问题就说你怎么用这个方法,建议自己写一个公开方法(然而放眼望去就没有不公开的),似乎提一个完善文档和Readme的issue更加合适
最后,如果一个项目,今天你的需求能实现,明天他的需求也能兼容,这才是一个好项目