Closed leekelleher closed 8 years ago
Going back to #151 , if we don't have the ability to use the new Processor framework due to our dependencies (Ditto.Resolvers), is there a way to hijack Ditto's IPublishedContent source before it starts mapping?
@LoganLehman You could hook in via the onConverting
parameter/event.
(I'm not sure how that would workaround the "default resolver" issue?)
@leekelleher - I work with Nicholas Westby. I am coming at the problem he was experiencing a different way (just for testing purposes). Because we of how we are using Polyglot, translation nodes are kept in a translation folder underneath the content node. Polyglot automatically copies all of the properties from the node when a translation node is made for it.
My idea is to check if a translation node exists, and matches the segment in current url "/en-us/", "/es-mx/". When those conditions are met, it will actually change the IPublishedContent source from the original English node, and swap it for the appropriate translation node, and then have mapping continue as usual.
That should hopefully result in the translation content being assigned to our models instead of the original english node.
@leekelleher - I have tested this out. It seems as though I can reassign the DittoConversionHandlerContext
's Content
property but it doesn't have an effect on the output in the models:
[DittoOnConverting]
internal void OnConverting(DittoConversionHandlerContext ctx)
{
ctx.Content = ctx.Content.GetLocalizedContent();
}
@LoganLehman Ah ok, it will be because it's updating the context's instance property.
How is Ditto being called initially? Using the .As<T>()
call, or something else?
I'm wondering if you can call GetLocalizedContent()
prior to calling Ditto?
@leekelleher It seems as though we are using .As
public static T GetLocalizedContentAs<T>(this IPublishedContent currentNode) where T : class
{
return GetLocalizedContent(currentNode).As<T>();
}
@leekelleher - What I did above seems to work. Thanks for helping me talk through it ;)
@LoganLehman No problem at all, glad you got it working! :+1:
Proposed solution to issue #151
Adds a way to register the default processor type, either globally or at class-level.
Includes unit-tests to support this feature.