Logic behind "More than one type wants to be a model for content type"

[kows]

Error: "More than one type wants to be a model for content type 'XXX'"
I am wondering why this occurs on a global level.
Would it be breaking to allow this if the two types belong to a different namespace/assembly?

My case:
I'm trying to use some of the generated classes in a shared library cross projects.
But I do not want to limit the option to be able to replace/extend/overwrite the shared implementation.
I had:
Shared.Models.XXX
Project.Models.Builder.cs -> XXX.generated.cs
I can prevent the generation through IgnoreContentType attribute so the Shared version is used and I don't get the above mentioned exception.
But once I want to modify one, I would have to remove the Shared dll and provide all implementations inside the project.

[zpqrtbnk]

The logic behind it is as follows: for one content type alias, we need to identify one unique CLR type that is the corresponding model type. The entire codebase (ie all dlls) is scanned, and model types are discovered by the [PublishedModel("alias")] attribute. If we find two CLR types marked with that attribute, for the same alias, we cannot decide which one to use, hence the exception.

Even if the two classes were in different namespaces and/or assemblies, we still don't know which one to pick.

If I understand correctly, you would want your shared code to provide a model class for a given alias, while still allowing custom code to somewhat replace that model class - is that it?

This is not something we support at the moment, as models are automatically discovered and there is no way to "disable" a model. In addition, there is no reliable way (that I can think of) to filter the model types before they are injected into the factory.

So... assuming I've understood the situation, and my answer makes sense, that would be a feature request.

[kows]

That's what I feared, yes this would probably mean a feature request.
I guess ideally, the mapping would be one alias to many model types.

In my case again:
If you want the default implementation, use Shared.Models namespace.
If you want your own, use Project.Models namespace.

In the meanwhile I guess I'll work around this by only using the Shared in the building phase, and moving to Project for the actual usage.

[zpqrtbnk]

Looking into how to support this - won't work for PureLive but might work for other modes.

[zpqrtbnk]

Up until now, the model types would be resolved and passed directly to the PublishedModelFactory. Dealing with this feature request by implementing a ModelTypeCollection and its corresponding ModelTypeCollectionBuilder.

When starting up, the ModelsBuilderComposer finds all the types inheriting from PublishedElementModel or PublishedContentModel - but instead of passing them to the PublishedModelFactory, they go into the model type collection - which can then be modified by another composer:

[ComposeAfter(typeof(ModelsBuilderComposer))]
public class MyComposer : IComposer
{
  public void Composer(Composition composition)
  {
    composition.ModelTypes()
      .Remove<Shared.Models.MyModel>()
      .Add<Project.Models.MyModel>();
  }
}

Thoughts, comments?

[kows]

Late response but not actively working with this anymore :).
Seems doable, but this doesn't prevent both types to be registered through the ModelsBuilderComposer (both inheriting PublishedXXXModel)?
The removal of the Shared type in the ModelTypeCollection would be sufficient.