In the project we are working on, we have a lot of cross linking between pages and other pages. I have created my own Form Control to link a page. I use this for linking a single page. What it does is store the NodeGUID in the text field of the page I select. I know you have the page selector, but to be quite honest that it to much for some people to keep traversing the content tree. My control is a drop down box that accepts properties of PageType so that I can limit the drop down box data to a specific PageType. This is perfect since it is used in a Wiki Fashion where by end users and the general public can select the page from a list which keeps my page linking intact without them having to see or traverse my content tree. In my transformation then I handle the NodeGUID and show a link with the page name. This works out great.
For example:
Habitat: North America
Diet: Herbs
So you get the idea, "North America" and "Herbs" are their own Page Types(Document Types) and they are populated from a drop down box that is fast and unobtrusive, rather than using the Page Selector and browsing the content tree. The NodeGUID of the page is then saved in a text field within the document.
1) I am under the impression that I should be using the NodeGUID rather than the DocumentID or NodeID, since the NodeGUID is stable. Is this correct ???
The second part to my question is that Now I have a requirement to create a related documents feature. I can do this by using the related documents control and features. The problem though exists is that I do not want the users browsing the Content Tree so I am going to have create another custom drop down control which populates the CMS_Relationship Table. In reviewing the CMS_Relationship Table I notice that It stores the NodeID on the left and the right. Referring to question 1, above,
2) Why is it not storing the NodeGUID which is supposed to be stable ??? instead. Did I miss something ?
3) Do you have a full API reference for the Relationship feature so that I can write custom code to insert the relationship from my code and create a custom control ? Or should I just insert the NodeID's and the RelationshipNameID from a SQL Statement from the code behind on my Custom Form Control, which is easy ?
4) I could create my own table and insert the NodeGUID's in a Many to Many relationship, but then I would have create lists and viewers either from scratch or through inheritance and some heavy modificaions, which I do not really want to do. I try to utilize as much integrated components (out of the box) that I can so that I don't have issues on upgrades and new versions. Thoughts?
5) Another thought came to mind, in example 1 at the top, instead of storing the NodeGUID and resolving the document name and URL, do not allow the system to create a duplicate Document Name anywhere (not sure if this is possible) and to just save the DocumentName in the text field and to Resolve the document name in the transformation with just some custom code ? Please note that I have over 300 Page Types (Document Types) and 408,000 pages in the system and its growing everyday. This would be great since when we import data through the import utility we wouldn't first have to run queries on the data being imported to turn their fields that need to be linked to a page into a NodeGUID first.
Any thoughts would greatly be appreciated.