Specification Writer Error with Parameters

[FedorSmirnov89]

When the specification writer is used to generate the xml file of a specification where parameters are defined for a certain attribute, it generates an xml file where the corresponding attribute is set to the default value instead of writing the appropriate parameter.

[vrichthammer]

I had a quick look at Part5 of the tutorial, where a small spec with parameters is exported. The export has the same problem you mentioned. Two things I noticed for this particular problem: (1) When viewing the specification with the SpecificationViewer, only the default value of the parameters is displayed, i.e. I cannot see that a particular attribute has parameters. (2) When inspecting the actual object that is set as parameter attribute (e.g. "variant" for Resource r1), its class is not ParameterSelect (as should be returned by the call to Parameters.select(...), when the parameter is created), but it is always the type of the default object and the objects contained in the list (i.e. String for "variant", or Integer for "cc", "memory", and "cost"). Since the Writer checks whether an attribute is instanceof Parameter, it obviously never exports mentioned attributes as parameter. Can you verify whether this is also the case for your specs (since I think you mentioned that DSE with parameters works for you)? Then the problem might not (only) be with the Writer, but also with how parameters are actually stored in the Specification (which I have not had a look at yet).

[FedorSmirnov89]

Concerning point (1):

You have inspected the attributes by choosing the according attribute in the drop-down list, right? This is an other weird thing. In this case it shows the default value. But if you hover over the element, it actually shows you the correct parameter values.

Concerning point (2):

I do not 100 % understand your question, but a parameter-based exploration definitely works as long as you set the parameters directly for the Element (the Java object) and do not store and reload it via xml in between.

[FedorSmirnov89]

Okay, I have added a test that checks (branch testForIssue17) that the process of reading and writing results in the same attribute for the annotated element. The problem also may lie with the getAttribute() method which returns the default value in case that the attribute is parametrized.

[vrichthammer]

This is exactly what I mean with (2): if you set a parameter attribute, and subsequently call getAttribute(), the type of the returned attribute is the class of the default value, and not class ParameterSelect, as is required by the Writer... Edit: Which obviously makes sense, if getAttribute() only returns the default value.

[vrichthammer]

The problem seems to come from the following method in Attributes.java, that - if an attribute is a parameter - returns the (default) value of a Parameter object, instead of the object itself. Fixing this and simply returning the Parameter object should resolve the error with the SpecificationWriter (since, again, the Writer checks if an attribute is instanceof Parameter). I am, however, not sure if any other parts of OpenDSE rely on the fact that getAttribute() works in this way?!

'public <O> O getAttribute(String identifier) {
    Object value = get(identifier);
    return (O) ((value instanceof Parameter) ? ((Parameter) value).getValue() : value);
}`

[FedorSmirnov89]

How about the Element.getAttributeParameter(String identifier) method in the Element class (package: net.sf.opendse.model). Iterating all the attributes of the element and checking whether the method returns a non-null value should give us all parameters in the spec.

Then we just need to agree on the syntax to write into the .xml and teach the writer and the reader to follow this syntax.