Community
Participate
Working Groups
We currently have a workaround for this issue in Aspen, but logging the issue so it won't be lost. Email from Nadeem to Konstantin: -------------------------------- I'm noticing that the validate() method only appears to be called on ModelElementLists (and subsequenly the list's elements) that are rendered in a table on the UI, but not on the lists that are rendered in the tree via <node-list>. I'm trying to figure out if this is something wrong in my code, or if this is the intended behavior? I'm trying to get errors to appear on tree nodes that represent erroneous customizations in the webservices editor, i.e., a node whose existance is invalid but none of the node's properties are invalid. I tried an override of the validators() method to handle the validation, but the method was never called. I also tried adding a validator to the list property using the Validator annotation, but the validator was was never called. I thought of trying to add the @Validator annotation to the IModelElement, but it doesn't seem like the annotation is valid in that context. Email response from Konstantin: ------------------------------- Currently, decorators on nodes in the content outline are limited to surfacing aggregate validation state of content displayed in sections attached to the node or to node's children. This is implemented in this way to account for the fact that you can have multiple nodes covering the same model element (to break up large model elements) and there might be properties that you are not showing at all. In the narrower case of list properties rendered in the content outline, I think we can safely extend node decorators to take into account validation of the list property as long as validation was shallow (the list itself, rather than element properties). I don't think there would be ambiguity as to which node should show the decoration and I don't think there is ever a case when you don't want to see it. Of course, once we add this, it becomes pretty important for us to have tooltips that show the validation message. Right now, it is only a nice-to-have item, since the user can drill down and find the original marker to get more information from.
Should investigate this for 0.3.1 release.
I have found a workaround (by adding a filter) for bug 353252 support dynamic list of child element types. Thus I don't have a need for this bug at the 0.3.1 target milestone.
I am working on this one right now.
Upon further investigation, I have decided to split off the task of displaying validation messages via a tooltip when hovering over a content outline node (now tracked by Bug 357714) from the ability to augment model element's validation at element level independent of properties. This bug tracks the latter portion. Note that the original narrative is obsolete as there hasn't been a way to actually override ModelElement's validate method in many releases. The modern approach is to use a validation service. As such, this bug now tracks enabling the use of ValidationService at model element level. Unfortunately, this requires the changes to services API available only in the 0.4 release. Moving the target release accordingly.
This one has been done for a while. I just finished cleaning up the sample and the enhancements doc content. For a sample, see DuplicateContactValidationService. Please verify.
Verified errors appears on tree node. Reopen bug because duplicate errors shown if more than one errors. contact.xml create 1 contact -> fill in all required texts create another contact -> name is the same as the first contact, leave other empty Now notice the errors are duplicated in reverse order.
Ling, I am wondering whether this is related or not. Could you check if de-duplication was happening in 0.4?
No duplication in 0.4 - should I open another bug for the regression?
If its a regression, then its fine to use this bug to track it.
Fixed the regression where duplicate validation messages are shown.
verified on 0.5.0.201206052356
Thanks. Closing.