Field order when generating pages from subclasses

[schifazl]

When generating pages from subclasses, the order of the fields is: first the fields from the subclass and then the fields from the superclass. The other way around would be better, because the superclass contains the ID (plus more generic fields), which logically should appear first.

E.g.: If you watch the Customer2 class from the previous thread, when you click create or edit or view you'll see first the many to many relationship and then the ID and other fields from EndUser2.

It's not a big problem, just a minor feature that I think could be useful

[Kay Wrobel]

This might be done on a level I don't have control over since I'm using NetBeans' internal API calls. Let me take a look at where this info is gathered and I'll get back to you on this.

[Kay Wrobel]

So after investigating the piece of code that gathers field names to be processed for each page, it looks like the NetBeans team is using methods from the javax.lang.model package, indicating that these are actually system methods. They use the following call in their JpaControllerUtil class:

ElementFilter.methodsIn(typeElement.getEnclosedElements())

This call returns an array containing all methods of a class, and it seems that the methods from the current class are preferred over the methods from inherited class. In other words, it traverses the methods from the bottom up rather than from the top down. Makes sense to me since it probably has to recursively gather the information.

[schifazl]

What a pity! Thanks for your time, I'll manually correct the order ;)

[Kay Wrobel]

Hey Schifazl, don't give up just yet. I am going to "massage" the way this is being done as I can see NetBeans' code and how they traverse the chain of classes. I am going to give it a shot to traverse from top to bottom as I also believe that, for this kind of application, we should see the fields of the superclass first. So hang on tight.

[Kay Wrobel]

You will be happy to know that I have taken care of this problem as well. The wizard will now prefer fields from your abstract class over the concrete class. I think this is in everybody's best interest.

May I suggest to you two changes to your EndUser2 class:

• Use @MappedSuperClass since it is not a queryable entity that exists by itself
• Use @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) instead of JOINED to produce one class per inherited entity.

These are just suggestions, though. @MappedSuperClass also has the effect that EndUser2 will not show up in the Available Entities list.

[schifazl]

Whoa, you're the best!

I understand your suggestion, but the "real" EndUser class (this one is simplified) has some relationships with other entities. I put them there because these relationships are common for the EndUser's subclasses: Customer and Employee. E.g. an order can be placed both by a Customer or an Employee. I'll consider the table per concrete class, but due to the relationships in EndUser I'm not sure if this is feasible.

[Kay Wrobel]

Hi Schifazl. I'm not sure if I had already addressed this problem in version 0.21, but go ahead and check out version 0.22. Should definitely be in there now. OK?

Enjoy!