Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » architectural approach
architectural approach [message #420797] Thu, 10 July 2008 14:17 Go to next message
Sam Julian is currently offline Sam JulianFriend
Messages: 29
Registered: July 2009
Junior Member
I am impressed by EMF and this community a great service Ed and friends!

I want for each IStructuredSelection, or each EObject (Depending on the
dataType) to define a global "Rule-Validate-Config.xml" file and bind each
Selection to its own Validator File.
based on the EMF Validation Framework. How would an clean and EMF Komform
architectural approach look like?

Thank you for your Council,

Sam
Re: architectural approach [message #420799 is a reply to message #420797] Thu, 10 July 2008 14:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
Sam,

Comments below.

Sam wrote:
> I am impressed by EMF and this community a great service Ed and friends!
I have more and more good friends too. It's a very rewarding thing to
watch a community grow and thrive.
>
> I want for each IStructuredSelection, or each EObject (Depending on
> the dataType) to define a global "Rule-Validate-Config.xml" file and
> bind each Selection to its own Validator File.
> based on the EMF Validation Framework. How would an clean and EMF
> Komform architectural approach look like?
This sounds like a question for super-Christian, also known as
give-a-damus. :-P
> Thank you for your Council,
>
> Sam
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: architectural approach [message #420801 is a reply to message #420799] Thu, 10 July 2008 14:36 Go to previous messageGo to next message
Sam Julian is currently offline Sam JulianFriend
Messages: 29
Registered: July 2009
Junior Member
hi Ed,

where can I ask super-Christian for advice? (is there a separate list for
EMF Validation Framework?)

thanks for this support,
Sam
Re: architectural approach [message #420804 is a reply to message #420801] Thu, 10 July 2008 15:00 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
Sam,

Christian monitors this newsgroup, though not quite as compulsively as I
do. He has a real job. :-P


Sam wrote:
> hi Ed,
>
> where can I ask super-Christian for advice? (is there a separate list
> for EMF Validation Framework?)
>
> thanks for this support,
> Sam
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: architectural approach [message #420810 is a reply to message #420804] Thu, 10 July 2008 15:26 Go to previous messageGo to next message
Sam Julian is currently offline Sam JulianFriend
Messages: 29
Registered: July 2009
Junior Member
Hi Ed,

I understand, you enjoy the other side of life.
Cheers,
Sam
Re: architectural approach [message #420812 is a reply to message #420797] Thu, 10 July 2008 15:54 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

--=-1TeOpgb7ejRfq5h3lkT7
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Sam,

I wouldn't call myself "super" but perhaps I can reply usefully.

I was actually thinking that I should add a constraint-provider in the
1.3 release that models the constraint meta-data required by the
framework in an Ecore model. It would load instances of this model from
any URI (XMI resource deployed in the plug-in, http: URI on the web, or
even a CDO resource from a repository). See this bug for details:

https://bugs.eclipse.org/240352

I don't know about the structured-selection; wouldn't it just contain a
bunch of EObjects selected in your editor?

The most obvious approach to binding constraints to the selection is to
have the constraint objects in the validation model reference the
EClasses to which they apply (a "context" EReference of type EClass).

If you want to wait a few months, I hope to have a prototype this
autumn. Otherwise, you are, of course, welcome to contribute to the
effort!

Cheers,

Christian


On Thu, 2008-07-10 at 14:17 +0000, Sam wrote:

> I am impressed by EMF and this community a great service Ed and friends!
>
> I want for each IStructuredSelection, or each EObject (Depending on the
> dataType) to define a global "Rule-Validate-Config.xml" file and bind each
> Selection to its own Validator File.
> based on the EMF Validation Framework. How would an clean and EMF Komform
> architectural approach look like?
>
> Thank you for your Council,
>
> Sam
>

--=-1TeOpgb7ejRfq5h3lkT7
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Sam,<BR>
<BR>
I wouldn't call myself &quot;super&quot; but perhaps I can reply usefully.<BR>
<BR>
I was actually thinking that I should add a constraint-provider in the 1.3 release that models the constraint meta-data required by the framework in an Ecore model.&nbsp; It would load instances of this model from any URI (XMI resource deployed in the plug-in, http: URI on the web, or even a CDO resource from a repository).&nbsp; See this bug for details:<BR>
<BR>
<A HREF="https://bugs.eclipse.org/bugs/show_bug.cgi?id=240352">https://bugs.eclipse.org/240352</A><BR>
<BR>
I don't know about the structured-selection; wouldn't it just contain a bunch of EObjects selected in your editor?<BR>
<BR>
The most obvious approach to binding constraints to the selection is to have the constraint objects in the validation model reference the EClasses to which they apply (a &quot;context&quot; EReference of type EClass).<BR>
<BR>
If you want to wait a few months, I hope to have a prototype this autumn.&nbsp; Otherwise, you are, of course, welcome to contribute to the effort!<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Thu, 2008-07-10 at 14:17 +0000, Sam wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">I am impressed by EMF and this community a great service Ed and friends!</FONT>
<FONT COLOR="#000000"> </FONT>
<FONT COLOR="#000000">I want for each IStructuredSelection, or each EObject (Depending on the </FONT>
<FONT COLOR="#000000">dataType) to define a global &quot;Rule-Validate-Config.xml&quot; file and bind each </FONT>
<FONT COLOR="#000000">Selection to its own Validator File.</FONT>
<FONT COLOR="#000000">based on the EMF Validation Framework. How would an clean and EMF Komform </FONT>
<FONT COLOR="#000000">architectural approach look like? </FONT>

<FONT COLOR="#000000">Thank you for your Council,</FONT>

<FONT COLOR="#000000">Sam</FONT>

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-1TeOpgb7ejRfq5h3lkT7--
Re: architectural approach [message #420813 is a reply to message #420812] Thu, 10 July 2008 16:54 Go to previous messageGo to next message
Sam Julian is currently offline Sam JulianFriend
Messages: 29
Registered: July 2009
Junior Member
Hi Christian,
---
I don't know about the structured-selection; wouldn't it just contain a
bunch of EObjects selected in your editor?
--
1- Exactly, iterate over this editor's EObject elements.

depending on the EDataType of the EObject, an XML (validation-rule.config)
file must be bind to the Selection.

--
The most obvious approach to binding constraints to the selection is to
have the constraint objects in the validation model reference the
EClasses to which they apply (a "context" EReference of type EClass).
--
2- How to get the constraint object in the Validation model
3- Can you give more details on this issue please?



If you want to wait a few months, I hope to have a prototype this
autumn. Otherwise, you are, of course, welcome to contribute to the
effort!
I will do my best!

Cheers,
Sam
Re: architectural approach [message #420815 is a reply to message #420813] Thu, 10 July 2008 21:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

--=-Gn83Mr6f0mczsfl55ie6
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Sam,

Find some replies in-line, below.

HTH,

Christian


On Thu, 2008-07-10 at 16:54 +0000, Sam wrote:

> Hi Christian,
> ---
> I don't know about the structured-selection; wouldn't it just contain a
> bunch of EObjects selected in your editor?
> --
> 1- Exactly, iterate over this editor's EObject elements.


OK, that's what I figured. You can actually validate them as a group in
a single call to the IValidator, for efficiency.


> depending on the EDataType of the EObject, an XML (validation-rule.config)
> file must be bind to the Selection.
>
> --
> The most obvious approach to binding constraints to the selection is to
> have the constraint objects in the validation model reference the
> EClasses to which they apply (a "context" EReference of type EClass).
> --
> 2- How to get the constraint object in the Validation model


Well, that's the constraint-provider's job. The framework calls on an
IModelConstraintProvider to give it IModelConstraints to evaluate. It's
up the to provider to determine how to instantiate these constraint
objects.

An example of a "dynamic constraint provider" (which is the kind of
provider you're looking to build) is the OCLConstraintProvider defined
in the OCL validation example plug-in:
org.eclipse.emf.validation.examples.ocl. Install this in your workspace
using the "New Example..." wizard, selecting the "OCL Example" in the
"EMF Validation Framework" category.


> 3- Can you give more details on this issue please?


This isn't a small subject. It's a reasonably big job to create a
constraint provider.

The EMF Validation Framework SDK includes a fairly comprehensive
Developer Guide documentation in the Eclipse Help viewer. It includes
descriptions of how to accomplish common tasks (such as this), the API
and extension point documentation, tutorials, and guides to using the
examples. These are the details that I would write in response to this
post, but I don't have to because I wrote them already in the SDK :-)

Once you have looked through the guide and played with the OCL example
to see how it works, follow up to the newsgroup with any more specific
questions that you may have.


>
>
>
> If you want to wait a few months, I hope to have a prototype this
> autumn. Otherwise, you are, of course, welcome to contribute to the
> effort!
> I will do my best!
>
> Cheers,
> Sam
>

--=-Gn83Mr6f0mczsfl55ie6
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Sam,<BR>
<BR>
Find some replies in-line, below.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Thu, 2008-07-10 at 16:54 +0000, Sam wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Christian,</FONT>
<FONT COLOR="#000000">---</FONT>
<FONT COLOR="#000000">I don't know about the structured-selection; wouldn't it just contain a</FONT>
<FONT COLOR="#000000">bunch of EObjects selected in your editor?</FONT>
<FONT COLOR="#000000">--</FONT>
<FONT COLOR="#000000">1- Exactly, iterate over this editor's EObject elements.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
OK, that's what I figured.&nbsp; You can actually validate them as a group in a single call to the IValidator, for efficiency.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">depending on the EDataType of the EObject, an XML (validation-rule.config) </FONT>
<FONT COLOR="#000000">file must be bind to the Selection.</FONT>

<FONT COLOR="#000000">--</FONT>
<FONT COLOR="#000000">The most obvious approach to binding constraints to the selection is to</FONT>
<FONT COLOR="#000000">have the constraint objects in the validation model reference the</FONT>
<FONT COLOR="#000000">EClasses to which they apply (a &quot;context&quot; EReference of type EClass).</FONT>
<FONT COLOR="#000000">--</FONT>
<FONT COLOR="#000000">2- How to get the constraint object in the Validation model</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Well, that's the constraint-provider's job.&nbsp; The framework calls on an IModelConstraintProvider to give it IModelConstraints to evaluate.&nbsp; It's up the to provider to determine how to instantiate these constraint objects.<BR>
<BR>
An example of a &quot;dynamic constraint provider&quot; (which is the kind of provider you're looking to build) is the OCLConstraintProvider defined in the OCL validation example plug-in:&nbsp; org.eclipse.emf.validation.examples.ocl.&nbsp; Install this in your workspace using the &quot;New Example...&quot; wizard, selecting the &quot;OCL Example&quot; in the &quot;EMF Validation Framework&quot; category.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">3- Can you give more details on this issue please?</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
This isn't a small subject.&nbsp; It's a reasonably big job to create a constraint provider.<BR>
<BR>
The EMF Validation Framework SDK includes a fairly comprehensive Developer Guide documentation in the Eclipse Help viewer.&nbsp; It includes descriptions of how to accomplish common tasks (such as this), the API and extension point documentation, tutorials, and guides to using the examples.&nbsp; These are the details that I would write in response to this post, but I don't have to because I wrote them already in the SDK&nbsp; :-)<BR>
<BR>
Once you have looked through the guide and played with the OCL example to see how it works, follow up to the newsgroup with any more specific questions that you may have.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>



<FONT COLOR="#000000">If you want to wait a few months, I hope to have a prototype this</FONT>
<FONT COLOR="#000000">autumn. Otherwise, you are, of course, welcome to contribute to the</FONT>
<FONT COLOR="#000000">effort!</FONT>
<FONT COLOR="#000000">I will do my best!</FONT>

<FONT COLOR="#000000">Cheers,</FONT>
<FONT COLOR="#000000"> Sam</FONT>

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-Gn83Mr6f0mczsfl55ie6--
Re: architectural approach [message #420819 is a reply to message #420815] Fri, 11 July 2008 08:57 Go to previous messageGo to next message
Sam Julian is currently offline Sam JulianFriend
Messages: 29
Registered: July 2009
Junior Member
Hi Christian,

1- for clarification; the purpose is to let myXSDModel and GenModel
untouched. no restriction will be done in the model like the Schema Based
Constraint. Depending on the EDataType of the selected EObject, a
RulesEngine will decide, wich Validation-Rule must be applied. and give
the Result of this Validation back to the "Viewer". What I have is at the
one Side the Validation model as XML Shema or what ever and on the other
side the generated EMF-model(Code).
What I am looking for is a pointer to the adequate way to combine those
two model via so-called Rules-Engine-Provider.

The main question is, can where we have to extend the Generated Code to
get the best architural solution?

--
OK, that's what I figured. You can actually validate them as a group in
a single call to the IValidator, for efficiency.
--
2- The EObject are different "EDataType", so the Validation I want to
implement, its depends on external spec. Rules that should have take
control of the selected EObject. This means that several XML-Rules-Files
will be involved. i didnŽt test this till now.

Do you think that we can preserve the efficiency at a good Value?

3- I will studie the "dynamic constraint provider" and look if its
fullfill my technical requirement.

--
Once you have looked through the guide and played with the OCL example
to see how it works, follow up to the newsgroup with any more specific
questions that you may have.
--
4- I will follow your proposal.

For comments, I am gratfull

Thank you very much!
Re: architectural approach [message #420844 is a reply to message #420819] Sat, 12 July 2008 18:52 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

--=-2J9M05yazFB1aPSUhxL2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi, Sam,

See some replies in-line, below.

HTH,

Christian

On Fri, 2008-07-11 at 08:57 +0000, Sam wrote:

> Hi Christian,
>=20
> 1- for clarification; the purpose is to let myXSDModel and GenModel=20
> untouched. no restriction will be done in the model like the Schema Based=
=20
> Constraint. Depending on the EDataType of the selected EObject, a=20

Right. That's the point of the EMF Validation Framework component: to
define constrants externally to the model. For intrinsic constraints,
you might use the generative EValidator approach, but that would modify
your models. So this seems like a good fit.


> RulesEngine will decide, wich Validation-Rule must be applied. and give=20

That's what the EMF Validation Framework does: it finds constraints
that are contributed on its extension point, that "target" specific
EClasses (note that EObjects are instances of EClasses, not EDataTypes).


> the Result of this Validation back to the "Viewer". What I have is at the=
=20

The standard approach in an Eclipse IDE workbench is to create problem
markers to be shown in the Problems View (the validation framework can
help with that) and problem decorations in your views (Eclipse UI has
API for that).


> one Side the Validation model as XML Shema or what ever and on the other=20
> side the generated EMF-model(Code).
> What I am looking for is a pointer to the adequate way to combine those=20
> two model via so-called Rules-Engine-Provider.

The EMF Validation Framework has a construct called a "constraint
provider" contributed on the
org.eclipse.emf.validation.constraintProviders extension point. It
sounds like what you're looking for.


> The main question is, can where we have to extend the Generated Code to=20
> get the best architural solution?=20


I don't know about the best solution, but we do provide a solution.


> --
> OK, that's what I figured. You can actually validate them as a group in
> a single call to the IValidator, for efficiency.
> --
> 2- The EObject are different "EDataType", so the Validation I want to=20
> implement, its depends on external spec. Rules that should have take=20
> control of the selected EObject. This means that several XML-Rules-Files=20
> will be involved. i didn=C5=BDt test this till now.

Right. As I said, this is the primary requirement satisfied by the EMF
Validation Framework component. You can even put your rules straight
into the plugin.xml if you want to.


> Do you think that we can preserve the efficiency at a good Value?


Well, the framework tries to be efficient. To a large extent the
efficiency will depend also on the complexity of the rules that you
write. I can't comment on efficiency without more information about
your rules, but ultimately you'll have to measure that, anyway, using a
good profiling tool.


> 3- I will studie the "dynamic constraint provider" and look if its=20
> fullfill my technical requirement.
>=20
> --
> Once you have looked through the guide and played with the OCL example
> to see how it works, follow up to the newsgroup with any more specific
> questions that you may have.
> --
> 4- I will follow your proposal.
>=20
> For comments, I am gratfull
> =20
> Thank you very much!=20
>=20

--=-2J9M05yazFB1aPSUhxL2
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Sam,<BR>
<BR>
See some replies in-line, below.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Fri, 2008-07-11 at 08:57 +0000, Sam wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Christian,</FONT>

<FONT COLOR="#000000">1- for clarification; the purpose is to let myXSDModel and GenModel </FONT>
<FONT COLOR="#000000">untouched. no restriction will be done in the model like the Schema Based </FONT>
<FONT COLOR="#000000">Constraint. Depending on the EDataType of the selected EObject, a </FONT>
</PRE>
</BLOCKQUOTE>
Right.&nbsp; That's the point of the EMF Validation Framework component:&nbsp; to define constrants externally to the model.&nbsp; For intrinsic constraints, you might use the generative EValidator approach, but that would modify your models.&nbsp; So this seems like a good fit.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">RulesEngine will decide, wich Validation-Rule must be applied. and give </FONT>
</PRE>
</BLOCKQUOTE>
That's what the EMF Validation Framework does:&nbsp; it finds constraints that are contributed on its extension point, that &quot;target&quot; specific EClasses (note that EObjects are instances of EClasses, not EDataTypes).<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">the Result of this Validation back to the &quot;Viewer&quot;. What I have is at the </FONT>
</PRE>
</BLOCKQUOTE>
The standard approach in an Eclipse IDE workbench is to create problem markers to be shown in the Problems View (the validation framework can help with that) and problem decorations in your views (Eclipse UI has API for that).<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">one Side the Validation model as XML Shema or what ever and on the other </FONT>
<FONT COLOR="#000000">side the generated EMF-model(Code).</FONT>
<FONT COLOR="#000000">What I am looking for is a pointer to the adequate way to combine those </FONT>
<FONT COLOR="#000000">two model via so-called Rules-Engine-Provider.</FONT>
</PRE>
</BLOCKQUOTE>
The EMF Validation Framework has a construct called a &quot;constraint provider&quot; contributed on the org.eclipse.emf.validation.constraintProviders extension point.&nbsp; It sounds like what you're looking for.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">The main question is, can where we have to extend the Generated Code to </FONT>
<FONT COLOR="#000000">get the best architural solution? </FONT>
</PRE>
</BLOCKQUOTE>
<BR>
I don't know about the best solution, but we do provide a solution.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">--</FONT>
<FONT COLOR="#000000">OK, that's what I figured. You can actually validate them as a group in</FONT>
<FONT COLOR="#000000">a single call to the IValidator, for efficiency.</FONT>
<FONT COLOR="#000000">--</FONT>
<FONT COLOR="#000000">2- The EObject are different &quot;EDataType&quot;, so the Validation I want to </FONT>
<FONT COLOR="#000000">implement, its depends on external spec. Rules that should have take </FONT>
<FONT COLOR="#000000">control of the selected EObject. This means that several XML-Rules-Files </FONT>
<FONT COLOR="#000000">will be involved. i didn&#381;t test this till now.</FONT>
</PRE>
</BLOCKQUOTE>
Right.&nbsp; As I said, this is the primary requirement satisfied by the EMF Validation Framework component.&nbsp; You can even put your rules straight into the plugin.xml if you want to.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Do you think that we can preserve the efficiency at a good Value?</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Well, the framework tries to be efficient.&nbsp; To a large extent the efficiency will depend also on the complexity of the rules that you write.&nbsp; I can't comment on efficiency without more information about your rules, but ultimately you'll have to measure that, anyway, using a good profiling tool.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">3- I will studie the &quot;dynamic constraint provider&quot; and look if its </FONT>
<FONT COLOR="#000000">fullfill my technical requirement.</FONT>

<FONT COLOR="#000000">--</FONT>
<FONT COLOR="#000000">Once you have looked through the guide and played with the OCL example</FONT>
<FONT COLOR="#000000">to see how it works, follow up to the newsgroup with any more specific</FONT>
<FONT COLOR="#000000">questions that you may have.</FONT>
<FONT COLOR="#000000">--</FONT>
<FONT COLOR="#000000">4- I will follow your proposal.</FONT>

<FONT COLOR="#000000">For comments, I am gratfull</FONT>
<FONT COLOR="#000000"> </FONT>
<FONT COLOR="#000000">Thank you very much! </FONT>

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-2J9M05yazFB1aPSUhxL2--
Re: architectural approach [message #420845 is a reply to message #420844] Sat, 12 July 2008 20:06 Go to previous messageGo to next message
Sam Julian is currently offline Sam JulianFriend
Messages: 29
Registered: July 2009
Junior Member
Hi Christian,

For your statement and answers, i say THANKS.
I think, some question will follow.

Sam
Re: architectural approach [message #420846 is a reply to message #420845] Sat, 12 July 2008 22:12 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33137
Registered: July 2009
Senior Member
Sam,

You can see now why I've characterized him the way I did! :-P


Sam wrote:
> Hi Christian,
>
> For your statement and answers, i say THANKS.
> I think, some question will follow.
>
> Sam
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: architectural approach [message #420906 is a reply to message #420844] Wed, 16 July 2008 10:35 Go to previous messageGo to next message
Sam Julian is currently offline Sam JulianFriend
Messages: 29
Registered: July 2009
Junior Member
Hi Christian,

--- ... constraints that are contributed on its extension point, that
"target" specific EClasses (note that EObjects are instances of EClasses,
not EDataTypes).---

1- It is possible to "target" a specific EAttribute instead of EClasse?
The use case is to assign specific Rule to EAttribute. According to
"Library target = (Library) ctx.getTarget();" the getTarget() is signed in
the Plugin.XML.

2- How do the logic in findLibrariesWithName(target.getName()) look like?

Thank you!
Sam
Re: architectural approach [message #420934 is a reply to message #420906] Wed, 16 July 2008 18:11 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

--=-z15BQadGp8tKXDill5PT
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Sam,

1. The "batch" mode of validation maps constraints to EClasses, not to
EAttributes. The assumption is that, since batch validation is intended
to check the rules for a tree of objects (often all of the objects in a
resource), you would want to evaluate all of the constraints that are
defined for each object (identified by EClass).

I guess that you're looking to associate a constraint with an EAttribute
so that any object that has this EAttribute will evaluate the
constraint? Only one EClass can own an EAttribute, anyway, so you can
just associate the constraint with that EClass. Then any instance of
that EClass (including subclasses) will evaluate that constraint.

2. Do you mean the code in the example? If you create the example
project in your workspace, then the code is right there for you to see.
I don't understand.

cW


On Wed, 2008-07-16 at 10:35 +0000, Sam wrote:

> Hi Christian,
>
> --- ... constraints that are contributed on its extension point, that
> "target" specific EClasses (note that EObjects are instances of EClasses,
> not EDataTypes).---
>
> 1- It is possible to "target" a specific EAttribute instead of EClasse?
> The use case is to assign specific Rule to EAttribute. According to
> "Library target = (Library) ctx.getTarget();" the getTarget() is signed in
> the Plugin.XML.
>
> 2- How do the logic in findLibrariesWithName(target.getName()) look like?
>
> Thank you!
> Sam
>

--=-z15BQadGp8tKXDill5PT
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Sam,<BR>
<BR>
1.&nbsp; The &quot;batch&quot; mode of validation maps constraints to EClasses, not to EAttributes.&nbsp; The assumption is that, since batch validation is intended to check the rules for a tree of objects (often all of the objects in a resource), you would want to evaluate all of the constraints that are defined for each object (identified by EClass).<BR>
<BR>
I guess that you're looking to associate a constraint with an EAttribute so that any object that has this EAttribute will evaluate the constraint?&nbsp; Only one EClass can own an EAttribute, anyway, so you can just associate the constraint with that EClass.&nbsp; Then any instance of that EClass (including subclasses) will evaluate that constraint.<BR>
<BR>
2.&nbsp; Do you mean the code in the example?&nbsp; If you create the example project in your workspace, then the code is right there for you to see.&nbsp; I don't understand.<BR>
<BR>
cW<BR>
<BR>
<BR>
On Wed, 2008-07-16 at 10:35 +0000, Sam wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Christian,</FONT>

<FONT COLOR="#000000">--- ... constraints that are contributed on its extension point, that </FONT>
<FONT COLOR="#000000">&quot;target&quot; specific EClasses (note that EObjects are instances of EClasses, </FONT>
<FONT COLOR="#000000">not EDataTypes).---</FONT>

<FONT COLOR="#000000">1- It is possible to &quot;target&quot; a specific EAttribute instead of EClasse? </FONT>
<FONT COLOR="#000000">The use case is to assign specific Rule to EAttribute. According to </FONT>
<FONT COLOR="#000000">&quot;Library target = (Library) ctx.getTarget();&quot; the getTarget() is signed in </FONT>
<FONT COLOR="#000000">the Plugin.XML. </FONT>

<FONT COLOR="#000000">2- How do the logic in findLibrariesWithName(target.getName()) look like?</FONT>

<FONT COLOR="#000000">Thank you!</FONT>
<FONT COLOR="#000000"> Sam</FONT>

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-z15BQadGp8tKXDill5PT--
Previous Topic:xs:choice and inheritance
Next Topic:ResourceSetListener : Command cancel issue
Goto Forum:
  


Current Time: Fri Apr 19 13:49:51 GMT 2024

Powered by FUDForum. Page generated in 0.02561 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top