1. I can see a use for being able to select Draft items. Especially if it's something like related news stories. You might not be ready for the story to go live yet. But once you do, and you publish it. You don't want to have to go adding it to anything it should be related to after the fact.
2. My gut reaction is that everything displayed should be consistent. Either the two items are related or they are not. No matter where you look, you should see the same data.
3. A categorical relationship would be great. It would be a welcome addition. However, I don't know that it's a must for phase I. I feel like it would be better to make sure the core product is working first before adding extra bells.
First, let me walk you through the latest version of the wireframes using a sample use case:
(wireframe: http://ezxjqv.axshare.com/?Page=Content_selector )
In a simple case, this is how related content will work.
However, there are some features on which we are deciding on and will need your opinion:
Our initial assumption was that users will be linking to items in order to display them on the site. Therefore, if a sessions is not published (i.e. draft) it would be confusing to allow to user to link to it, as this link will not show on the site. However, there are cases when users might want to relate to draft items. What is your opinion?
From this moment on, in Backend>Sessions I will start seeing all related presentations to a session. So, on the edit page of “session1” I will see all related presentations. But “presentation1” was already related to “session1” in step 5 above. So, do you expect to see “presentation1” as relate data for “session1”? What should happen if I detach “presentation1” from “session1”. Should that be reflected on the “presentation1” edit page as well?
We look forward to hearing from you!
And thanks for the valuable feedback. A quick follow-up is below:
On 1) Per your feedback, we have added the possibility to relate to item in any status (not just published).
On 2) When two items (X and Y) are related, the relationship b/n them will be visible from both sides. So, in the Backend, the edit page of X will show the link to Y, and the edit page of Y will show the link to X.
On 3) To handle the scenarios when one content type is related to another content type via more than one custom fields, we decided to store the name of the field as a parameter of the link.
Let me illustrate:
All relationships records will be stored in a table. For each relationship we will store the linked items and also the custom field via which they were related.
So, in the case above, we will make two records:
Thus, in the front end, when you are retrieving the related presenters for a given session, you will be able to specify whether you want to show the presenters associated via “main presenter” or the presenters associated via “supporting presenter”
Let me know if that makes sense.
Betty, on your question about hierarchical self-referencing relationships, in this iteration we will not cover this scenario, but it is on our list for next iterations. We will however, allow for self-referencing relationships that is flat. For example, for a given Product, user will be able to specify other related Products.
Steve, I confirm that deletions will be handled properly. Thanks for the note.
Thanks for your help and feedback. Let me know if you have other questions that we can address.
I would expect option 1 in most cases. Typically we setup structure etc when defining the English content then get translators to come through later and just edit individual content items, this means they don't need to understand how the site works and don't need to setup relationships. Massive time saver.
The only case I can think of where option 2 makes sense is where the data in the two different languages isn't a direct translation of the other - eg related contact details directing you to someone who can speak your language. So it could be useful, but not a massive time saver like option 1.
We are making a steady progress with the Related Content implementation, and we are planning to have a beta build including a preview in the coming weeks. Details will be announced.
I have one question to you in regards to multilingual support for relating content: When you relate an item which is translated to other languages, do you expect the relationship to extend to all translations of the item, or only to the current translation you are working with?
Let me illustrate with an Use Case:
1) I have a project with these languages: English (EN), German (DE), Spanish (ES)
2) I have custom content type “Presentations” with item: “prEN”, which is translated to “prES” and “prDE”
3) I have custom content type “Showcases”, with item “scEN” which is translated to “scES” and “scDE”
4) I relate “prEN” and to “scEN”.
5) Automatically, “prES” is related to “scES”, and “prDE” is related to “scDE”.
5) “prES” is not automatically related to “scES”, and “prDE” is not automatically related to
“scDE”. For each language, I need to relate the items separately.
In your practice, which of the scenarios makes more sense?
I look forward to receiving your feedback.
Betty, thanks for the feedback. That was very helpful.
We have a question on Relating to Pages. This seems to be a popular request and we are interested in collecting scenarios in how this feature will be used. Can you provide us with examples from your practice when a content item was linked to a Page. How were the linked Pages displayed on the public site?
Currently, there is workaround for achieving linking to Pages. You can add a custom field of type “Long text” to “News”. Users editing a news item will be able to insert links to pages via this field by using the HTML editor (in HTML users can insert links to pages). This will result in generating lists to pages on the news frontend. Can this work?
Thanks in advance for your feedback.
Sitefinity 7 goes in live. How can I implement this ability in custom types in custom module. For example, I'll try to implement SlideShow widget in custom module that will use are custom content types SlideShow (with fields Title, Description, PreviewImage, etc.) derived from Content class and SlideShowEntry (with fields Image, Description, etc.). Please, give me any related example project or sample code of field definitions for backend views or link to any related blog or other help information.