Closed ujhelyiz closed 12 years ago
I agree.
Additional issue: multiple ObservableValue annotations are not supported right now - only the first one is used...
And we have a third issue: because of some value expression parsing issues only parameters can be databound for the Query Explorer - e.g. the following annotation returns empty values in the query explorer:
@ObservableValue(name = "className", expression = "$C.name$") pattern propertyNumberOfClassInPackage(P: Package, C : Class, No) {
I think, it is enough for today...
This is a high priority bugfix issue for 0.6.6. It might also necessitate an earlier 0.6.6 than originally planned, as these bugs clearly break functionality promised in the documentation.
About the third issue I had a revelation this night: I was wrong in the syntax, as the expression parameter should have stated "C.name" instead of "$C.name$", but the parse error was ignored and null was returned, so there is nothing on the user interface about this issue.
However, this does not change the fact that I agree about the milestone change.
The first two issues (displaying both parameters and extra values; multiple observable values support) seem working both in generated and generic interfaces, using a common code base for parameter calculation to avoid further discrepancies between the two.
I will have a look at the third issue later.
The Query Explorer view should order the Observable Values as follows:
Comparator added, commits cherry-picked into the maintenance branch.
When defining an ObservableValue annotation for a pattern, the Query Explorer "forgets" to display the parameters in the Details panel.
I would image, the correct semantics of observable values would be to have all parameters as observable properties, that could be extended with new values using the annotation, while (unless redefined) the original parameters are still available - both in the Details pane and in the Observable Match.