this is a very large step ahead. I have seen that you not only adapted the sources to the existing sources, but even were able to fix the source.
For instance in Attribute you were able to provide now always the correct default values. You used the automated IDE formatting indention, etc.
In addition I like your statements in an generated element class for adding a child element:
- Child element is new in Odf 1.2
- Child element is mandatory.
Still we might think about a different Syntax, perhaps similar to the JDK
@since ODF 1.2
@since ODF 1.1
On the get/setter of the new element/attribute and on the element/attribute itself.
Complicated when only the value has been altered, or it was removed and later added.. But we get off-track, those feature might be worth a stand-alone bugzilla task.
Aside of this great improvements there are still some parts, that you need to revise.
(Perhaps you add next time some summary, of what you have changed and why you have changed it, so I am not mistaken about the benefits, I oversee.)
1) Validation of attribute values.
The discussion about validation is before your time, but Daisy can give you insights about the validation steps we did before.
Earlier we used our ODFDOM type classes from the Java package
to validate every input.
But often the user only wants add a value to an attribute without need of validation, the validation should become an optional step, but not the default.
This optional handling has not be added to ODFDOM so far.
Therefore in public void setValue(String attrValue)
you should write
instead of the current new created
Your version will follow with the enabling of optional validation (you might keep the source as comment in the template.
(similar for other Java primitives and the getValue method)
During review I realized, that if we changed in OdfElement
public OdfAttribute getOdfAttribute(OdfNamespace namespace, String localname)
public OdfAttribute getOdfAttribute(NamespaceName namespace, String localname)
Using the interface, we might generate in OdfElement instead of
making it easier for the user.
Shall we return from an element (e.g. AnimAnimateColorElement.java):
I tend to the first, as the redirection will resolved during compile time and there is only one instance of the DEFAULT_VALUE available.
You have changed this, I do not see the benefit here.
PS: As I only could make random picks, there might be further obstacles unseen yet... I assume Daisy finished her review on those changes already.