Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] emf validation in Papyrus 
Dear Nicholas,

this is quite simple: just follow the tutorial in
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.emf.validation.doc/tutorials/validationTutorial.html
for batch constraints. It is necessary to create a ClientContext, the selector class could for instance just check whether the passed element is a UML model element, e.g. 

public class ValidationDelegateClientSelector implements IClientSelector {
    /**
* Queries whether to select the specified object, which indicates that it 
     * belongs to this client context.
     *
     * @param object a model element of some kind
* @return <code>true</code> if the <code>object</code> matches my client 
     *     context; <code>false</code>, otherwise
     */
    public boolean selects(Object object) {
        return (object instanceof Element);
    }
}
Once registered, your constraints should be checked and lead marked model elements within Papyrus. 

Best regards

Ansgar


On 01/11/2011 02:42 PM, Nicholas Pacini wrote:

Dear Ansgar,

thank you for your reply. I asked about the status of the emf
validation in Papyrus for the following reason:
At the moment i'm working on the CHESS project which relies on the
Papyrus editor. In this project we have defined an UML profile and
several constraints (in OCL and Java) that have to be applied during
the validation of models that comply with our profile.
What we whished to know is how we could link our constraints with your
validation, according to the current implementation of Papyrus.

Thanks for your attention,
Best Regards,
Nicholas

2010/12/24, RADERMACHER Ansgar 206501<Ansgar.RADERMACHER@xxxxxx>:

Dear Nicholas,

I'm not very happy using the internal function, I principally wanted to
avoid to duplicate code that is already present. For additional constraints,
we use the standard EMF extension point, i.e. in the moment I do not see a
need to customize the EValidatorAdapter.
=>  could it be made a non-internal function?
The alternative is to create a minimal EValidatorAdapter in Papyrus.

Btw. I also use the internal Modisco class LinkItem in function
tryChildIfEmpty() of class ValidationTool: in order to know, if it should be
decorated with a marker, I need to know the EObject of the childs.
=>  is there a cleaner way to get the information about the childs?
=>  if not, could LinkItem be made non-internal?

Have a Merry Christmas and a Happy New Year!

Ansgar

-----Original Message-----
From: mdt-papyrus.dev-bounces@xxxxxxxxxxx on behalf of Nicholas Pacini
Sent: Wed 12/22/2010 4:18 PM
To: mdt-papyrus.dev@xxxxxxxxxxx
Subject: [mdt-papyrus.dev] emf validation in Papyrus

dear all,

In the current version of Papyrus i noticed that you are using an
internal class of MoDisco in order to check user-defined rules based
on the emf.validation.constraintProviders extension point.
I was wondering, if possible, if you intend to keep this
implementation or if you are going to develop a custom
EValidatorAdapter within Papyrus in order to add other constraints
without touching a MoDisco plugin.

thanks in advance,
best regards,

Nicholas
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev



_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev




--
Ansgar Radermacher                CEA/DRT/DILS/LISE
http://www-list.cea.fr/index.htm
phone: +33 16908 3812
mailto: ansgar.radermacher@xxxxxx

Back to the top