3

We've got a problem with the EntityBuilder when creating an entity. The builder is not resolving to the right entityClass when more than one entity class has been declared with the same entityName.

I show an example:

SCHEMA LINK

  • rootName Content
  • field: Seo (ComponentLink to Seo)

SCHEMA SEO

  • rootName Content

JAVA ENTITIES

@SemanticEntity(entityName = "Content", vocabulary = SDL_CORE, prefix = "tri")
public class Seo extends AbstractEntityModel

@SemanticEntity(entityName = "Content", vocabulary = SDL_CORE, prefix = "tri")
public class Link extends AbstractEntityModel

When creating the entity for the component Link, the componentLink field seo has to be resolved. The problem is that the entityClass is resolved against Link but not Seo entity.

The function getEntityClassByFullyQualifiedName looks up http://www.sdl.com/web/schemas/core:Content iterating over all the semantics with the node Content. The function finds both entities: Link and Seo, but this function always returns the first element: this.semanticMappingRegistry.getEntityClassByFullyQualifiedName(semanticTypeName)

QUESTION

  • Is this a bug or a misconfiguration issue?
3

I see this as expected behavior because how should getEntityClassByFullyQualifiedName know when to load Seo and when it should load Link?

The thing that makes entities unique is the entityName which is derived from RootElement names for all Schemas.

The solution is to use unique RootElement names for all Schemas.

| improve this answer | |
  • Sorry, I didn't read the question correctly. Seems like a bug to me. I thought you were talking about 2 separate schema's. The solution would be to use unique enityName as a work around. You can report the issue with the DXA team at Github or better yet implement a fix and do a pull request here ;) - github.com/sdl/dxa-web-application-java – Kunal Jun 28 '16 at 11:49
  • they are two separate Schemas, with the same root element name, at least that is what I read in the question. So Your answer is right, this is expected behaviour and DXA requires your root element names to be unique. – Bart Koopman Jun 28 '16 at 14:04
1

DXA has what we called automagic mapping of Schema fields to model properties, for this it uses the semantic mapping, which defaults to using the root element name of a Schema (see also http://docs.sdl.com/LiveContent/content/en-US/SDL%20DXA-v4/GUID-7EA7470E-1592-4734-B824-8F23FF3BD526).

Because of that, it is sort of required that you choose unique root element names to your Schemas, and for Multimedia Schemas, unique titles (since a MM Schema doesn't have a root element name, so we use the Schema title in its place).

Technically you could try to solve this through using the semantics, but since the root element name of a Schema is automatically considered the default semantic via the core vocabulary, you still run the risk of something mapping to the wrong model. If you simply look at your model classes you should be able to see the issue; you do pick a unique name for your model classes:

public class Seo extends AbstractEntityModel

and

public class Link extends AbstractEntityModel

But then you add the exact same semantics annotation to both:

@SemanticEntity(entityName = "Content", vocabulary = SDL_CORE, prefix = "tri")

And that annotation, is what does the mapping, so even I as a (smart) person cannot determine what you mean based on the information given, how do you expect a (dumb) bit of software to resolve it then?

| improve this answer | |
  • The problem is that the schemas were not well defined in Tridion, as we come from a non-dxa solution where the default value Content wasn't modified. Then, I can't change the root name schemas for all the schemas. In fact, I already tried and I couldn't achieve it. I can't save the components.Having a link component, with its id schema, we can get the semantic schema and with the class of the field we can get the entityClass. My problem was that the ComponentLinkFieldConverter class returns null when the targetClass and the calculatedClass are not assignables. – tfinez Jun 28 '16 at 15:23
  • I think that the solution is when the classes are not assignable, just replicate the same behavior as when throwing the ContentProviderException, create the entityModel with the targetClass. This is working fine for me. – tfinez Jun 28 '16 at 15:27
  • 1
    Although changing root element name in CM is a rather high impact action, it is possible. When you change the root element name in the CM Schema, you effectively invalidate the content of all Components based on the Schema (which still use the old root element name). However the Core Service provides an API to "synchronize" the Components with their Schema. Furhermore, the CME does that implicitly if you open and save the Components. – Rick Pannekoek Jun 29 '16 at 17:42
  • I think this might be explicitly explained in the documentation. We think that it would be great to have an addon/plugin in tridion for clients using DXA, then this will check that DXA constraints are accomplished in the CM. – tfinez Jun 30 '16 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.