Multipicker tree synchronize with MultiPicker Relations
Hi,
I am using ucomponents Multipicker tree with ucomponents Multipicker relations to create bidirectional relationships between products. It's all working fine but I want to know if there is someway both can be synchronized?
For example:
I create a relationship between Product A and Product B which is bidirectional, it is all fine when I retrieve on a webpage but when I go to Product B through CMS and check Multipicker tree, there isn't any relation created whereas Its always there on Product A.
I know Multipicker tree uses CSV whereas Multipicker relations save in database tables, but can anyone guide me how to achieve this task?
Currently the suggestion is that you would need to write a custom action/event handler to do the "hooking-up" between MNTP and the relations table.
We haven't got any plans to add this kind of functionality into uComponents for v2.1 (due for release early next week) ... but could be considered for v3.0?
I think the thinking was that the action/event handler to update the related multipicker values could be a part of the MultiPicker Relations (MPR) datatype... it would mean that the MPR would need to be aware of each of the multipickers formats, could do with a little more thinking / discussion on how best to handle this...
I'll put a fix in so that bidirectional relations can be updated by either multipicker (at the moment relations are marked in the comment field by the instance of the MPR to prevent other MPRs from editing these values - the opposite to what you want!) am wondering if a checkbox to toggle marking would be useful, or to remove them completely ?
I first created a bidirectional relationship from Product A between A and B. That worked fine.
But when I went to Product B and created another relation between B and C, the original relationship between B and A was lost and deleted from Relations table.
I think it would have been ideal if Multinode Tree Picker would work bidirectional without need of these complexities. Its becoming very difficult to use if the relations exists in database but when through CMS you access related products, you dont see original referencing products.
I am quite new to umbraco, it would be great if someone can help me regarding custom action/event handler to do the "hooking-up" between MNTP and the relations table as advised in earlier post?
Hi all - still having problems with this. It's more complex than I thought.
Plan A
I've tried using the MPR action handler to add the selected nodeId's from the MNTP to the node data element at the other end of the relationship. This seemed to kind of work, though I had to make it quite bespoke with my docType aliases & data element aliases. So once saved the other end of the relationship did show the correct relationship.
i.e. Add a relationship to product B in product A. Go to product B and product A was showing as selected in MNTP - cool.
So far so good until some of the relationships started disappearing - I'm assuming that there's another action going on somewhere that is causing this - I could probably find it with some digging, but there are two bigger problems.
1. Once the relationship has been added, my system essentially adds the extra item to the correct data element in the opposing end of the relationship. This then has to be saved/published or the change will be lost. So if I save it I get stuck in a never ending loop - v-bad - or if I publish only the related node it means any unsaved changes on that node would be immediately promoted to live - also v-bad.
2. If I want to remove the relation to product B from product A (or visa versa) then there needs to be a delete function. The delete function is particularly difficult because once deleted from product A, there is no way of finding what was deleted without doing a compare between the two. Not too bad on one related item, but I have 6 kinds of related data per page with hundreds of pages. Cycling through all data elements on all nodes that could be related is a nightmare and not very efficient on a large site.
My conclusion from this bit of R&D is that trying to persist the relations by copying their values into normal umbraco data elements for related content is a bad idea. Plus the work is very bespoke for any particular site and requires re-compilation of uComponents.
Plan B - try and get the MNTP to show selected items directly from the relations table.
Initial thoughts...
1. Add a pre-value checkbox to the mntp to tell it to show it's selected items directly from the relations table instead of a data element in a node.
2. Probably need a relation type alias pre-value too unless the MPR can handle this bit.
Off to have a think about this one.
I also posted this on Codeplex. I hope I've not bored you to death with this, but I thought I should share my findings.
I think I've cracked it. I have two way relations working via MNTP using the relations DB.
I've added a few bits to the MNTP to tie it to a relation type alias and to read it's selected nodes directly from the "umbracoRelationType" table in the db - but that's just bumf really.
The cool bit is an extra method in the "MultiPickerRelationsEventHandler.cs" class that catches the relation that has just been made and creates the opposite end of the relationship as if it were saving from the related node. I think Hendy can be thanked for pointing me in the right direction.
It goes a little something like this...
private void CreateDataRelationForOpposingNode(int currentNodeId, int relatedNodeId, string instanceIdentifier) { string aliasRelatedNodeToUpdate = ""; umbraco.cms.businesslogic.web.Document currentNode = new umbraco.cms.businesslogic.web.Document(currentNodeId); umbraco.cms.businesslogic.web.Document relatedNode = new umbraco.cms.businesslogic.web.Document(relatedNodeId); string nodeTypeCurrent = currentNode.ContentType.Alias; string nodeTypeRelated = relatedNode.ContentType.Alias; switch (nodeTypeCurrent) { case "ListedDivision": aliasRelatedNodeToUpdate = "relatedDivisions"; break; case "ListedLocation": aliasRelatedNodeToUpdate = "relatedLocations"; break; case "ListedPeopleProfile": aliasRelatedNodeToUpdate = "relatedPeople"; break; case "ListedPortfolio": aliasRelatedNodeToUpdate = "relatedPortfolios"; break; case "ListedPressRelease": aliasRelatedNodeToUpdate = "relatedPressReleases"; break; case "ListedSector": aliasRelatedNodeToUpdate = "relatedSectors"; break; } RelationType relationType = RelationType.GetByAlias(aliasRelatedNodeToUpdate); CreateRelation(relationType, relatedNodeId, currentNodeId, false, instanceIdentifier);
}
And is called from just after Hendy's call to create the relation
foreach (KeyValuePair<int, string> pickerNode in pickerNodes) { CreateRelation(relationType, sender.Id, pickerNode.Key, options.ReverseIndexing, instanceIdentifier); // TODO: Add in here a tie up to add the value into the right area for the node being saved //added NT 08-03-2011 CreateDataRelationForOpposingNode(sender.Id, pickerNode.Key, instanceIdentifier); }
It's not perfect yet, as you can see by my code it has to understand which nodeTypeAlias's it has to work with - which is not ideal. I'd like it to parse the content tree to find matches rather than naming NodeTypeAlias's.
But it's a start, and it gets me out of a hole. The updates to the MNTP to make it read from the relations table are pretty sorted but too extensive to put down here. Hendy - we need to talk :)
As I am quite new to umbrac, I don't understand how to implement these changes intro my MNTP control. I don't have access to code. Can you please send me an updated ucomponents with these changes? or let me know how I can implement these changes? Certainly it would be a help for beginners.
OK I have managed to download source code for ucomponents and also found the class MultiPickerRelationsEventHandler.cs and added your code. Can you help me how should I compile it and make it into a form which I can then import in umbraco?
I am also confused why do we have branches, tags and trunk folders? All of them are having this file.
It would be really good if someone can post a step by step guide on how to update datatypes and compile and save them for using in umbraco.
Hi Wagar, I can't comment on Neil's code changes to MNTP - I haven't tried or tested them - so you're on your own in terms of support.
As for your branches/tags/trunk question with the uComponents source. Its up to you which version you want to use... latest development version (for upcoming v2.1 release) is in the /branches/v2.0 folder. The /tags contain the snapshot of when we released that specific version ... and the /trunk is the last stable release (v2.0.1)
The choice is yours! :-) I'd suggest compiling from the /branches/v2.0 folder ... as its pretty much stable now!
Hi Wagar, if you can hold fire on this for a couple of days we might be able to get a more tried and tested release to the relations dilema. As I said, my code isn't perfect, and Friday's testing showed some gremlins when working bidirectionally. More work will be done on it this week - we're going in the right direction but it needs polishing. It's very much a WIP.
As for your other comments - compiling and adding your own code to umbraco isn't difficult, but requires a little knowledge of .net. If you can stomach it, I'd get a begginers book on c# and learn the basics & how things fit together before modifying the umbraco systems. Adding your code to umbraco is easy - just add your compiled dll to the bin folder. Be warned though - it's a very powerful system and can break a lot of things. Once you know the basics, the umbraco level 2 course is excellent.
Relations are notoriously difficult, but you're welcome to whatever code I end up with.
As a sort of compromise, this post - who picked this ? describes how to link back to the picker from a picked node, so instead of two pickers working in opposite directions and then having to manage the syncronisation of property data on the remote node, this is a simplier setup, but also offers an enhanced content editor experience.
Is Niel's code is available somewhere? I would like to check it out and help move this idea further by involving in its development.
IMHO umbraco bidirectional relation lose a lot without this usage. Working with relations in code is cool, but main actions must be available from admin panel.
I'm guessing you've found the package Neil wrote: uRelate (source here) which is a customised MNTP with two way relations ?
Would be great to solve the problem of two way relations with other pickers - if you're interested, for v7 in nuComponents we currently have all pickers able to map to a relation type, but not update remote pickers. Current thinking is that the pickers wouldn't store any local data, but just use relations; PropertyEditorValueConverters for a picker could ensure the data is taken from the appropriate place. I know Jeavon and Neil have some ideas on this...
yeah, saw uRelate some time ago, but didn't check source code. The only show stopper with this package is that it does not seem to be supported in v7, which I plan to upgrade to in near future.
I will definitely check nuComponents, it would be great to have this functionality on v7.
The latest nuComponents source now supports two-way relations, where pickers can be used at both ends - they communicate by retrieving and storing their values using relations data only (no local values are stored). To configure: select a Bidirectional Relation Type for the mapping, and then set the Save Format to 'Relations Only'.
Any feedback on how to improve or simplify this very welcome :)
Multipicker tree synchronize with MultiPicker Relations
Hi,
I am using ucomponents Multipicker tree with ucomponents Multipicker relations to create bidirectional relationships between products. It's all working fine but I want to know if there is someway both can be synchronized?
For example:
I create a relationship between Product A and Product B which is bidirectional, it is all fine when I retrieve on a webpage but when I go to Product B through CMS and check Multipicker tree, there isn't any relation created whereas Its always there on Product A.
I know Multipicker tree uses CSV whereas Multipicker relations save in database tables, but can anyone guide me how to achieve this task?
Regards,
Waqar Zafar
Hi Waqar,
There's a discussion over on the uComponents CodePlex site at the moment...
http://ucomponents.codeplex.com/discussions/247996
Currently the suggestion is that you would need to write a custom action/event handler to do the "hooking-up" between MNTP and the relations table.
We haven't got any plans to add this kind of functionality into uComponents for v2.1 (due for release early next week) ... but could be considered for v3.0?
Cheers, Lee.
Hi,
I think the thinking was that the action/event handler to update the related multipicker values could be a part of the MultiPicker Relations (MPR) datatype... it would mean that the MPR would need to be aware of each of the multipickers formats, could do with a little more thinking / discussion on how best to handle this...
I'll put a fix in so that bidirectional relations can be updated by either multipicker (at the moment relations are marked in the comment field by the instance of the MPR to prevent other MPRs from editing these values - the opposite to what you want!) am wondering if a checkbox to toggle marking would be useful, or to remove them completely ?
Cheers,
Hendy
The other issue I had with MPR is:
I have Product A, Product B, Product C.
I first created a bidirectional relationship from Product A between A and B. That worked fine.
But when I went to Product B and created another relation between B and C, the original relationship between B and A was lost and deleted from Relations table.
I think it would have been ideal if Multinode Tree Picker would work bidirectional without need of these complexities. Its becoming very difficult to use if the relations exists in database but when through CMS you access related products, you dont see original referencing products.
I am quite new to umbraco, it would be great if someone can help me regarding custom action/event handler to do the "hooking-up" between MNTP and the relations table as advised in earlier post?
Hi all - still having problems with this. It's more complex than I thought.
Plan A
I've tried using the MPR action handler to add the selected nodeId's from the MNTP to the node data element at the other end of the relationship. This seemed to kind of work, though I had to make it quite bespoke with my docType aliases & data element aliases. So once saved the other end of the relationship did show the correct relationship.
i.e. Add a relationship to product B in product A. Go to product B and product A was showing as selected in MNTP - cool.
So far so good until some of the relationships started disappearing - I'm assuming that there's another action going on somewhere that is causing this - I could probably find it with some digging, but there are two bigger problems.
1. Once the relationship has been added, my system essentially adds the extra item to the correct data element in the opposing end of the relationship. This then has to be saved/published or the change will be lost. So if I save it I get stuck in a never ending loop - v-bad - or if I publish only the related node it means any unsaved changes on that node would be immediately promoted to live - also v-bad.
2. If I want to remove the relation to product B from product A (or visa versa) then there needs to be a delete function. The delete function is particularly difficult because once deleted from product A, there is no way of finding what was deleted without doing a compare between the two. Not too bad on one related item, but I have 6 kinds of related data per page with hundreds of pages. Cycling through all data elements on all nodes that could be related is a nightmare and not very efficient on a large site.
My conclusion from this bit of R&D is that trying to persist the relations by copying their values into normal umbraco data elements for related content is a bad idea. Plus the work is very bespoke for any particular site and requires re-compilation of uComponents.
Plan B - try and get the MNTP to show selected items directly from the relations table.
Initial thoughts...
1. Add a pre-value checkbox to the mntp to tell it to show it's selected items directly from the relations table instead of a data element in a node.
2. Probably need a relation type alias pre-value too unless the MPR can handle this bit.
Off to have a think about this one.
I also posted this on Codeplex. I hope I've not bored you to death with this, but I thought I should share my findings.
Neil
I think I've cracked it. I have two way relations working via MNTP using the relations DB.
I've added a few bits to the MNTP to tie it to a relation type alias and to read it's selected nodes directly from the "umbracoRelationType" table in the db - but that's just bumf really.
The cool bit is an extra method in the "MultiPickerRelationsEventHandler.cs" class that catches the relation that has just been made and creates the opposite end of the relationship as if it were saving from the related node. I think Hendy can be thanked for pointing me in the right direction.
It goes a little something like this...
And is called from just after Hendy's call to create the relation
It's not perfect yet, as you can see by my code it has to understand which nodeTypeAlias's it has to work with - which is not ideal. I'd like it to parse the content tree to find matches rather than naming NodeTypeAlias's.
But it's a start, and it gets me out of a hole. The updates to the MNTP to make it read from the relations table are pretty sorted but too extensive to put down here. Hendy - we need to talk :)
Neil
Hi Neil,
As I am quite new to umbrac, I don't understand how to implement these changes intro my MNTP control. I don't have access to code. Can you please send me an updated ucomponents with these changes? or let me know how I can implement these changes? Certainly it would be a help for beginners.
OK I have managed to download source code for ucomponents and also found the class MultiPickerRelationsEventHandler.cs and added your code. Can you help me how should I compile it and make it into a form which I can then import in umbraco?
I am also confused why do we have branches, tags and trunk folders? All of them are having this file.
It would be really good if someone can post a step by step guide on how to update datatypes and compile and save them for using in umbraco.
Thanks
Hi Wagar, I can't comment on Neil's code changes to MNTP - I haven't tried or tested them - so you're on your own in terms of support.
As for your branches/tags/trunk question with the uComponents source. Its up to you which version you want to use... latest development version (for upcoming v2.1 release) is in the /branches/v2.0 folder. The /tags contain the snapshot of when we released that specific version ... and the /trunk is the last stable release (v2.0.1)
The choice is yours! :-) I'd suggest compiling from the /branches/v2.0 folder ... as its pretty much stable now!
Cheers, Lee.
Hi Wagar, if you can hold fire on this for a couple of days we might be able to get a more tried and tested release to the relations dilema. As I said, my code isn't perfect, and Friday's testing showed some gremlins when working bidirectionally. More work will be done on it this week - we're going in the right direction but it needs polishing. It's very much a WIP.
As for your other comments - compiling and adding your own code to umbraco isn't difficult, but requires a little knowledge of .net. If you can stomach it, I'd get a begginers book on c# and learn the basics & how things fit together before modifying the umbraco systems. Adding your code to umbraco is easy - just add your compiled dll to the bin folder. Be warned though - it's a very powerful system and can break a lot of things. Once you know the basics, the umbraco level 2 course is excellent.
Relations are notoriously difficult, but you're welcome to whatever code I end up with.
Good luck
Neil
Was there ever a solution to this?
Hi Jørgen,
As a sort of compromise, this post - who picked this ? describes how to link back to the picker from a picked node, so instead of two pickers working in opposite directions and then having to manage the syncronisation of property data on the remote node, this is a simplier setup, but also offers an enhanced content editor experience.
HTH,
Hendy
Hi guys,
sorry for bringing old thread back but i have same requirement - having a bidirectionall relation edited with MNTP on both ends.
http://24days.in/umbraco/2012/who-picked-this/ is nice, but not full solution (you can only see list of related nodes and not edit them on the other end).
Is Niel's code is available somewhere? I would like to check it out and help move this idea further by involving in its development.
IMHO umbraco bidirectional relation lose a lot without this usage. Working with relations in code is cool, but main actions must be available from admin panel.
Hi Pavel,
I'm guessing you've found the package Neil wrote: uRelate (source here) which is a customised MNTP with two way relations ?
Would be great to solve the problem of two way relations with other pickers - if you're interested, for v7 in nuComponents we currently have all pickers able to map to a relation type, but not update remote pickers. Current thinking is that the pickers wouldn't store any local data, but just use relations; PropertyEditorValueConverters for a picker could ensure the data is taken from the appropriate place. I know Jeavon and Neil have some ideas on this...
Hi Hendy,
yeah, saw uRelate some time ago, but didn't check source code. The only show stopper with this package is that it does not seem to be supported in v7, which I plan to upgrade to in near future.
I will definitely check nuComponents, it would be great to have this functionality on v7.
Thanks!
Hi Pavel,
The latest nuComponents source now supports two-way relations, where pickers can be used at both ends - they communicate by retrieving and storing their values using relations data only (no local values are stored). To configure: select a Bidirectional Relation Type for the mapping, and then set the Save Format to 'Relations Only'.
Any feedback on how to improve or simplify this very welcome :)
HTH,
Hendy
is working on a reply...