DisplayText Priority

Topics: Core
Nov 29, 2012 at 3:49 PM

I have encountered a good problem, Metadata.DisplayText is working great and more people are using it (a good thing). The problem is priority it is applied. Right now, the UserPartHandler.cs has a DisplayText and the TitlePartHandler.cs has a DisplayText. Well, I have added a TitlePart to my User Content Type in order for a user to provide a "Title". My goal was to use the DisplayText property to retrieve their name. This works great except for the fact that the UserPart DisplayText is being called last and there is no "If Null then apply" on it.

So the question in my head is should we be focusing on building a user interface to set priority on what DisplayText get's implemented as prioirity? Alternatively, everyone out there who is building modules should handle this themself? Of course, the last option is not great as the module builder really doesn't know what is the most important to the end user. Final option, is there a precedence in the order that the DisplayText get's implemented? Does the Content Type work from the bottom most Content Part in the list to the top? If so, can we change "Order" of Content Parts in the Content Type and thus, in essence, allow each user to control the priority on the individual Content Type?

Look forward to some ideas, willing to code.

Coordinator
Nov 29, 2012 at 6:55 PM
Edited Nov 29, 2012 at 6:56 PM

Maybe we could do something with the part settings. This way, it could be edited from the content type editor. What do others think?

If you're going to build something into core to address this, please open a feature request in the issue tracker.

Nov 30, 2012 at 10:48 AM

I have been thinking about this a bit more and here is what I think would provide the most control. Right now each Content Type has a "Display Name", "Creatable", "Draftable", "Stereotype", and "Index this content type for search". I think it would be  best to have a field for "Default Display Text".

Option 1: This field would be a dropdown that is populated by querying (somehow) all of the attached parts and retrieving the eligible "Default Display Text". To support backwards integration, if it is left blank, the process just continues as it does today, you just get whichever Display Text happens to be returned. This new field would need to somehow be used as a check when the Display Text is being set to see if it is actually the correct one. 

Option 2: With the introduction of Tokens, it would not even need to be a dropdown, could just be a tokenized string. 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?

Before any coding is done (and yes, would throw it in as a feature request) would like to get some further thoughts of the community.

Coordinator
Nov 30, 2012 at 5:18 PM

That sounds great to me. Don't forget to open a feature request before you start however. That will enable us to formally approve it and will allow others to give feedback who might have missed this thread.