Open orchardbot opened 11 years ago
@sebastienros commented:
Nice idea. To be discussed.
@jeffolmstead commented:
I am need of this solution so I have started coding. I have the User Interface all set up and the only thing (yes, major thing) I am lacking is a place to be the last implementation of the GetContentItemMetadata or some similar place to inject code, ensuring that the token (if provided) in the "Display Text" override is used.
Due to the dynamic nature of Orchard, I am not sure what event I can tap into that will be the last instance AND provide me access to the Content Item Metadata. Is there anywhere I can learn more? I am looking at the following interface:
IContentHandler
But if I go that route, I am fighting with the other ContentParts to GetContentItemMetadata so that doesn't work. Of course, I could inject my code right into the Content Handler:
IContentHandler.GetContentItemMetadata(GetContentItemMetadataContext context)
But then I would need to have Orchard.Framework dependent on Orchard.Core and that violates all standards (and likely would cause a circular reference and not work). So it needs to be driven off an Interface from Orchard.Framework - will need help here.
@jeffolmstead created: https://orchard.codeplex.com/workitem/19332
Stemming from a discussion here: http://orchard.codeplex.com/discussions/405035 the feature would be to address the (good) issue that more and more developers are utilizing Metadata.DisplayText. Unfortunately, there is not a priority mechanism to say which one wins (and there probably should not be one that the developer can choose since they don't really know what the end user would find to be the most valuable).
As an example of where the "issue" can happen: I added a Title onto the User part and the Username is still being returned (because both User and Title have a Metadata.DisplayText defined). In some instances I could see the username being the most important, in others, the Title. It just depends on the website (and more specifically) the Content Type.
With this in mind, the thought is to use the power of Tokens and add an additional paramater onto every content type representing the Default DisplayText. Using tokens would give full access to ALL of the Parts/Fields in the Content Type. In addition, if someone didn't provide a value, it sould just revert back to the use of Display Text as it does today (so there is still a value in the programmer setting up Display Text).
Does this seem a viable approach that could be integrated into the current Display Text? Do you see any performance issues using this approach?