|
|
|
|
|
|
|
|
|
| Re: [EMF Validation] how can i control multiple context? [message #895905 is a reply to message #895854] |
Mon, 16 July 2012 09:12   |
Eclipse User |
|
|
|
Hi,
OK, so Ed's advice applies equally to this validation API. Your best
bet is probably a constraint on the Library class that checks for
uniqueness of all of the names of the Books within it, and another
constraint also on the Library class that checks for uniqueness of all
of the Writers. I suggest separate constraints because these logically
would seem to be separate namespaces. There shouldn't be any problem
having a Book that has a title equal to a Writer's name (it might be a
biography of the writer!).
But, perhaps the library is just an analogy for your specific proprietary case.
Anyhow, if your model has multiple Library instances and you need to
check uniqueness across all libraries, then it gets a bit more
interesting. Do your Libraries comprise a hierarchical containment
structure? If so, the topmost library (the first visited by
validation) can check all of the books and writers in its entire
subtree and then use the
IValidationContext::skipCurrentConstraintFor(…) API to tell the
validation service that the nested libraries have already been checked
and that it can skip them, to avoid redundant calculation and reporting
of problems.
HTH,
Christian
On 2012-07-16 10:29:55 +0000, wiwa wiwa said:
> Yes I asking about org.eclipse.emf.validation API.
> But my main problem that I can't arrive to manipulate several class in
> the same constraint to compare their different instance????
> As I have already said,I want compare the attribute "name" of all
> instance "Writer and Book" to check the duplicated name.
> So ,when the constraint will be execute it must verify that all
> instance (of Book and Writer for example) does not have the same name.
> Thank you for your help (ed Makers and Christian).
|
|
|
|
| Re: [EMF Validation] how can i control multiple context? [message #895939 is a reply to message #895935] |
Mon, 16 July 2012 10:59 |
| Eclipse User |
|
|
|
Do the things you're trying to constrain have a common container? Ecore
itself has constraints not so different, as I already mentioned, e.g.,
the eClassifiers of an EPackage must have unique names. Also, the
eAllStructureFeatures of an eClass, i.e., the ones contained locally and
the ones inherited from the eSuperTypes must be unique. In both these
cases, the constraint is on that container object.
On 16/07/2012 4:37 PM, wiwa wiwa wrote:
> But the Library Model is just an analogue to the example that I treat
> it. So, In the context of my model I need to verify this constraint
> which combine several class at the same time.
> That why I can't seperate this constraint and treat each class aside.
|
|
|
Powered by
FUDForum. Page generated in 0.06459 seconds
Home