How are you integrating Strongly Typed Models on Document Types that your package creates with the host Umbraco CMS?
For example, I have a site with a custom namespace set for the Strongly Typed models generation, and I want to add a package that has it’s own set of Document Types. I don’t necessarily want to have to worry about different namespaces for these models, they should be generated and delivered by the package, without causing problems when generating document types within Umbraco (don’t want duplicates, etc.)
This also begs the question: What’s the best way to register (create) a package’s document types with Umbraco? I could use a migration perhaps - or package some Deploy files + package uSync files to accommodate both systems…
I remembered a discord chat on this… How to include Models Builder models in package Umbraco #help-with-umbraco
But think it’s fraught with danger to try to have modelsbuilder in packages.. you just don’t know what the end user might be doing with modelsbuilder settings.. (not inconcievable to have mode set to none for all environments?)
Could you perhaps use UmbracoMapper to map to your typed objects from IPublishedContent? (not sure how extensible it is as usually use automapper)
Having had to deal with doctype creation in a theme package, again a few danger points.. migrations with the automatice package migration, so old now… and package updates down the line can be hit and miss merging doctype changes seem to be ok, but dataypes just ignore updates if a dataype exists. Also with migrations you have suppressed notifications and need to add a postmigration handler to redo a save.. as otherwise if you are using uSync/Deploy (importAtStartup) they revert your changes. Package developers.. I see I can use Umbraco #package-development
One other thing with the automatic package migration, is that it also deals with templates (views) requiring your template chtml to be plain text in the package.xml and so you have this duality where you actually want nuget to handle the chtml file.. but then battle commences between the automaticpackagemigration and nuget targets for who wins and what you cshtml ends up looking like,
could you somehow re-use models generation to generate modelsbuilder compliant cs-files for your types? Though package would still have an issue if the enduser wasn’t using modelsbuilder?
I’m currently copying the generated models into the package project, so not worrying so much about the generation - not ideal, but workable - I suspect when it comes to running the site with these, it will duplicate the models but in a different namespace based on the modelsbuilder settings, so in theory shouldn’t conflict. It’s not more about how to get those document types and associated properties in there in the first place…
I’ve not even started on views as yet, but I suspect this won’t really be a problem as they nuget package will package them up, and if I get the deploy/usync files right, they should in theory just be imported
I’ve not even considered looking at package.xml for this! Looks like that’s my next stop though
Interesting, I guess you are setting you modelsbuilder namespace to be aligned with your package so as not to get conflicts should the default be left?
Does that though then preclude the enduser updating models and views/partials should they so wish to extend your package… (guessing you are rcl approach so allowing the override facility?)
with uSync/deploy I’d not seen where you can have different settings for package installs.. So again are you at the mercy of an enduser having importAtStartup/firstboot to none (uSync for me as deploy too pricey :-)) .. and so your package dictates a certain uSync config?
