Related Documents and Cross Linking

Charles Matvchuk asked on September 3, 2014 20:52

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.

Recent Answers

Brenden Kehren answered on September 4, 2014 04:35

Just a comment on the custom form control which might help with some things. Why don't you use the UniSelector? You can set the properties on that to select page types and return your page list and desired fields.

Where is this linking happening? On the document itself? Or is this something that could be handled within a custom module? You can easily setup M:N relationships in modules now a lot easier than you could in v7 or earlier.

0 votesVote for this answer Mark as a Correct answer

Charles Matvchuk answered on September 4, 2014 06:05

Brenden, thanks for the input. Had a hard time getting the uni selector to work correctly, since I am storing NodeGUID which isn't part of Page Type. Also, for some reason it doesn't see my page type in the object field and throws errors, although if I use a standard class like cms.user it works correctly. Finally with respect to the UniSelector I have lookups that have 50,000 plus in them. The uniselector doesn't do well. I use Devexpress Controls within kentico and use their LookupGrid Which allows me to search all columns in the dropdown, and it loads the 50,000 records in about 1 second. I also have a more info in each grid row that people can click and a JavaScript window pops with more data about the row, etc.

With the linking the NodeGUID is saved in a field the Page Type (Document) and it is being selected in the form in Pages or via an alternate form in a contribution webpart or in the front end in place editing. I then resolve the NodeGUID in my transformation which calls a custom function ResolveSourceURL() and ResolveSourceURLPageName(), and then displayed within an anchor .

The down side to this, is it is only 1 way linking and if I delete the Page with the NodeGUID I saved than I have an issue. So then I need to create clean up code that when a document is deleted then I will have to scan all objects that can have a link and do some clean up on that field.

I really wanted to avoid creating a custom module. What I am attempting to do is to do dynamic internal linking (I have 400,000 pages which could be referenced in any page at anytime). Think Wikipedia linking but very simple with dropdowns that limit what can be linked.

There was an internal linking tool in the marketplace that I looked at a while ago, but the link is broken and cannot be downloaded anymore.

I am trying different things to see what I can come up with. I actually thought about parsing each document and then if a PageName is found then to create a link on the fly. Although I have never done that before and I wouldn't know where to begin. Also I am concerned about performance and load.

Any other ideas would be very much welcomed. Putting a lot of thought and prototyping into this one but with not great success.

0 votesVote for this answer Mark as a Correct answer

Charles Matvchuk answered on September 4, 2014 17:38

Anyone have any other suggestions or idea's ?

0 votesVote for this answer Mark as a Correct answer

Christian Nickel answered on October 20, 2014 22:47 (last edited on December 6, 2014 10:17)

Hi Charles,

This is probably a really late answer for you, but I found the answer to your #1 and #2 question on this page:

Essentially the relationship table uses the NodeIDs in the CMS_Tree table because the CMS_Tree contains only one record for each page and it's primary key is NodeID. The CMS_Document table may contain multiple records per page languages & versions.

I hope this helps!


0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.