Implement a Token Provider interface #3820
Conversation
|
|
|
did you test with modules implementing custom TR, like "DNN Form & List"? |
I haven't tested Form and List yet. I tested the HTML module, which also uses a derived TR HtmlTokenReplace and the skin tokens, such as the language flags. |
|
tokenReplace was originally developed as part of Form&List module, which still uses it more extensively than HTML, Skin or Newsletter module. |
Thanks for the info! I've detected an issue and made adjustments. |
|
@bogdan-litescu this contribution looks great! There are some failing tests, though. I'm assuming you'll need to adjust how some things are created in the tests, maybe by creating mock implementations. Feel free to ask questions if you have trouble tracking the issues down. Thanks! |
@bdukes Thanks for pointing this out. I registered the CoreTokenProvider in the ComponentFactory and that seems to do the trick. |
use the default TokenProvider for token replacement cleanup
|
It would be very nice to see some documentation or an example usage somewhere... I tried to use this and got into StackOverflow errors, not sure why... |
Agreed @valadas @bogdan-litescu is that something you'd be able to do? |
#3819.
The token replacement code is very exposed through public and protected members. My implementation leaves all of those in place to avoid breaking existing functionality. Therefore, all the core tokenization code still lives in the BaseCustomTokenReplace, BaseTokenReplace and TokenReplace classes.
If the provider is different than the CoreTokenProvider, it calls that provider instead. The CoreTokenProvider also has a simple implementation that calls the TokenReplace class. This is in case someone decides to use the provider instead of calling TokenReplace directly.
The changes I did also consolidate all parameters related to tokenization into a single TokenContext class that can be easily passed around.
Tested on DNN 9.6.1 with some simple scenarios and everything seems to work as before.