Relations are not 'wired-up' between pickers that use the same bidirection relation type and have Relations Only checked. The pickers are both DoNet Prefectch (also tried DotNet checkbox list).
"If the Save Format is set to Relations Only, this ensures no local value is stored on the item being edited, causing the picked keys to be loaded from the relations data - this enables pickers to be 'wired-up' such that changing a picker on one end will cause any corresponding pickers to 'update'."
I figured out the issue. In order to "wire-up", you must use the same exact datatype. It doesn't make sense if the content is same type. Since I'm using a custom datasource, I can check the context's contentTypeAlias to pull different content for the lists.
I'd recommend removing the restrictions on requiring to use the exact same datatype, should just work regardless if they us the same relation type.
Hey Daniel, how did you access the context within the custom DotNet datasource? I need to read the "propertyAlias" value to determine the content for the lists
Vince, with the lastest nuPicker update, the context id is passed into the GetDataEditorItems() method. If you haven't updated, you can get the context id from the querystring in the request.
I guess you are refering to this issue - I'm wondering if that restriction is even needed at all, perhaps it's best to just remove it and not bother with a config option ?
Relations not working with IDotNetDataSource based pickers
Relations are not 'wired-up' between pickers that use the same bidirection relation type and have Relations Only checked. The pickers are both DoNet Prefectch (also tried DotNet checkbox list).
According the documentation (https://github.com/uComponents/nuPickers/wiki/Relation-Mapping)
"If the Save Format is set to Relations Only, this ensures no local value is stored on the item being edited, causing the picked keys to be loaded from the relations data - this enables pickers to be 'wired-up' such that changing a picker on one end will cause any corresponding pickers to 'update'."
What am I missing?
I figured out the issue. In order to "wire-up", you must use the same exact datatype. It doesn't make sense if the content is same type. Since I'm using a custom datasource, I can check the context's contentTypeAlias to pull different content for the lists.
I'd recommend removing the restrictions on requiring to use the exact same datatype, should just work regardless if they us the same relation type.
Hey Daniel, how did you access the context within the custom DotNet datasource? I need to read the "propertyAlias" value to determine the content for the lists
Vince, with the lastest nuPicker update, the context id is passed into the GetDataEditorItems() method. If you haven't updated, you can get the context id from the querystring in the request.
Cheers mate
Hi Daniel,
I guess you are refering to this issue - I'm wondering if that restriction is even needed at all, perhaps it's best to just remove it and not bother with a config option ?
Thanks,
Hendy
is working on a reply...