Class Associations in generated Model classes

[ombako]

Given the following itemtype definition:

 <itemtype code="BaseSite" autocreate="false" generate="false">
     <description>Extending BaseSite type with additional attributes.</description>
     <attributes>
         <!-- Other properties omitted -->
         <attribute qualifier="defaultPromotionGroup" type="PromotionGroup">
             <description>The default promotion group for the site.</description>
             <persistence type="property" />
         </attribute>
     </attributes>
 </itemtype>

the file BaseSiteModel.java will be generated:

 public class BaseSiteModel extends ItemModel
 {
     public final static String _TYPECODE = "BaseSite";
     /* Other properties omitted */
     public static final String DEFAULTPROMOTIONGROUP = "defaultPromotionGroup";
 
     @Accessor(qualifier = "defaultPromotionGroup", type = Accessor.Type.GETTER)
     public PromotionGroupModel getDefaultPromotionGroup()
     {
         return getPersistenceContext().getPropertyValue(DEFAULTPROMOTIONGROUP);
     }
 }    

The generated class has no property of type PromotionGroupModel, only a static final String which will be used by the getter to return an instance of type PromotionGroupModel.

The question: Is there any way to have hybris generate a real association property like the following?

private PromotionGroupModel promotionGroup;

That way the generated java class would look like:

 public class BaseSiteModel extends ItemModel
 {
     public final static String _TYPECODE = "BaseSite";
     /* Other properties omitted */
      public static final String DEFAULTPROMOTIONGROUP = "defaultPromotionGroup";
      private PromotionGroupModel promotionGroup;
 
     @Accessor(qualifier = "defaultPromotionGroup", type = Accessor.Type.GETTER)
     public PromotionGroupModel getDefaultPromotionGroup()
     {
         return promotionGroup;
     }
 }

[ombako]

Consider the following UML Diagramm of a generated Model object next to a simple POJO:

Looking at the model you cannot tell of what type the properties are, since all of them are of type String. The diagram of the POJO, on the other side, tells you straight away of what type each property is.

Why are models generated this way? Is there a way to change that?

[Former Member]

Why would you need this? Anyway I wouldn't even consider this change as such associations managed by the Hybris persistence framework, if you make it part of the class then you may introduce significant problem in real time.

[ombako]

I find myself very often trying to figure out how the models relate to each other, how their dependencies look like, what the type of a given attribute is and so on. For all of that an UML-Diagramm can be very useful and that's what an UML is for in the first place.

Now, the way hybris generates the java classes prevents you from doing that. It wasn't like that before, that changed around version 5.3, I was hoping that it became optional and that you could somehow reactivated it.

[Former Member]

For that purpose you always need to consult with *items.xml, that's "source of truth", not generated java classes. And there are tools which can create UML diagrams out of *items.xml files.

[ombako]

Do you happen to know what UML tool generates uml out of *items.xml? I could try with that. Thanks for the hint.

May I still disagree with you? 😉 You are right when you say that the items.xml is the source of truth, but if a Model.java has just been generated out the items.xml, why should there be any differences? Besides, a generated model is the sum of all definitions for that type that might be scattered through many items.xml in different extensions. So, an items.xml might just be a part of the whole truth for a given type, while the Model is the result of all those parts.

[Former Member]

Try this one

[former_member624549]

can't you generate the uml and tell it to use getter/setter pairs only? The getter/setter on the model do tell what fields you have. Even better than the items.xml. since in items xml a item can be modified/have fields added in different places. For example relations you see immediately on the model but not that easy in the items.xml

[former_member624549]

It once was the way you ask for! Having the a real object property also has the advantage to actually see the model fields in a debugger as how it is now you don't see the fields.

The hybris models are not real pojo. You see the members of the model only from the getter/setter pair. The real values are in a hashmap in the context object. But not all of them, only the ones you have accessed.

Why hybris changed from real object members to a proprietary hash map one (or at least I) can only speculate.

[ombako]

Thanks for your comment. That's exactly the way I remember it and neither can I understand why the changed it. Well, it's hybris, you know...

[geffchang]

You can customize model generation, but what you are looking for is not supported.

Only the following are supported:

• exclude an entire type (including all subtypes) from the generation

• exclude an attribute from the Model generation process

• specify a constructor to be generated

• add alternative getter and setter methods for an attribute

I assume it's designed this way because it needs to get the values through the persistence context.

Reference: Models

[ombako]

Thank you for your answer. I can't help but only sigh in frustration that it's been implemented this way. It's thwarting the help the language syntax can offer.

Just for my own note, why not something like this?:

 @Accessor(qualifier = "defaultPromotionGroup", type = Accessor.Type.GETTER)
      public PromotionGroupModel getDefaultPromotionGroup()
      {
          if (promotionGroup == null) {
              promotionGroup = getPersistenceContext().getPropertyValue(DEFAULTPROMOTIONGROUP);
          }
          return promotionGroup;
      }
 

[geffchang]

We just have to get used to the way Hybris platform works. Anyway, if you are using Ee, you can always see the return type of the getters in the Outline view. 🙂

Also, if you think this answer has been somewhat helpful, feel free to Upvote and/or Accept the Answer. :)