|emf validation examples [message #26882]
||Thu, 07 June 2007 08:38
Originally posted by: asma.charfi.com|
I am tried to understand the emf validation exemples, so I have some
questions to ask:
in the BatchValidationDelegate class, final IStatus status =
validator.validate(selectedEObjects) this validate method,is it the same
validate method defined in the NonEmptyNamesConstraint class?
if it is, how can the statut returned by this method include information
about other constraints defined in
org.eclipse.emf.validation.examples.adapter or .ocl?
there is only the "OCLValidationExamplePlugin" class! after creating the
constraintProvider, how can this plugin parse and evaluate the constraint ?
it is said in the help that this plugin use the adapter one cause the
adapter implements the Evalidator
I don't really understand this explication (why we did not implements
Evalidator in rhe ocl examples?)
also, I want to know if general validation example did use the adapter one
|Re: emf validation examples [message #27082 is a reply to message #26922]
||Thu, 07 June 2007 13:30
Originally posted by: cdamus.ca.ibm.com|
Hi, Asma, François,
This discussion belongs in the EMF newsgroup, to which I have replied.
The BatchValidationDelegate invokes the validate() method of an IValidator
instance created by the ModelValidationService. The IValidator (more
specifically in this case, an IBatchValidator) finds all of the constraints
that need to be evaluated on the input objects and executes them. It
gathers their resulting IStatuses into a MultiStatus, which it returns to
the client. The IValidator and IModelConstraint/AbstractModelConstraint
types have no other relation than that. See the "The Validation Service"
topic in the EMF Validation Programmer's Guide for more details on that.
The org.eclipse.emf.validation.examples.ocl plug-in demonstrates two
different concepts: how to leverage the framework's support for OCL as a
constraint language in the basic XML-driven constraint provider, and how to
define a custom constraint provider implementation that doesn't get its
constraints from the plugin.xml file. The OCLConstraintProvider
demonstrates the latter, and has nothing to do with the <constraint>
declaration in the plugin.xml that uses an OCL expression. Nothing in this
example plug-in has anything to do with EValidators.
The EValidator is the crux of the EMF core component's validation framework,
the inception of which post-dates the org.eclipse.emf.validation* plug-ins
by more than a year, but which was available in Eclipse for a considerable
time before the latter was contributed. The
org.eclipse.emf.validation.examples.adapter plug-in demonstrates one
possible way to bridge these two completely independent frameworks by
implementing an EValidator that delegates to the ModelValidationService and
converts results from IStatuses to Diagnostics. In general, usage of the
EMF Validation Framework (org.eclipse.emf.validation) has nothing to do
with EValidators, but now that the VF has "graduated" from EMFT to be an
EMF component, this may well change in the future.
François is correct, that basically the definition of constraints boils down
to implementing (by some means) an IModelConstraint or
AbstractModelConstraint that is provided to the system by an
IConstraintProvider, and that is bound to an application context via a
"client context" on the bindings extension point.
Finally, I agree with François that the
org.eclipse.emf.validation.examples.ocl plug-in should not use the same
category as the org.eclipse.emf.validation.examples.adpater plug-in, thus
depending on its client-context binding to activate the constraints. The
consequence is that the .ocl and .adapter examples must be installed and
used together in order for the former to work. They should be made
independent; I have raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=191471 for this.
François Lagarde wrote:
> In the last post, on 06/07 about 10h, "charfi" (charfi asma) wrote:
> charfi> org.eclipse.emf.validation.examples.general: [...] can the
> statut charfi> returned by this method include information about
> other charfi> constraints
> I am sure that others people (christian) could provide a better
> explanation, but according to the tuturial, constraints need to be
> declared by providing a constraintProvider (which call a class extending
> AbstractModelConstraint to evaluate a model element) and a
> constraintProvider, which will bind the former constraints to a context (a
> namespace). That is enough to make "aware" all the available constraints.
> This binding is done thanks to the ID and category in the plugin
> extensions view.
> charfi> -concerning org.eclipse.emf.validation.examples.ocl: there
> is charfi> only the "OCLValidationExamplePlugin" class! after
> creating the charfi> constraintProvider, how can this plugin parse
> and evaluate the charfi> constraint ?
> the OCLConstraintProvider does this job. This constraint provider is
> registered "by hand". It declares the category, categoryID=
> "emf-validation-example/" to be latterly bound.
> But to be frank, I do not know why this constraint provider depends from
> the Adapter. I tried to remove it and declare my own constraint binding
> without success.
> Hopping that I did not say you too much mistakes.
Powered by FUDForum
. Page generated in 0.01965 seconds