Ditto 0.9 = Death of Ditto Archetype Resolvers?
Nicholas-Westby opened this issue · comments
See here: micklaw/Ditto.Resolvers#14 (comment)
Looks like the changes in Ditto 0.9 are extensive enough that the creator of Ditto Archetype Resolvers no longer has the ability to add support for this version of Ditto.
I have been using Ditto/Archetype heavily with my latest site over the last 6 months or so. I was hoping Ditto would be our (aka, http://rhythmagency.com/) content mapper going forward. It looks like this may no longer be the case.
Is there anything you can do to help Ditto Archetype Resolvers or an alternative for Archetype support?
@Nicholas-Westby Here's my solution for using Ditto with Archetype:
https://github.com/leekelleher/umbraco-ditto-labs/blob/develop/src/README.md#ditto-for-archetype
That looks promising! Hopefully it has similar capabilities to the Ditto Archetype Resolvers (my Archetypes are used to store very complicated sets of widgets). Thanks for the tip; will definitely look into that.
That's the extension method I was taking about, though I think this would mean that each POCO would now need to inherit from PublishedContentModel?
So I am not sure if this would would be a show stopper for you based on your previous requirements for this to be more polymorphic?
Yes, I would not want to have my POCO's inherit from PublishedContentModel. And I have a ton of widgets that inherit from a single IWidget interface (an empty interface). Here are about half of my widgets for the site I built with Ditto Archetype Resolvers:
Some of those are very complicated. Here is one that is low to medium complexity:
And here's the class that is used to map the widgets:
@leekelleher Would the extension method (or attribute) you linked to be able to handle this level of complexity for mapping Archetype to POCO's without requiring those POCO's inherit from a base class like PublishedContentModel?
@Nicholas-Westby There's no constraint on having your POCOs inherit from any class (PublishedContentModel or other).
Thought I'd throw my two cents in, but its been a while since I've been in Umbracoland, and really does seem like major amends have been made to Ditto, for the better of course. So feel free to shoot me down if I'm way off mark with my views.
From having a quick scan of the docs it seems like Ditto no longer requires your POCOs to inherit for anything Umbraco related? So really is now just plain old classes, awesome. Though, from looking at the docs it seems like for @Nicholas-Westby to bind his Archetype Fieldset based POCOs to a collection based on one of his Interfaces, he would need to also have his classes inherit from IPublishedContentModel, as it only seems to bind to IEnumerable<IPublishedContentModel>. Would it be possible to bind to an IEnumerable<IWidget>, if so I see no reason to use the old Resolvers project as this meets the same functionality the Resolvers project aimed to achieve using more standardised Umbraco practices.
just out of interest, is this also true of doc types and collections, like if i had a base class or inherited from some abstract class, would Ditto hook this up for me? Or would it only work with an IEnumerable<IPublishedContent>
Correct me if I am wrong Nicholas.
@micklaw Right, that is the real question. That is, if [DittoArchetype] can handle a collection of mixed Archetype fieldsets (what I call "widgets"). And if it could do so cleanly (i.e., without inheriting from IPublishedContentModel).
And if it provides Ditto-like behaviors for nested Archetypes (e.g., a grid widget that contains a section widget that contains a rich text and image widget).
Or is it a very simple attribute that just allows for mapping a very simple Archetype?
For reference, here's an example of a nested widget scenario that Ditto Archetype Resolvers is currently handling properly:
Hi @micklaw - all good questions 😃
Ditto has never enforced that your POCO has to inherit from something. We do have an optional feature for your POCO's constructor to accept an IPublishedContent parameter - which is probably the part that could mislead people.
As for mapping to a collection of custom interfaces, no Ditto doesn't (currently) offer that feature, sorry. (Totally open to contributions on that if it is possible)
That said, we can map to IEnumerable<IPublishedContent>, but that is only because we know what we're dealing with, we can return the concrete classes straight from Umbraco.
With reference to Archetype, just to clarify that the proposed solution that I linked to earlier is part of my "Ditto Labs" expermental repository - the sole purpose is to convert an ArchetypeFieldsetModel into an IPublishedContent, then let Ditto do it's thing. (It was in no way indented to be a drop-in replacement for your Ditto Archetype Resolver).
Hey @leekelleher,
Thanks for that. Yeah I think that's maybe what got me thinking originally there was a dependency on the PublishedContentModel class. Turns out I've been doing it wrong from the get go... doh!
I do think this would be a great feature and would absolutely help in keeping binding more polymorphic for what @Nicholas-Westby is trying to achieve. I might be able to contribute some work towards assigning to a collection based on the Ienumerable properties first generic type. Though, you guys are machines and would more than likely nail this before I get the chance, but if I manage to scramble a few hours I'll give it a whack!
This does feel like the correct way to move forward with Ditto and Archetypes for me, the Resolvers thing for Archetypes was a Frankensteins monster of reflection and workarounds to bind in to the Ditto converters which never sat well with me. This feels much more structured.
@micklaw Just been looking over your code for ArchetypeContentAttribute - I'm still reading, but curious if/how this could be possible for Ditto core. I think it's worth exploring, (not suggesting for you to dev it - unless you've got an itch for it? 😉)
With going from ValueResolvers to Processors, it's all pure evolution of the codebase - I remember thinking at the time of v0.8.0 release that "we'd nailed it", then @mattbrailsford blew us away with Processors pipeline 
Ha yeah, sadly I do have an itch for this type of stuff, it a vice I think we all share!
The approach we took in the resolvers project is similar to Ditto I think, the only difference when we want to bind to an IEnumerable<IWidget> we require on the POCO it inherits from the interface or abstract class and also decorate it with an Attribute so we know which alias is dependant on which type. We cache this up so its not expensive for us. All other stuff we can just derive based on the POCO type.
Yeah, I remember having a look month ago when @mattbrailsford added it in, I made a lot of sense as I was always a bit torn with the TypeConvertors and ValueResolvers stuff, felt a little duplicated in places. In saying that though, its been a great bit of code you guys have all created, I'm sure its making folks life much easier, certainly did mine when we hooked all my examine based searches up with it. Strong type all the things!
Closing this one off.
Archetype can be handled via "Ditto Labs" and polymorphic collections discussion is over on #168 (and PR #169).
For reference, I posted an example of this in another comment: #168 (comment)