Home » Modeling » EMF » EMF Validation Framework
|
| Re: EMF Validation Framework [message #418570 is a reply to message #418569] |
Sat, 19 April 2008 15:24   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
AJ,
I suppose it depends on how fancy you want to get with things like live
validation, turning on and off validation of individual constraints, and
so on, or whether the basic facilities suffice for your needs. You'll
get a generated XyzValidator if and only if your model defines
constraints or invariant operations, so if you don't want a generated
validator, you should not define any constraints on the model itself.
Even without a generated validator, basic constraints (as checked by
EObjectValidator, the base class of the generated validators) will still
be available for your instances...
AJ wrote:
> Hi,
>
> My apologies if this has been asked before, but when is more
> appropriate to use the EMF Validation Framework
> (org.eclipse.emf.validation) instead of the EMF diagnostics. In my
> case, I don't need live validation.
>
> Also, is there is any relation between the above implementations and
> the Validator interfaces generated by the EMF generator into
> abc.xyz.validation package? Otherwise, can the generation of these
> interfaces be disable via the GenModel properties?
>
> Thanks!
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EMF Validation Framework [message #418574 is a reply to message #418571] |
Sun, 20 April 2008 10:40 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
AJ,
By basic facilities I mean EObjectValidators or the generated
XzyValidators that produce Diagnostic about violated basic constraints,
i.e., those induced by Ecore itself, such as multiplicity bounds, or by
extended meta data simple type constraints, or about violated user
defined constraints or invariants. Perhaps Chrisitian can give some
more specific advice, but I'd look at the documentation for what the
validation component provides, and if I needed them, I'd used them and
if not, I'd stick to the basic stuff.
AJ wrote:
> Ed,
>
> Please see comments below...
>
>> I suppose it depends on how fancy you want to get with things like live
>> validation, turning on and off validation of individual constraints,
>> and so on
>
> No, I don't need either live validation or turn on and off validation
> of individual constraints. I don't even need to do a rollback if
> validation find errors or warnings. I just want to report them.
>
>> or whether the basic facilities suffice for your needs.
>
> By the basic facilities, do you mean EMF diagnostics and/or
> EObjectValidator?
>
> So, is there any guidance that I can use to determine when it is the
> appropriate use-case to use the EMF Validation Framework
> (org.eclipse.emf.validation) or the EMF diagnostics?
>
> Thanks!
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Validation Framework [message #418585 is a reply to message #418574] |
Mon, 21 April 2008 13:06 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed, AJ,
I think that this thread, so far, makes a convincing argument for AJ to
start with the generated validator. As AJ's application evolves and,
perhaps, some of the capabilities provided by the extended validation
framework become more relevant, a rudimentary integration of generated
constraints is provided via the "EMF" constraint language extension. This
is something that can, I am sure, be much improved upon (it is fairly
cumbersome).
As Ed indicates, a survey of the Developer Guide documentation included in
the EMF Validation Framework SDK (see the Eclipse help viewer) will uncover
all of its capabilities.
Cheers,
Christian
Ed Merks wrote:
> AJ,
>
> By basic facilities I mean EObjectValidators or the generated
> XzyValidators that produce Diagnostic about violated basic constraints,
> i.e., those induced by Ecore itself, such as multiplicity bounds, or by
> extended meta data simple type constraints, or about violated user
> defined constraints or invariants. Perhaps Chrisitian can give some
> more specific advice, but I'd look at the documentation for what the
> validation component provides, and if I needed them, I'd used them and
> if not, I'd stick to the basic stuff.
>
>
> AJ wrote:
>> Ed,
>>
>> Please see comments below...
>>
>>> I suppose it depends on how fancy you want to get with things like live
>>> validation, turning on and off validation of individual constraints,
>>> and so on
>>
>> No, I don't need either live validation or turn on and off validation
>> of individual constraints. I don't even need to do a rollback if
>> validation find errors or warnings. I just want to report them.
>>
>>> or whether the basic facilities suffice for your needs.
>>
>> By the basic facilities, do you mean EMF diagnostics and/or
>> EObjectValidator?
>>
>> So, is there any guidance that I can use to determine when it is the
>> appropriate use-case to use the EMF Validation Framework
>> (org.eclipse.emf.validation) or the EMF diagnostics?
>>
>> Thanks!
>>
|
|
|
| Re: EMF Validation Framework [message #418598 is a reply to message #418585] |
Mon, 21 April 2008 20:48 |
Al B
Messages: 130
Registered: July 2009 |
Senior Member |
|
|
Hi, Christian, Ed,
Thank you both for your comments on this. So, I guess choosing between the
EMF Core SDK and EMF Validation Framework SDK is a matter of preference.
However, Christian, I am not sure if in your last post you're saying that
one is more cumbersome than the other. Would you mind clarifying that?
Another thing that might be confusing to people (at least in my case) is
that in 2005 what is today referred as the EMF Core SDK was once called
the EMF Validation Framework as well. Although, I don't think Christian
was involved back then :-)
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. emf.doc/references/overview/EMF.Validation.html
Anyway, today when you guys refer to the EMF Validation Framework SDK, you
are referring to the one moved from EMFT into EMF, correct?
So, in the event that I use the later EMF Validation Framework SDK and
define an implementation of the IConstraintProvider interface on the
org.eclipse.emf.validation.constraintProviders extension point, can I look
for constraints defined by other language besides OCL (i.e. JavaScript)?
|
|
|
| Re: EMF Validation Framework [message #418602 is a reply to message #418598] |
Mon, 21 April 2008 21:01 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, AJ,
Find some replies in-line, below.
HTH,
Christian
AJ wrote:
> Hi, Christian, Ed,
>
> Thank you both for your comments on this. So, I guess choosing between the
> EMF Core SDK and EMF Validation Framework SDK is a matter of preference.
> However, Christian, I am not sure if in your last post you're saying that
> one is more cumbersome than the other. Would you mind clarifying that?
What I suggested is somewhat cumbersome is only the "EMF"
constraint-language extension that provides delegation of constraints from
the extensible provider framework to the generated constraints in your
model. It is cumbersome because constraints have to be delegated
individually, which means that maintenance is required as the generated
constraints evolve (particularly as more are added to your model).
> Another thing that might be confusing to people (at least in my case) is
> that in 2005 what is today referred as the EMF Core SDK was once called
> the EMF Validation Framework as well. Although, I don't think Christian
> was involved back then :-)
Actually, the extensible framework (erstwhile EMFT component) is actually
*older* than the intrinsic codegen-based validation. It just didn't appear
at Eclipse (in the EMFT project) until after the introduction of the other.
As long as this component was in EMFT, the name wasn't a problem. Now, it's
always a mouthful to attempt a distinct identification. :-)
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. emf.doc/references/overview/EMF.Validation.html
>
> Anyway, today when you guys refer to the EMF Validation Framework SDK, you
> are referring to the one moved from EMFT into EMF, correct?
That's right. The other is included in the EMF SDK; not a separate entity.
> So, in the event that I use the later EMF Validation Framework SDK and
> define an implementation of the IConstraintProvider interface on the
> org.eclipse.emf.validation.constraintProviders extension point, can I look
> for constraints defined by other language besides OCL (i.e. JavaScript)?
You mean the earlier EMF Validation Framework :-)
That's right. I actually had, at one point, prototyped a BeanShell provider
that was pretty cool -- it was actually the genesis of the "extraction
variables" that has since been deprecated (BeanShell provides access to the
last values of local variables of a script, after it has finished).
The SDK developer guide has a page discussing how to plug in your own
constraint language. Post here as you have questions. This is, actually,
fertile ground for contributions! Why should everybody write their own
JavaScript/BeanShell/JRules/etc. plug-in?
|
|
|
Goto Forum:
Current Time: Sat Apr 20 03:02:30 GMT 2024
Powered by FUDForum. Page generated in 0.03545 seconds |
] 
Search
Help
Register
Login
Home
