Closed gvanbrakel closed 2 years ago
This issue asks to remove the concept of "technical override" for config children. We should investigate the impact before doing that. I will create an XSD without technical overrides and compare it to the XSD we are currently working with. We can discuss the differences to make a decision what to do.
I have created an XSD in which technical overrides are not ignored. This has the following effects:
And the effect we want: SenderPipe gets MessageLog, InputWrapper and InputValidator.
These effects can be mitigated by replacing an empty description by the inherited description. The drawback is that the XSDs become larger this way because descriptions are repeated.
I think technical overrides are a useful feature: If there is a technical override, then the Frank!Doc is not affected. This issue identifies a case in which an overriden method should affect the Frank!Doc, while the method has no JavaDoc of its own. I propose we introduce a JavaDoc tag @ff.reintroduce
. If a config child or attribute has that annotation, then the attribute or config child has to appear in the child (no technical override).
We can have a Java annotation @Reintroduce that does the same as @ff.reintroduce
.
This solution is very easy to implement.
There is no need to lose a description. If no description is specified, is should be inherited.
After analyzing, I agree with the proposed solution to introduce a Java annotation @Reintroduce.
Order of nested elements should be the same as the order of declaration of the corresponding setter-methods. SenderPipe overrides setMessageLog, setInputWrapper and setInputValidator, but this is not reflected in the order in the FrankDoc: