Home » Modeling » OCL » About OCL name expressions
|
| Re: About OCL name expressions [message #53861 is a reply to message #53836] |
Tue, 15 April 2008 13:22   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
I'm afraid I don't understand the problem. If the validator doesn't
complain about an OCLExpression not having a name, then why would it
produce a message? Or, do you mean for other problems that may be
reported?
In any case, I don't think that the metaclass name makes sense as a name for
an element. Keep in mind that the client of the Diagnostician can provide
an EValidator::SubstitutionLabelProvider to customize the string
representation of objects in the problem messages. You might use that to
substitute, say, the un-parsed expression text (probably part of it only,
truncated by an ellipsis) for OCLExpressions.
Cheers,
Christian
Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,
>
> Working around the new EValidator infraestructure I have noticed that
> now OCLExpressions may not have a name, and the validator doesn't
> complain about that, That's good ;). However, when there is a problem
> with an OCLExpression itself, the produced message is not clear (a null
> name appears for the unnamed OCLExpressions)
>
> I suggest you overriding getName method from OCLExpressionImpl.
> Something like this:
>
> /* (non-Javadoc)
> * @see org.eclipse.emf.ecore.impl.ENamedElementImpl#getName()
> */
> @Override
> public String getName() {
> String name = super.getName();
> return (name == null) ? eClass().getName() : name;
> }
>
> If you considere it, I could arise an enhancement feature for that ;).
>
> Cheers,
> Adolfo.
|
|
|
| Re: About OCL name expressions [message #53884 is a reply to message #53861] |
Tue, 15 April 2008 14:57 |
 Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Sorry for my bad explanations and my poor knowledge about EValidator
framework;P. Maybe an example would have helped, I'll will explain my
concrete example:
I have a Metaclass VariableInitExp ( -> ImperativeExpression ->
OCLExpression) with a required reference called referredVariable. If
this referredVariable is not set in an instance of it, the Validator
throws the following message error:
Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
required feature 'referredVariable' of
'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody:: <null>'
must be set
This "<null>" value is due to the absence of a name for the
OCLExpression (in this case VariableInitExp). I agree that a lot of
expressions don't need a name, but the main reason for that is that the
own expression is meaningful to identify it, so I think that its
metaclass's name could make sense for all of them...
So, for the previous case we could have the following report:
Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
required feature 'referredVariable' of
'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody::VariableInitExp'
must be set
So when getting the name of every VariableInitExp instance, we could
obtain a proper identifying name. Note that when persisting to a
resource, the name is not serialized since the name is not set at all
(I'm not sure if I have been clear :S).
Besides, if you look at the error reporting, OperationBody is included
as the name for OperationBody's instance (However, it's is not a
NamedElement). I'm not sure of that, but probably this is the policy
(taking its MetaClass name) for all elements which are not NamedElements ...
Anyway for this concrete purpose, perhaps I could achieve a better error
reporting from the validator, making use of that
SubstituionLabelProvider, as you mention. As I said you I'm a newbie
trying to configure the validation of models for a concrete metamodel,
so I don't have a good point to get the better way to solve the problems
with it.
Anyway, a bugzilla enhancement will probably be needed since the OCL
EValidator will not properly report the problems concerning unnamed
OCLExpressions. So it's a problem which will need to be solved.
Cheers,
Adolfo.
Christian W. Damus escribió:
> Hi, Adolfo,
>
> I'm afraid I don't understand the problem. If the validator doesn't
> complain about an OCLExpression not having a name, then why would it
> produce a message? Or, do you mean for other problems that may be
> reported?
>
> In any case, I don't think that the metaclass name makes sense as a name for
> an element. Keep in mind that the client of the Diagnostician can provide
> an EValidator::SubstitutionLabelProvider to customize the string
> representation of objects in the problem messages. You might use that to
> substitute, say, the un-parsed expression text (probably part of it only,
> truncated by an ellipsis) for OCLExpressions.
>
> Cheers,
>
> Christian
>
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> Hi Christian,
>>
>> Working around the new EValidator infraestructure I have noticed that
>> now OCLExpressions may not have a name, and the validator doesn't
>> complain about that, That's good ;). However, when there is a problem
>> with an OCLExpression itself, the produced message is not clear (a null
>> name appears for the unnamed OCLExpressions)
>>
>> I suggest you overriding getName method from OCLExpressionImpl.
>> Something like this:
>>
>> /* (non-Javadoc)
>> * @see org.eclipse.emf.ecore.impl.ENamedElementImpl#getName()
>> */
>> @Override
>> public String getName() {
>> String name = super.getName();
>> return (name == null) ? eClass().getName() : name;
>> }
>>
>> If you considere it, I could arise an enhancement feature for that ;).
>>
>> Cheers,
>> Adolfo.
>
|
|
|
| Re: About OCL name expressions [message #53905 is a reply to message #53884] |
Tue, 15 April 2008 15:21 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
I see. Where did the qualified name come from in the error message? Is
that provided by the default substitution-label provider in the
diagnostician?
The problem with providing a non-null default name is that, unless it is
actually specified as the default in the Ecore model (the OCLExpression
EClass), it will be written out when an expression is serialized. That's
not great, because it should behave consistently like a default, and not be
written.
I think the better approach will be to see whether the '<null>' is provided
by EMF by default, and whether that could be changed (in EMF) to
show '<VariableInitExp>' instead (according to the EClass name). I really
do think the solution needs to be implemented in the validation framework,
not in the metamodel.
Cheers,
Christian
Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,
>
> Sorry for my bad explanations and my poor knowledge about EValidator
> framework;P. Maybe an example would have helped, I'll will explain my
> concrete example:
>
> I have a Metaclass VariableInitExp ( -> ImperativeExpression ->
> OCLExpression) with a required reference called referredVariable. If
> this referredVariable is not set in an instance of it, the Validator
> throws the following message error:
>
> Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
> required feature 'referredVariable' of
> 'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody:: <null>'
> must be set
>
> This "<null>" value is due to the absence of a name for the
> OCLExpression (in this case VariableInitExp). I agree that a lot of
> expressions don't need a name, but the main reason for that is that the
> own expression is meaningful to identify it, so I think that its
> metaclass's name could make sense for all of them...
>
> So, for the previous case we could have the following report:
>
> Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
> required feature 'referredVariable' of
> 'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody::VariableInitExp'
> must be set
>
> So when getting the name of every VariableInitExp instance, we could
> obtain a proper identifying name. Note that when persisting to a
> resource, the name is not serialized since the name is not set at all
> (I'm not sure if I have been clear :S).
>
> Besides, if you look at the error reporting, OperationBody is included
> as the name for OperationBody's instance (However, it's is not a
> NamedElement). I'm not sure of that, but probably this is the policy
> (taking its MetaClass name) for all elements which are not NamedElements
> ...
>
> Anyway for this concrete purpose, perhaps I could achieve a better error
> reporting from the validator, making use of that
> SubstituionLabelProvider, as you mention. As I said you I'm a newbie
> trying to configure the validation of models for a concrete metamodel,
> so I don't have a good point to get the better way to solve the problems
> with it.
>
> Anyway, a bugzilla enhancement will probably be needed since the OCL
> EValidator will not properly report the problems concerning unnamed
> OCLExpressions. So it's a problem which will need to be solved.
>
> Cheers,
> Adolfo.
-----8<-----
|
|
|
| Re: About OCL name expressions [message #53925 is a reply to message #53905] |
Tue, 15 April 2008 16:27 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Christian W. Damus escribió:
> Hi, Adolfo,
>
> I see. Where did the qualified name come from in the error message? Is
> that provided by the default substitution-label provider in the
> diagnostician?
>
Certainly, I don't exactly know, but it should be...Anyway I'll look
into that to have a better point about it (Perhaps Ed Merks, could give
us some help ;P).
What I'm sure:
- Is that the default implementation (substitution-label or whatever)
makes use of the getName() method (from ENamedElement) to display the
errors. I overwrote it, to check it.
> The problem with providing a non-null default name is that, unless it is
> actually specified as the default in the Ecore model (the OCLExpression
> EClass), it will be written out when an expression is serialized. That's
> not great, because it should behave consistently like a default, and not be
> written.
Note that overwriting the getName method to return a no null name for a
oclexpression, is not the same that setting a name for it. So when
saving the element in a Resource, since the field is still set to null,
it will not be serialized. At least that is the conclusion I got when I
checked that my unnamed ImperativeExpressions don't have (serialized)
name after overwriting the getName method ;).
>
> I think the better approach will be to see whether the '<null>' is provided
> by EMF by default, and whether that could be changed (in EMF) to
> show '<VariableInitExp>' instead (according to the EClass name). I really
> do think the solution needs to be implemented in the validation framework,
> not in the metamodel.
Yes, I agree. It would probably be better working around the
OCLValidator (and the displayed messages), at least to solve this
concrete issue. I don't know if there will be more problems surrounding
the unnamed OCL Expressions.
Anyway, I'll arise a bugzilla bug relating that OCL EValidator doesn't
properly display errors when dealing with unnamed OCL Expressions. And
I'll look into the diagnostician reporting error.
Cheers,
Adolfo.
>
> Cheers,
>
> Christian
>
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> Hi Christian,
>>
>> Sorry for my bad explanations and my poor knowledge about EValidator
>> framework;P. Maybe an example would have helped, I'll will explain my
>> concrete example:
>>
>> I have a Metaclass VariableInitExp ( -> ImperativeExpression ->
>> OCLExpression) with a required reference called referredVariable. If
>> this referredVariable is not set in an instance of it, the Validator
>> throws the following message error:
>>
>> Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
>> required feature 'referredVariable' of
>> 'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody:: <null>'
>> must be set
>>
>> This "<null>" value is due to the absence of a name for the
>> OCLExpression (in this case VariableInitExp). I agree that a lot of
>> expressions don't need a name, but the main reason for that is that the
>> own expression is meaningful to identify it, so I think that its
>> metaclass's name could make sense for all of them...
>>
>> So, for the previous case we could have the following report:
>>
>> Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
>> required feature 'referredVariable' of
>> 'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody::VariableInitExp'
>> must be set
>>
>> So when getting the name of every VariableInitExp instance, we could
>> obtain a proper identifying name. Note that when persisting to a
>> resource, the name is not serialized since the name is not set at all
>> (I'm not sure if I have been clear :S).
>>
>> Besides, if you look at the error reporting, OperationBody is included
>> as the name for OperationBody's instance (However, it's is not a
>> NamedElement). I'm not sure of that, but probably this is the policy
>> (taking its MetaClass name) for all elements which are not NamedElements
>> ...
>>
>> Anyway for this concrete purpose, perhaps I could achieve a better error
>> reporting from the validator, making use of that
>> SubstituionLabelProvider, as you mention. As I said you I'm a newbie
>> trying to configure the validation of models for a concrete metamodel,
>> so I don't have a good point to get the better way to solve the problems
>> with it.
>>
>> Anyway, a bugzilla enhancement will probably be needed since the OCL
>> EValidator will not properly report the problems concerning unnamed
>> OCLExpressions. So it's a problem which will need to be solved.
>>
>> Cheers,
>> Adolfo.
>
> -----8<-----
|
|
| | |
Goto Forum:
Current Time: Wed Sep 18 16:44:24 GMT 2024
Powered by FUDForum. Page generated in 0.03385 seconds |
] 
Search
Help
Register
Login
Home
