I'm working on a relations package/solution to create a 1:1 relationships system. I'm using Hendy's MultipickerRelations as a base and modding to suit. The special thing about this solution is that the relationships are shown from both ends.
here's how it works...Set relations on node A to node B. Navigate to node B and see node A selected for a given relationship category in the MNTP.
My problem is I'd like to change the selected nodes inside the integrated Multi-node Tree Picker (MNTP) when a page is loaded inside umbraco from what is selected in the content database to show the selected relations data instead.
For example, rather than showing what was selected using the MNTP, I'd rather show selected nodes based on a CSV (1108,1298,1474).
I want to know if I can access the integrated tree and change what it shows for a given alias. Possible??
My rough method would be as follows...
1. When document loads, if MultipickerRelations present, it checks to see if it's tied to an MNTP.
2. If relations are set, then force MNTP to show selected nodes from the relations table.
If all this works I promise to OS it :) I have an older version working beautifully and the client loves it, but it required re-writing parts of the uComponents MNTP. Seeing as the MNTP now exists in the core - I don't want to have to re-write umbraco to make this package work. Ultimately I'd rather do the whole lot with standard kit and just a couple of action handlers.
I've looked through that post - it's a good backup plan, but I'm still looking for plan A which is to force the return relations to show in the tree picker whislt on the return node.
As you're probably aware, that blog post explains a similar idea in terms of enhancing the content editors experience, but avoids all the complexity that would come about from using 'two way setters'.
My initial thoughts would be when changing node A and relating it to node B, then how would the property alias that should be updated on node B be identified (and should B then be saved / published - and what if there are other changes to B that aren't ready to be published) ? To counter this, your suggestion of updating the picker on node B only when it's loaded into view to be edited would work (as you say, could customise the MNTP to read from relations, or create another datatype placed on node B to see if the MNTP is in sync, and if not, update it's value and cause a save, or maybe update the MTNP hidden field and then trigger the MNTP to re-render (but that's a bit hacky!)) Either way, the data saved on node B is potentially out of sync with the relations data, so you'd have to ensure that any usage of these datatypes on the front-end would have to use the relations data (which is potentially slower than property values stored by a datatype (1 database hit v querying the xml cache)).
To enable two way setters, how about a new picker datatype that doesn't store data in the xml, but just uses the relations data alone, so avoiding all the complexity of having the same data stored in 3 places ? or even if one of the pickers didn't store it's own data ?
Sorry if this reply seems a bit negative, but I think it's a really tricky problem to solve !
I think the conundrum over which set of data to show and whether or not to save/save&pub the reverse node is where the true problems lie. You wouldn't want the reverse node to automatically be published.
The older solution I have forced the MNTP to show the relations data only. That worked a treat but required a custom build of uComponents to handle it.
I like the idea of creating a custom datatype specifically for 2 way 1:1 relations that hooks into the existing relations system. Could even be an OS package at the end of development. I'll start with a simplified MNTP and take it from there. Will keep you posted.
Unfortunately this problem won't go away - I have a live project relying on it. Nothing like a little pressure to get the creative juices going!
I'm making good progress - I've copied out the integrated MNTP from 4.11 and defined it as a new datatype with some extra preval fields to tie it to a relations set. Nearly done. I'll send you a copy when it's done.
Looks like the right way to go. Then to install will be a doddle :)
Just a quick update to anybody that's interested. I've cracked the 2-way relations MNTP datatype. Project on it's way. Lots of testing still to do but results so far are great. Happy Wednesday!
Relations tied to integrated MNTP - uComponents Tree help needed
Hi all,
I'm working on a relations package/solution to create a 1:1 relationships system. I'm using Hendy's MultipickerRelations as a base and modding to suit. The special thing about this solution is that the relationships are shown from both ends.
here's how it works...Set relations on node A to node B. Navigate to node B and see node A selected for a given relationship category in the MNTP.
My problem is I'd like to change the selected nodes inside the integrated Multi-node Tree Picker (MNTP) when a page is loaded inside umbraco from what is selected in the content database to show the selected relations data instead.
For example, rather than showing what was selected using the MNTP, I'd rather show selected nodes based on a CSV (1108,1298,1474).
I want to know if I can access the integrated tree and change what it shows for a given alias. Possible??
My rough method would be as follows...
1. When document loads, if MultipickerRelations present, it checks to see if it's tied to an MNTP.
2. If relations are set, then force MNTP to show selected nodes from the relations table.
If all this works I promise to OS it :) I have an older version working beautifully and the client loves it, but it required re-writing parts of the uComponents MNTP. Seeing as the MNTP now exists in the core - I don't want to have to re-write umbraco to make this package work. Ultimately I'd rather do the whole lot with standard kit and just a couple of action handlers.
Thanks
Neil
Is this blog post what you're looking for? http://24days.in/umbraco/2012/who-picked-this/
Jeroen
Thanks Jeroen,
I've looked through that post - it's a good backup plan, but I'm still looking for plan A which is to force the return relations to show in the tree picker whislt on the return node.
I'll keep looking - and thanks for your time.
Neil
Hi Neil,
As you're probably aware, that blog post explains a similar idea in terms of enhancing the content editors experience, but avoids all the complexity that would come about from using 'two way setters'.
My initial thoughts would be when changing node A and relating it to node B, then how would the property alias that should be updated on node B be identified (and should B then be saved / published - and what if there are other changes to B that aren't ready to be published) ? To counter this, your suggestion of updating the picker on node B only when it's loaded into view to be edited would work (as you say, could customise the MNTP to read from relations, or create another datatype placed on node B to see if the MNTP is in sync, and if not, update it's value and cause a save, or maybe update the MTNP hidden field and then trigger the MNTP to re-render (but that's a bit hacky!)) Either way, the data saved on node B is potentially out of sync with the relations data, so you'd have to ensure that any usage of these datatypes on the front-end would have to use the relations data (which is potentially slower than property values stored by a datatype (1 database hit v querying the xml cache)).
To enable two way setters, how about a new picker datatype that doesn't store data in the xml, but just uses the relations data alone, so avoiding all the complexity of having the same data stored in 3 places ? or even if one of the pickers didn't store it's own data ?
Sorry if this reply seems a bit negative, but I think it's a really tricky problem to solve !
Hendy
Hi Hendy,
Thanks for getting back to me.
I think the conundrum over which set of data to show and whether or not to save/save&pub the reverse node is where the true problems lie. You wouldn't want the reverse node to automatically be published.
The older solution I have forced the MNTP to show the relations data only. That worked a treat but required a custom build of uComponents to handle it.
I like the idea of creating a custom datatype specifically for 2 way 1:1 relations that hooks into the existing relations system. Could even be an OS package at the end of development. I'll start with a simplified MNTP and take it from there. Will keep you posted.
Unfortunately this problem won't go away - I have a live project relying on it. Nothing like a little pressure to get the creative juices going!
Neil
Hi Hendy,
I'm making good progress - I've copied out the integrated MNTP from 4.11 and defined it as a new datatype with some extra preval fields to tie it to a relations set. Nearly done. I'll send you a copy when it's done.
Looks like the right way to go. Then to install will be a doddle :)
Neil
Just a quick update to anybody that's interested. I've cracked the 2-way relations MNTP datatype. Project on it's way. Lots of testing still to do but results so far are great. Happy Wednesday!
Neil
is working on a reply...