To be honest, once you have your strongly-typed model, anything you do in the Razor view is pure Razor - Ditto has done it's mapping bit and gets out of your way.
So things like overloaded helper methods that's regular Razor/C#.
As there are a few mappers to choose from, Where do you see this going? Do you think we might end up with one in Umbraco to complement its own IPublishedContentModelFactory?
I ask because I've become quite jaded about using package extensions for Umbraco. I've kept our build on the upgrade path from 4.0.4.2 to 7.3 and have hit roadblocks many times, almost always resorting to removing packages in favour of keeping Umbraco up-to-date.
In the case of a custom Mapper, it essentially becomes an underpinning for the whole delivery mechanism. Other than modifying your source code, what choices do you think I have going forward as Umbraco changes and/or you stop supporting it?
To my knowledge, the IPublishedContentModelFactory implementation in the Umbraco core isn't going away any time soon. Stephan (on the core-team) is continuing to drive it forwards.
My issue with the model-factory approach is that it assumes "1 DocType = 1 POCO", which in my experience isn't always the case, and led me to develop Ditto. Both approaches have their place, which is fine.
As for the longevity of 3rd-party packages, I hear you, 100%. It's always better to keep as close as possible to the Umbraco core's "best practices", (albeit, we don't always know what that exactly means).
With regards to Ditto's longevity specifically, I'm actively using it on the Carlsberg websites, which we'll actively support for at least the next 2 years. But lets say that I did get hit by a bus, (god forbid), there are 2 other contributors - Matt Brailsford & James Jackson-South ... so the project itself wouldn't halt. As well as, of course, the code being open-source.
I guess there's always a risk in using 3rd-party packages.
I think what typically happens is that with each client-project turnover, developers will review the tools/packages used and progress/evolve from there. If Ditto doesn't suit, then try something else on the next client-project.
Of course, ongoing project maintenance is a larger concern.
If i choose to use it, do you think it's probably better/safer for me to use the source code rather than nuget?
I currently prefer Dittos approach, it seems simpler than ModelsBuilder and UmbracoMapper. Also I don't want Visual Studio dependencies, as in ModelsBuilder.
Potentially this would mean, if I hit any compile or runtime issues at point of upgrading, I can fix them at the time and ultimately feed them back in.
Compiling the Ditto source-code yourself is fine, (there's a build.cmd in the root) ... Personally, I'd go with NuGet, (more of ease).
On a side-note, we're using AppVeyor for CI/builds, unit-tests and NuGet deployment.
The main downside with compiling your own is that if/when you need support, we (the Ditto team), can't be 100% sure if your build contains custom code.
But that's not really a showstopper if you're comfortable(ish) with the Ditto codebase.
Sorry to keep asking questions, does Ditto do media? I noticed ModelsBuilder will create models for media as well as content. At least that's what it looked like.
Declarative style in Razor with Ditto
Is it possible to do this...
https://github.com/zpqrtbnk/Zbu.ModelsBuilder/wiki/CoolThingsWithModels
In Ditto?
M.
Hi Martin,
Yes, 100% possible.
To be honest, once you have your strongly-typed model, anything you do in the Razor view is pure Razor - Ditto has done it's mapping bit and gets out of your way.
So things like overloaded helper methods that's regular Razor/C#.
Cheers,
- Lee
Thanks for the prompt. info Lee. Most helpful.
A quick question/opinion, if you don't mind...
As there are a few mappers to choose from, Where do you see this going? Do you think we might end up with one in Umbraco to complement its own IPublishedContentModelFactory?
I ask because I've become quite jaded about using package extensions for Umbraco. I've kept our build on the upgrade path from 4.0.4.2 to 7.3 and have hit roadblocks many times, almost always resorting to removing packages in favour of keeping Umbraco up-to-date.
In the case of a custom Mapper, it essentially becomes an underpinning for the whole delivery mechanism. Other than modifying your source code, what choices do you think I have going forward as Umbraco changes and/or you stop supporting it?
Kind regards
Martin
That's a really good question!
To my knowledge, the
IPublishedContentModelFactoryimplementation in the Umbraco core isn't going away any time soon. Stephan (on the core-team) is continuing to drive it forwards.My issue with the model-factory approach is that it assumes "1 DocType = 1 POCO", which in my experience isn't always the case, and led me to develop Ditto. Both approaches have their place, which is fine.
As for the longevity of 3rd-party packages, I hear you, 100%. It's always better to keep as close as possible to the Umbraco core's "best practices", (albeit, we don't always know what that exactly means).
With regards to Ditto's longevity specifically, I'm actively using it on the Carlsberg websites, which we'll actively support for at least the next 2 years. But lets say that I did get hit by a bus, (god forbid), there are 2 other contributors - Matt Brailsford & James Jackson-South ... so the project itself wouldn't halt. As well as, of course, the code being open-source.
I guess there's always a risk in using 3rd-party packages.
I think what typically happens is that with each client-project turnover, developers will review the tools/packages used and progress/evolve from there. If Ditto doesn't suit, then try something else on the next client-project.
Of course, ongoing project maintenance is a larger concern.
Cheers,
- Lee
Hi Lee
If i choose to use it, do you think it's probably better/safer for me to use the source code rather than nuget?
I currently prefer Dittos approach, it seems simpler than ModelsBuilder and UmbracoMapper. Also I don't want Visual Studio dependencies, as in ModelsBuilder.
Potentially this would mean, if I hit any compile or runtime issues at point of upgrading, I can fix them at the time and ultimately feed them back in.
What do you think?
M.
Compiling the Ditto source-code yourself is fine, (there's a
build.cmdin the root) ... Personally, I'd go with NuGet, (more of ease).On a side-note, we're using AppVeyor for CI/builds, unit-tests and NuGet deployment.
The main downside with compiling your own is that if/when you need support, we (the Ditto team), can't be 100% sure if your build contains custom code.
But that's not really a showstopper if you're comfortable(ish) with the Ditto codebase.
I hope this helps?
Cheers,
- Lee
Hi Lee
Thanks, i'll give it some thought.
Sorry to keep asking questions, does Ditto do media? I noticed ModelsBuilder will create models for media as well as content. At least that's what it looked like.
M.
Yup, Ditto works with
IPublishedContent... so Content, Media and Members :-)Thanks Lee
Branch time... i'll give it a whirl.
M.
is working on a reply...