Home » Modeling » EMF » Trigger Parent Consraints from Diagnostician
| | |
| Re: Trigger Parent Consraints from Diagnostician [message #480849 is a reply to message #480647] |
Tue, 18 August 2009 16:30   |
 John T.E. Timm
Messages: 161
Registered: July 2009 |
Senior Member |
|
|
Looking at the UML2 contribution to codegen of validation-related code, it
looks like it uses the stock EMF template without modification. I think
the problem actually lies in how Diagnostician finds validators for a
given object/class. Specifically the method:
public boolean validate(EClass eClass, EObject eObject, DiagnosticChain
diagnostics, Map<Object, Object> context)
It appears that this method walks up the inheritance tree looking at
classes/packages until it finds a validator and uses the first available.
If a validator exists higher in the, it could be ignored. Instead,
perhaps, the method should collect all validators for a class and its
supertypes and process them in a loop while gathering results. I'm going
to take a stab at overriding this method.
Thanks,
JT
Ed Merks wrote:
> John,
> Yes, this doesn't sound quite right. The basic validator should take
> all constraints from all the classes into account.
> John T.E. Timm schrieb:
>> I suppose this behavior is more related to the way that UML2 generates
>> an EValidator implementation class to evaluate OCL constraints. Perhaps
>> the EValidator implementation could also include the validation of an
>> instance against constraints on its class supertypes. Alternatively, I
>> could override the default Diagnostician implementation to take into
>> consideration EValidators for supertypes of a given class.
>>
>> Thanks,
>>
>> JT
>>
>> John T.E. Timm wrote:
>>
>>> I have two classes in different packages:
>>
>>> package A
>>> class A
>>
>>> package B
>>> class B -> A
>>
>>> Where B is a subclass of A. I have OCL constraints on both classes
>>> wihch generates an EValidator for both packages. If I attempt to
>>> validate an instance of class B, I notice that none of the constraints
>>> attached to class A will fire. Is it possible to trigger these
>>> constraints? The code in Diagnostician appears to only consider the
>>> EValidator for package A::class A, iff an EValidator for package
>>> B::class B does not exist but in my case, I want to validate an
>>> instance of B against class B AND class A constraints.
>>
>>> Thanks,
>>
>>> JT
>>
>>
|
|
|
| Re: Trigger Parent Consraints from Diagnostician [message #480869 is a reply to message #480849] |
Tue, 18 August 2009 17:49 |
John T.E. Timm
Messages: 161
Registered: July 2009 |
Senior Member |
|
|
Something I missed yesterday is what is happening in EObject Validator:
List<EClass> eSuperTypes = eClass.getESuperTypes();
return
eSuperTypes.isEmpty() ?
validate_EveryDefaultConstraint(eObject, diagnostics, context) :
validate(eSuperTypes.get(0), eObject, diagnostics, context);
Apparently, the super types are considered during validation. I must be
chasing another issue.
Thanks,
JT
John T.E. Timm wrote:
> Looking at the UML2 contribution to codegen of validation-related code, it
> looks like it uses the stock EMF template without modification. I think
> the problem actually lies in how Diagnostician finds validators for a
> given object/class. Specifically the method:
> public boolean validate(EClass eClass, EObject eObject, DiagnosticChain
> diagnostics, Map<Object, Object> context)
> It appears that this method walks up the inheritance tree looking at
> classes/packages until it finds a validator and uses the first available.
> If a validator exists higher in the, it could be ignored. Instead,
> perhaps, the method should collect all validators for a class and its
> supertypes and process them in a loop while gathering results. I'm going
> to take a stab at overriding this method.
> Thanks,
> JT
> Ed Merks wrote:
>> John,
>> Yes, this doesn't sound quite right. The basic validator should take
>> all constraints from all the classes into account.
>> John T.E. Timm schrieb:
>>> I suppose this behavior is more related to the way that UML2 generates
>>> an EValidator implementation class to evaluate OCL constraints. Perhaps
>>> the EValidator implementation could also include the validation of an
>>> instance against constraints on its class supertypes. Alternatively, I
>>> could override the default Diagnostician implementation to take into
>>> consideration EValidators for supertypes of a given class.
>>>
>>> Thanks,
>>>
>>> JT
>>>
>>> John T.E. Timm wrote:
>>>
>>>> I have two classes in different packages:
>>>
>>>> package A
>>>> class A
>>>
>>>> package B
>>>> class B -> A
>>>
>>>> Where B is a subclass of A. I have OCL constraints on both classes
>>>> wihch generates an EValidator for both packages. If I attempt to
>>>> validate an instance of class B, I notice that none of the constraints
>>>> attached to class A will fire. Is it possible to trigger these
>>>> constraints? The code in Diagnostician appears to only consider the
>>>> EValidator for package A::class A, iff an EValidator for package
>>>> B::class B does not exist but in my case, I want to validate an
>>>> instance of B against class B AND class A constraints.
>>>
>>>> Thanks,
>>>
>>>> JT
>>>
>>>
|
|
|
| Re: Trigger Parent Consraints from Diagnostician [message #480950 is a reply to message #480869] |
Wed, 19 August 2009 07:03 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
John,
Yes, I was going to point that out. It's important to avoid visiting
the same super type twice in the case of multiple inheritance; that's
why it's done as you see it...
John T.E. Timm schrieb:
> Something I missed yesterday is what is happening in EObject Validator:
>
> List<EClass> eSuperTypes = eClass.getESuperTypes();
> return
> eSuperTypes.isEmpty() ?
> validate_EveryDefaultConstraint(eObject, diagnostics, context) :
> validate(eSuperTypes.get(0), eObject, diagnostics, context);
>
> Apparently, the super types are considered during validation. I must be
> chasing another issue.
>
> Thanks,
>
> JT
>
> John T.E. Timm wrote:
>
>> Looking at the UML2 contribution to codegen of validation-related
>> code, it looks like it uses the stock EMF template without
>> modification. I think the problem actually lies in how Diagnostician
>> finds validators for a given object/class. Specifically the method:
>
>> public boolean validate(EClass eClass, EObject eObject,
>> DiagnosticChain diagnostics, Map<Object, Object> context)
>
>> It appears that this method walks up the inheritance tree looking at
>> classes/packages until it finds a validator and uses the first
>> available. If a validator exists higher in the, it could be ignored.
>> Instead, perhaps, the method should collect all validators for a class
>> and its supertypes and process them in a loop while gathering results.
>> I'm going to take a stab at overriding this method.
>
>> Thanks,
>
>> JT
>
>> Ed Merks wrote:
>
>>> John,
>
>>> Yes, this doesn't sound quite right. The basic validator should take
>>> all constraints from all the classes into account.
>
>
>>> John T.E. Timm schrieb:
>>>> I suppose this behavior is more related to the way that UML2
>>>> generates an EValidator implementation class to evaluate OCL
>>>> constraints. Perhaps the EValidator implementation could also
>>>> include the validation of an instance against constraints on its
>>>> class supertypes. Alternatively, I could override the default
>>>> Diagnostician implementation to take into consideration EValidators
>>>> for supertypes of a given class.
>>>>
>>>> Thanks,
>>>>
>>>> JT
>>>>
>>>> John T.E. Timm wrote:
>>>>
>>>>> I have two classes in different packages:
>>>>
>>>>> package A
>>>>> class A
>>>>
>>>>> package B
>>>>> class B -> A
>>>>
>>>>> Where B is a subclass of A. I have OCL constraints on both classes
>>>>> wihch generates an EValidator for both packages. If I attempt to
>>>>> validate an instance of class B, I notice that none of the
>>>>> constraints attached to class A will fire. Is it possible to
>>>>> trigger these constraints? The code in Diagnostician appears to
>>>>> only consider the EValidator for package A::class A, iff an
>>>>> EValidator for package B::class B does not exist but in my case, I
>>>>> want to validate an instance of B against class B AND class A
>>>>> constraints.
>>>>
>>>>> Thanks,
>>>>
>>>>> JT
>>>>
>>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 20:10:31 GMT 2024
Powered by FUDForum. Page generated in 0.02904 seconds |
] 
Search
Help
Register
Login
Home
