Hi Denis (and other contributors)!

Great work on this one! Really awesome and thanks for sharing it! I would definitely contribute in the future! I really think that this project has the potential of being a great source of inspiration and best practice for Umbraco websites going forward. Like a documentation that actually shows how to solve the “real” problems implementors are facing.

I’m wondering about ditching Models Builder. Is there a really good reason not to use it in a best practice example?

I do get that you don’t want to expose the whole cms-model (IPublishedContent) in the view but wouldn’t the mapping in the controllers be cleaner/safer if done from a models builder model? The models created by Models Builder is basically what you are doing manually in the controllers but without all the constants for property names, or actually more “automatic constants” with the strongly typed names. They also keep information about any Compositions so one can go ie:

if(model is IPageWithHero hero) {
…
}

It’s also safer for any changes in the document type - MB would give a compiler warning. The current solution will throw at runtime in best case or silently fail/behave strange if I forget to change the constant for the property alias.

Did you actively decide not to go with Models Builder? It would be nice to hear more about why and maybe document that decision.

And also, I think it sounds bad to indicate that models builder is only suitable for “simpler projects” (in the readme) - that might put a lot of people in the wrong direction, I would say that it might be a matter of taste but from a technical standpoint running without Model Builder is a less safe and sustainable way of building a complex and maintainable solution with Umbraco - more manual work and more prone to errors.

Would be nice to hear your thoughts?

Cheers man!

After cloning and running demo project, an upgrade required notice displays: https://www.screencast.com/t/QvjPBe7SuHj

After clicking the continue button the following error displays: https://www.screencast.com/t/aLVKRsZiakQ

Please advise. Thanks!

Hi Dennis, I have realised that you changed my last pull request and I like to understand your intention. So have changed the code again and added an extra comment for explanation.

Let me explain in my own words: My concern is about the class name HeroComponent. Later on in Web project you reference this class in \Views\Home.cshtml with:

@(await Component.InvokeAsync("Hero", Model.Hero))

This is only works when you add the attribute [ViewComponent(Name = "Hero")] to the class.

I can imagine one argument for the class name suffix Component and extra attribute:

1. This is to express the type of class by its name.
2. And the attribute to avoid an obviously redundant expression like [ViewComponent(Name = "HeroComponent")]

If this is your intent, I think you should call the class HeroViewComponent and omit the attribute.

Another argument for the extra attribute is to make views resilient against class name refactoring in the Core project.

For me all this has code smells🤔 Maybe I am overly pedantic or got something wrong. Actually I just like to hear your opinion!

Btw. I got my first ahh effect of mocking and testing😁

/Dirk

Hi Dennis, I think this is a good starting point for a Models Builder setup.

• Upgrade to Umbraco release version 9.0.0
• small bugfixes for search
• Models are generated in the .Core project
• hard coded property alias constants are obsolete now!
• manual mapping of these models int simple POCO view models are mostly done in page controllers (for SitePageBase base class I use an extension method viewModel.MapSitePageBase())
• updated tests (need to setup all view model properties with empty values. I'm not sure this is the best approach🤔 Do you have an idea?)

I am looking forward for your review. Have a nice weekend!

Dirk

Depending on the content structure we can look for a settings node at root, under home node or deeper in structure. Alternatively we could also use Descendant() method, DescendantOfType() or FirstChildOfType().

Fixes https://github.com/Adolfi/UmbracoNineDemoSite/issues/9

I noticed ContentAtXPath() is used here: https://github.com/Adolfi/UmbracoNineDemoSite/blob/master/UmbracoNineDemoSite.Core/Features/Shared/Settings/SiteSettings.cs#L17-L18

In both Umbraco v8 and v9 there is no longer an XML config/cache, so it is NuCache representation as XML and using XPathNavigator. Most of the time we don't need it though.

So with NuCache it should be faster using the LINQ queries or in other cases Examine.

Something like this:

private IPublishedContent home => this.umbracoHelper.ContentAtRoot().Where(x => x.ContentType.Alias == ContentTypeAlias.Home)?.FirstOrDefault();
private IPublishedContent settings => this.umbracoHelper.ContentAtRoot().Where(x => x.ContentType.Alias == ContentTypeAlias.SiteSettings)?.FirstOrDefault();

or

private IPublishedContent home => this.umbracoHelper.ContentAtRoot().FirstOrDefault(x => x.ContentType.Alias == ContentTypeAlias.Home);
private IPublishedContent settings => this.umbracoHelper.ContentAtRoot().FirstOrDefault(x => x.ContentType.Alias == ContentTypeAlias.SiteSettings);

Furthermore I think it could use .Value() / Value<T>() extension method if the code should be a bit more simpler.

public string CallToActionHeader => this.settings.Value<string>(PropertyAlias.CallToActionHeader);

Hi Dennis, I have changed some umbracoContext?.Content.GetByXPath requests into umbracoContext?.Content.GetByContentType which has a better performance. But I could not figure out how to update related tests😣

Currently I have no time for further help because I am in a new job position where Umbraco is not a topic. I wish you good luck with this project.

Maybe we meet at next CodeGarden...

Dirk

1. Upgrade to release version 9.0.0
2. Several fixes for search:

• add url for content pages (not sure this is best practise getting the url 🙄)
• fix total of pages + products
• show single product result
• add search field 'preamble' and type for Home page

Hi Dennis, I have exclude wwwroot\umbraco\lib folder, because it gets regenerated on each run. Hopefully Umbraco or Community (maybe me) will document an updated .gitignore for V9🙄

Btw. again I create this PR for the feature/integration-products branch, because it seems to be your current WIP branch. In general I think it would be better to use the master branch. My experience with git is: short life times for feature branches are the best to avoid merging conflicts or limit the effort of solving these. What do you think about branch targets and git collaboration?

Have a nice weekend!

/Dirk

Hi Dennis, after CodeGarden and the "unintended" release of version 10.0.0 I have added a v10 solution to the Modelsbuilder branch. I think it makes sense to keep the v9 solution for now. Yours Dirk

Sorry if this is not the right place to ask, but I am seriously struggling to find out how to do this and wondered if there is any code here that would help:

I have added some custom fields to the Member type and want to add them to the Member index. My last project was using Umbraco 7 and I have skipped V8 and gone straight to V9 for this current project, so configuring Examine indexes is completely different!

So, say I have added a field to the Member type which has an alias of "disableBalanceAlert" ... how do I include this as a searchable field in the Member index?

Again, if this is not an appropriate question here, then just comment as such and I'll continue my search elsewhere.