Home » Modeling » OCL » CollectionItem -> item direct edition
| CollectionItem -> item direct edition [message #51279] |
Wed, 27 February 2008 21:12  |
Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hello!
The 'item : OCLExpression' property of CollectionItem is marked as not
much editable in the OCL.genmodel file. I would have expected the
Edit: 'children' and 'createChildCreate Child' fields to be set to true.
Otherwise I cannot fulfill my own OCL models by hand in the editor and I am
forced to revert to a XMI text editor if I want to set any value
to this property.
The same happens with CollectionRange -> 'first' and 'last' properties.
I'm not sure if there are other similar cases. Is that acknowledged?
Intended? I can change the genmodel myself and regenerate, but I would be
more confident if such (subtle?) changes would end up in the OCL
project's mainstream releases.
Thank you very much!
Victor Sánchez
|
|
|
| Re: CollectionItem -> item direct edition [message #51416 is a reply to message #51279] |
Thu, 28 February 2008 14:25  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
I would have expected the GenModel to have these properties set as you
expect, because they are the default settings for containment references.
I wonder whether this is because these features have multiplicity 1?
You might add comments to this enhancement request:
https://bugs.eclipse.org/196973
or raise a new bug to capture these issues, and we'll see about sorting it
out.
HTH,
Christian
Victor Sanchez wrote:
> Hello!
>
> The 'item : OCLExpression' property of CollectionItem is marked as not
> much editable in the OCL.genmodel file. I would have expected the
> Edit: 'children' and 'createChildCreate Child' fields to be set to true.
> Otherwise I cannot fulfill my own OCL models by hand in the editor and I
> am forced to revert to a XMI text editor if I want to set any value
> to this property.
>
> The same happens with CollectionRange -> 'first' and 'last' properties.
> I'm not sure if there are other similar cases. Is that acknowledged?
> Intended? I can change the genmodel myself and regenerate, but I would be
> more confident if such (subtle?) changes would end up in the OCL
> project's mainstream releases.
>
> Thank you very much!
>
> Victor Sánchez
|
|
|
| Re: CollectionItem -> item direct edition [message #51545 is a reply to message #51416] |
Thu, 28 February 2008 17:56 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hello, Christian! Replies inline.
On Thu, 28 Feb 2008 09:25:19 -0500, Christian W. Damus wrote:
> Hi, Victor,
>
> I would have expected the GenModel to have these properties set as you
> expect, because they are the default settings for containment references.
> I wonder whether this is because these features have multiplicity 1?
Sincerely I doubt that, but mere speculation does not lead anywhere. My
suspect is that this GenModel may be containing old remnants from earlier
versions (put it up to 1.0.x, before any generics' refactoring). I have
had similar experiences with old .genmodel files.
> You might add comments to this enhancement request:
>
> https://bugs.eclipse.org/196973
>
> or raise a new bug to capture these issues, and we'll see about sorting
> it out.
Yes, you are right, it has very much to do with this bug. I suppose I
could add these issues to it, but I think it would be easier for
you to treat it separately, since changes are very straightforward.
On the other hand, I didn't remember that bug (yes, this one I was aware of
at the time). :) This reminds me that I had a contribution to make to the
OCL project. What do you think about a redefinition of the text provided
by each and every node in an OCL model, so it closely resembles the
original concrete syntax? This redefinition is not trivially accomplished,
because each node has to gather information from its children to assemble
the proper text. For instance, an OperationCallExp would need to assemble
the 'source' part, the 'argument' part, aside from the name of the
referred operation. Since navigating through children is delicate due to
lack of Java interfaces providing multiple inheritance to item provider
adapters generated by the Genmodel, I have had to devise a proper design
that copes with these concerns.
Since this text redefinition has to do with integral support to QVT,
support is currently limited to the Essential OCL contents
(only IteratorExp is still missing proper support, and perhaps
other minor details as well). The good news is that it is highly
customizable and can easily made extensible to any other metatype to
participate in such customizations.
Also I have only made text redefinitions for the ocl.ecore project, which
comes along with two new Java packages per original package. To test it
you only have to install the corresponding ocl.ecore Edit, which does not
contain anything else than the generated contents via the Genmodel plus
manual text modifications. And to generate the ocl.ecore Editor plugin as
well, in order to navigate models in a Sample Ecore Model Editor.
Since this work comes out of my PhD work, it is ok for my company for me to
make such a contribution to the OCL project, as long as the company's name
is also mentioned somewhere in the source code. What I don't know is how
to make that contribution. I suppose I have to comply with some guidelines
in the header of each redefined java file or something. Could anybody help
me on that matter? I have generated the Edit plugin with OCL 1.2 M5. I
could attach it as is to the abovementioned bug for you to test it, if you
like, since diff over a non-existing previous version does not have much
sense. Still you could generate the Edit plugin by yourself and somehow
check the manual changes and additions, which are all marked as 'generated
NOT' tag in their javadoc.
See you!
Victor Sánchez
> HTH,
>
> Christian
>
>
> Victor Sanchez wrote:
>
>> Hello!
>>
>> The 'item : OCLExpression' property of CollectionItem is marked as not
>> much editable in the OCL.genmodel file. I would have expected the Edit:
>> 'children' and 'createChildCreate Child' fields to be set to true.
>> Otherwise I cannot fulfill my own OCL models by hand in the editor and
>> I am forced to revert to a XMI text editor if I want to set any value
>> to this property.
>>
>> The same happens with CollectionRange -> 'first' and 'last' properties.
>> I'm not sure if there are other similar cases. Is that acknowledged?
>> Intended? I can change the genmodel myself and regenerate, but I would
>> be more confident if such (subtle?) changes would end up in the OCL
>> project's mainstream releases.
>>
>> Thank you very much!
>>
>> Victor Sánchez
|
|
| |
| Re: CollectionItem -> item direct edition [message #51741 is a reply to message #51545] |
Fri, 29 February 2008 18:55 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
More replies in-line, below.
cW
Victor Sanchez wrote:
> Hello, Christian! Replies inline.
>
> On Thu, 28 Feb 2008 09:25:19 -0500, Christian W. Damus wrote:
>
>> Hi, Victor,
>>
>> I would have expected the GenModel to have these properties set as you
>> expect, because they are the default settings for containment references.
>> I wonder whether this is because these features have multiplicity 1?
>
> Sincerely I doubt that, but mere speculation does not lead anywhere. My
> suspect is that this GenModel may be containing old remnants from earlier
> versions (put it up to 1.0.x, before any generics' refactoring). I have
> had similar experiences with old .genmodel files.
Yes, that's exactly what happened, here. These are properties that were
erroneously indicated as non-containment references and fixed, a long time
ago. The genmodel was not subsequently updated.
By coincidence, in developing new UML models, I found that singular
containment references were showing up the same way in the genmodel, my
generated Edit code didn't include new-child-descriptors for them, but the
editor worked as expected nonetheless. Despite the incorrect genmodel,
something was making my editor work. Hence my confusion.
>> You might add comments to this enhancement request:
>>
>> https://bugs.eclipse.org/196973
>>
>> or raise a new bug to capture these issues, and we'll see about sorting
>> it out.
>
> Yes, you are right, it has very much to do with this bug. I suppose I
> could add these issues to it, but I think it would be easier for
> you to treat it separately, since changes are very straightforward.
>
> On the other hand, I didn't remember that bug (yes, this one I was aware
> of at the time). :) This reminds me that I had a contribution to make to
> the OCL project. What do you think about a redefinition of the text
> provided by each and every node in an OCL model, so it closely resembles
> the original concrete syntax? This redefinition is not trivially
> accomplished, because each node has to gather information from its
> children to assemble the proper text. For instance, an OperationCallExp
> would need to assemble the 'source' part, the 'argument' part, aside from
> the name of the referred operation. Since navigating through children is
> delicate due to lack of Java interfaces providing multiple inheritance to
> item provider adapters generated by the Genmodel, I have had to devise a
> proper design that copes with these concerns.
I'm not sure about the value of having the item providers render the
concrete syntax of sub-expressions. That will end up making a very verbose
editor, which either will be hard to read or will have much ellipsis
truncation. Do you not find it so?
> Since this text redefinition has to do with integral support to QVT,
> support is currently limited to the Essential OCL contents
> (only IteratorExp is still missing proper support, and perhaps
> other minor details as well). The good news is that it is highly
> customizable and can easily made extensible to any other metatype to
> participate in such customizations.
Speaking of iterators expressions, how do you render iterators with implicit
variables?
> Also I have only made text redefinitions for the ocl.ecore project, which
> comes along with two new Java packages per original package. To test it
> you only have to install the corresponding ocl.ecore Edit, which does not
> contain anything else than the generated contents via the Genmodel plus
> manual text modifications. And to generate the ocl.ecore Editor plugin as
> well, in order to navigate models in a Sample Ecore Model Editor.
Well, since I haven't even committed, yet, to providing the Edit and Editor
plug-ins yet in the OCL component (these would be six new plug-ins of
dubious value, considering how uninteresting an AST editor would generally
be expected to be), I'm not sure what to do with such a contribution.
> Since this work comes out of my PhD work, it is ok for my company for me
> to make such a contribution to the OCL project, as long as the company's
> name is also mentioned somewhere in the source code. What I don't know is
That is Eclipse policy, so have no worries on that score.
> how to make that contribution. I suppose I have to comply with some
> guidelines in the header of each redefined java file or something. Could
> anybody help me on that matter? I have generated the Edit plugin with OCL
Eclipse's IP process and contributor guidelines should tell you how, and
there are numerous examples in OCL already, especially from Ed Willink's
contributions (search for "Willink" in the source).
> 1.2 M5. I could attach it as is to the abovementioned bug for you to test
> it, if you like, since diff over a non-existing previous version does not
> have much sense. Still you could generate the Edit plugin by yourself and
> somehow check the manual changes and additions, which are all marked as
> 'generated NOT' tag in their javadoc.
This would need a separate enhancement request, as each contribution should
be tracked individually in bugzilla.
> See you!
>
> Victor Sánchez
>
>> HTH,
>>
>> Christian
>>
>>
>> Victor Sanchez wrote:
>>
>>> Hello!
>>>
>>> The 'item : OCLExpression' property of CollectionItem is marked as not
>>> much editable in the OCL.genmodel file. I would have expected the Edit:
>>> 'children' and 'createChildCreate Child' fields to be set to true.
>>> Otherwise I cannot fulfill my own OCL models by hand in the editor and
>>> I am forced to revert to a XMI text editor if I want to set any value
>>> to this property.
>>>
>>> The same happens with CollectionRange -> 'first' and 'last' properties.
>>> I'm not sure if there are other similar cases. Is that acknowledged?
>>> Intended? I can change the genmodel myself and regenerate, but I would
>>> be more confident if such (subtle?) changes would end up in the OCL
>>> project's mainstream releases.
>>>
>>> Thank you very much!
>>>
>>> Victor Sánchez
|
|
|
| Re: CollectionItem -> item direct edition [message #51765 is a reply to message #51648] |
Fri, 29 February 2008 18:55 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
And I have fixed it.
Thanks!
cW
Victor Sanchez wrote:
> Hello, Christian!
>
> I have opened bug #220931 concerning the OCL.genmodel issues.
>
> Thank you very much!
>
> Victor Sanchez
|
|
|
| Re: CollectionItem -> item direct edition [message #51820 is a reply to message #51741] |
Fri, 29 February 2008 21:57 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hello, Christian! (replies in-line).
> By coincidence, in developing new UML models, I found that singular
> containment references were showing up the same way in the genmodel, my
> generated Edit code didn't include new-child-descriptors for them, but the
> editor worked as expected nonetheless. Despite the incorrect genmodel,
> something was making my editor work. Hence my confusion.
If you mean the editor of the the Eclipse UML project, I'm not really
surprised, since they have many things redefined their own way. That said,
I'm way less expert about this subject than I may be implying. :D
> I'm not sure about the value of having the item providers render the
> concrete syntax of sub-expressions. That will end up making a very
> verbose editor, which either will be hard to read or will have much
> ellipsis truncation. Do you not find it so?
As I see it it is a blessing. It works like a charm. I mean, verbosity is
what someone would ask for when not present while exploring OCL (or
QVT, which are more in tune with my experience) models.
As it can be customized to suit your needs, you could easily end with
graph roots whose text contains a lot of things, or be more conservative
and break the information into parts which will be assigned to their
children. Either way, children themselves show the same or more
complete information than their parents.
> Speaking of iterators expressions, how do you render iterators with
> implicit variables?
Whatever (meta)property is implicit or optional and not specified it is
left out of the text rendering. If something is required and still not
defined, a particular error string is shown in its place.
> Well, since I haven't even committed, yet, to providing the Edit and
> Editor plug-ins yet in the OCL component (these would be six new
> plug-ins of dubious value, considering how uninteresting an AST editor
> would generally be expected to be), I'm not sure what to do with such a
> contribution.
What we can do is the following. I have talked with my boss, and it is
ok for him to make this ocl.ecore.edit plugin available in our website, so
anybody, including you, can test it as much as they like (it will probably
be followed by similar plugins targeting text redefinition for the QVT
Operational Mappings language). Of course it will be released under the
EPL license, so you can decide whenever you see fit whether to make it
become an official component of the OCL project (or, which is the same,
attach my handmade modifications to the official Edit plugin), or not. My
part on this mini-contribution will be over as soon as the plugin is
downloadable from our website. :)
>> how to make that contribution. I suppose I have to comply with some
>> guidelines in the header of each redefined java file or something.
>> Could anybody help me on that matter? I have generated the Edit plugin
>> with OCL
>
> Eclipse's IP process and contributor guidelines should tell you how, and
> there are numerous examples in OCL already, especially from Ed Willink's
> contributions (search for "Willink" in the source).
Glad to hear all this. Thank you for the information, Christian!
>> 1.2 M5. I could attach it as is to the abovementioned bug for you to
>> test it, if you like, since diff over a non-existing previous version
>> does not have much sense. Still you could generate the Edit plugin by
>> yourself and somehow check the manual changes and additions, which are
>> all marked as 'generated NOT' tag in their javadoc.
>
> This would need a separate enhancement request, as each contribution
> should be tracked individually in bugzilla.
Ok. I think I will wait for your feedback (provided you have time, etc.,
no obligation here implied) before I make such an enhancement request. I'll
let you know when and where this plugin is made available. Should I use a
post to the news with a subject starting with "[Announce] ..."?. That would
be most fun! :)
Thank you very much for everything, Christian!
Victor Sanchez
|
|
|
| Re: CollectionItem -> item direct edition [message #52003 is a reply to message #51820] |
Mon, 03 March 2008 17:23 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
>> Speaking of iterators expressions, how do you render iterators with
>> implicit variables?
>
> Whatever (meta)property is implicit or optional and not specified it is
> left out of the text rendering. If something is required and still not
> defined, a particular error string is shown in its place.
Ups, perhaps this answer deserves a more thorough explanation. What I mean
is that normally such variables end up with having its explicit
correspondence in models. They are only implicit in the original concrete
syntax. It is not expected that the kind of text rendering we are
talking about be exactly the same as the original out from which parsing
builds its semantically equivalent model. If the information is stored in
the model, it can be located and displayed. I don't know if there are any
cases in which implicit information in the concrete syntax would remain so
in its abstract representation. In such cases I suspect the situation
could be identified and dealt with happily but I would probably need to
come across a conflicting case just to be sure.
Just my two cents. I admit I am learning a lot about the OCL specification
derived from our discussions these days, more than ever! :)
Victor Sanchez
|
|
|
| Re: CollectionItem -> item direct edition [message #52361 is a reply to message #52003] |
Thu, 06 March 2008 12:17 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hi, Christian!
Sorry to give the matter further attention. I intend to add a comment
to bug# 196973 about my need for an official ocl(.ecore).edit plugin.
Fortunately, I have found such a plugin available via the UMLX
project, so in the meantime I can use it and hope to contribute to it.
Cheers!!!
Victor
|
|
|
| Re: CollectionItem -> item direct edition [message #52415 is a reply to message #51820] |
Fri, 07 March 2008 21:02 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
In-line, again.
cW
Victor Sanchez wrote:
> Hello, Christian! (replies in-line).
>
-----8<-----
>> I'm not sure about the value of having the item providers render the
>> concrete syntax of sub-expressions. That will end up making a very
>> verbose editor, which either will be hard to read or will have much
>> ellipsis truncation. Do you not find it so?
>
> As I see it it is a blessing. It works like a charm. I mean, verbosity is
> what someone would ask for when not present while exploring OCL (or
> QVT, which are more in tune with my experience) models.
>
> As it can be customized to suit your needs, you could easily end with
> graph roots whose text contains a lot of things, or be more conservative
> and break the information into parts which will be assigned to their
> children. Either way, children themselves show the same or more
> complete information than their parents.
In general, the tree-based generated editor can be expected to be hard to
use. The structure of the AST for even the simplest OCL text is quite
complex, and using the editor to construct a well-formed expression is very
difficult.
For debugging the AST, I use Miguel's OCL ASTView plug-in. Have you seen
it? It's included in the initial contribution of the MDT OCLTools
component.
>> Speaking of iterators expressions, how do you render iterators with
>> implicit variables?
>
> Whatever (meta)property is implicit or optional and not specified it is
> left out of the text rendering. If something is required and still not
> defined, a particular error string is shown in its place.
I don't mean property values or objects missing from the AST, but iterator
variables that were implicit in the OCL source text. e.g.,
context Teacher
inv: self.class.student->forAll(isHappy)
in which the iterator variable is unnamed.
>> Well, since I haven't even committed, yet, to providing the Edit and
>> Editor plug-ins yet in the OCL component (these would be six new
>> plug-ins of dubious value, considering how uninteresting an AST editor
>> would generally be expected to be), I'm not sure what to do with such a
>> contribution.
>
> What we can do is the following. I have talked with my boss, and it is
> ok for him to make this ocl.ecore.edit plugin available in our website, so
> anybody, including you, can test it as much as they like (it will probably
> be followed by similar plugins targeting text redefinition for the QVT
> Operational Mappings language). Of course it will be released under the
> EPL license, so you can decide whenever you see fit whether to make it
> become an official component of the OCL project (or, which is the same,
> attach my handmade modifications to the official Edit plugin), or not. My
> part on this mini-contribution will be over as soon as the plugin is
> downloadable from our website. :)
I gather from your other reply that you are now planning to incubate your
enhancements in UMLX? That sounds like a good idea, as the edit plug-in is
already semi-supported, there. I will definitely need to look into how
that is being used, why UMLX has defined this, in order to determine
whether it really should be provided by MDT OCL.
>>> how to make that contribution. I suppose I have to comply with some
>>> guidelines in the header of each redefined java file or something.
>>> Could anybody help me on that matter? I have generated the Edit plugin
>>> with OCL
>>
>> Eclipse's IP process and contributor guidelines should tell you how, and
>> there are numerous examples in OCL already, especially from Ed Willink's
>> contributions (search for "Willink" in the source).
>
> Glad to hear all this. Thank you for the information, Christian!
>
>>> 1.2 M5. I could attach it as is to the abovementioned bug for you to
>>> test it, if you like, since diff over a non-existing previous version
>>> does not have much sense. Still you could generate the Edit plugin by
>>> yourself and somehow check the manual changes and additions, which are
>>> all marked as 'generated NOT' tag in their javadoc.
>>
>> This would need a separate enhancement request, as each contribution
>> should be tracked individually in bugzilla.
>
> Ok. I think I will wait for your feedback (provided you have time, etc.,
> no obligation here implied) before I make such an enhancement request.
> I'll let you know when and where this plugin is made available. Should I
> use a post to the news with a subject starting with "[Announce] ..."?.
> That would be most fun! :)
Anyone can, in theory, announce the availability of cool OCL-based plug-ins
or other components on the newsgroup. Why not?
> Thank you very much for everything, Christian!
>
> Victor Sanchez
|
|
|
| Re: CollectionItem -> item direct edition [message #52447 is a reply to message #52415] |
Sat, 08 March 2008 19:54 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hello, Christian! In-line replies follow :)
>>> I'm not sure about the value of having the item providers render the
>>> concrete syntax of sub-expressions. That will end up making a very
>>> verbose editor, which either will be hard to read or will have much
>>> ellipsis truncation. Do you not find it so?
>>
>> As I see it it is a blessing. It works like a charm. I mean, verbosity is
>> what someone would ask for when not present while exploring OCL (or
>> QVT, which are more in tune with my experience) models.
>>
>> As it can be customized to suit your needs, you could easily end with
>> graph roots whose text contains a lot of things, or be more conservative
>> and break the information into parts which will be assigned to their
>> children. Either way, children themselves show the same or more
>> complete information than their parents.
>
> In general, the tree-based generated editor can be expected to be hard to
> use. The structure of the AST for even the simplest OCL text is quite
> complex, and using the editor to construct a well-formed expression is very
> difficult.
I cannot agree more. We can add to that the already mentioned fact that
inspection of OCL models won't happen very often. At least, for standalone
usage. However, there may be people (like me) who, for whatever reason,
need to analyze portions of OCL AST instances, and sometimes, even create
them from scratch, and in such cases text customization can help us avoid
getting lost while navigating ASTs. This may be (a little bit) more
usual if we consider support efforts for OCL language extensions, for which
I recall two particular cases, namely OMG's QVT and MOF2Text.
> For debugging the AST, I use Miguel's OCL ASTView plug-in. Have you seen
> it? It's included in the initial contribution of the MDT OCLTools
> component.
Cool! I see what you mean. This is even more verbose than an attempt to
come up with text more or less in tune with the expected concrete syntax.
In fact, it does not seem to be an attempt to mimic concrete syntax at
all, which does not limit its usefulness whatsoever! The problem I
have with that is that I also need text enhancements for languages
extending OCL, such as the QVT suite, and for practical purposes it is
more useful for me to redefine them in the Sample Ecore Model Editor.
My text customization might be seen as a double check you can make
upon assembled OCL models to assess their correctness or semantic
equivalence against source textual instances, which is one of the purposes
we use it for with QVT models obtained out of parsing execution.
>>> Speaking of iterators expressions, how do you render iterators with
>>> implicit variables?
>>
>> Whatever (meta)property is implicit or optional and not specified it is
>> left out of the text rendering. If something is required and still not
>> defined, a particular error string is shown in its place.
>
> I don't mean property values or objects missing from the AST, but iterator
> variables that were implicit in the OCL source text. e.g.,
>
> context Teacher
> inv: self.class.student->forAll(isHappy)
>
> in which the iterator variable is unnamed.
Haha, nice example! Ok, so my previous answer was still right, only that I
forgot to mention that I was referring exclusively to models when talking
about optional (if this is possible!) or not specified artifacts. My
particular text customization cannot distinguish between implicit or
explicit concrete variables, so for the provided example, the IteratorExp
node would currently end up displaying something like this:
self.class.student->forAll(temp2 : Student | isHappy)
even though 'temp2' does not participate in the rendered text for the body
section. Which is fine in case we really want to track down what exactly
the tree is composed by and which node contributes what. Optionally, the
body can be substituted by an ellipsis. On the other hand, it would be
easy to check for occurrences of 'temp2' inside the body portion text, and
conditionally disable the render of the whole 'temp2' iterator variable
portion. This kind of micro-customization tweaks could further be applied
upon the java code on a personal basis.
I agree, though, that Miguel's ASTView also offers important missing
information from the original, EMF automatically generated, OCL editor and
the (semantically equivalent) concrete syntax.
> I gather from your other reply that you are now planning to incubate
> your enhancements in UMLX? That sounds like a good idea, as the edit
> plug-in is already semi-supported, there. I will definitely need to
> look into how that is being used, why UMLX has defined this, in order to
> determine whether it really should be provided by MDT OCL.
Yeah that's exactly what I plan to do. Dr. Willink is still awaiting
reception of my contribution to take a look at it. As I see it UMLX is a
great site for the contribution in question. Adolfo's plugins concerning
the QVT Operational Mappings support are (or will be, I'm not sure of the
details) hosted there as well. Also, once text redefinition is incorporated
in the ocl.ecore.edit plugin, QVT .edit plugins will be able (have) to
follow. In any case, everything will be available from a centralized site,
which is good news.
By the way, Dr. Willink has already contributed a comment to bug# 196973
with a lot more insight than what I would have said in his stead so
I've been left without words to add and withdraw
from further comments. :)
>> Ok. I think I will wait for your feedback (provided you have time, etc.,
>> no obligation here implied) before I make such an enhancement request.
>> I'll let you know when and where this plugin is made available. Should I
>> use a post to the news with a subject starting with "[Announce] ..."?.
>> That would be most fun! :)
>
> Anyone can, in theory, announce the availability of cool OCL-based
> plug-ins or other components on the newsgroup. Why not?
Thanks again, Christian. I didn't know whether there is some kind of
etiquette for these kinds of things or to what extent there is one. :)
Cheers!!!
Victor Sánchez
|
|
|
| Re: CollectionItem -> item direct edition [message #52464 is a reply to message #52447] |
Sat, 08 March 2008 21:13 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hello again!
(Bad luck with my posts which I have to be constantly updating)
I did only take a superficial glance a screenshot of Miguel's OCL ASTView
and I based my comments on that. Now that I have given it a closer look (at
the same screenshot), I see that the AST information comes along with the
original OCL text. In that case, it is an excellent tool, an unbeatable
one, for parser maintainers, such as, I suppose, yourself, Christian. As
for myself, I usually work with models as input, which are somehow detached
from the source OCL text.
See you!
Victor Sánchez
|
|
|
| Re: CollectionItem -> item direct edition [message #52518 is a reply to message #52447] |
Sun, 09 March 2008 08:35 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Sorry again!!! Another mistake in my reasonings. Believe me, it is not
my intention to flood this thread with more messages! :D
Ok, back to the example:
context Teacher
inv: self.class.student->forAll(isHappy)
I did not assume that the 'isHappy' body is some sort of expression
involving each iterated student. Let's say a Property Call Expression. In
that case, assembled text for the inv: expression would look more like:
self.class.student->forAll(temp2 : Student | temp2.isHappy)
and it would be way harder to get rid of the implicit 'temp2' identifier,
basically because the original text is not involved in this process,
and temp2 is supposedly not distinguishable from any other regular
variable in the model.
Regards!
Victor
|
|
|
| Re: CollectionItem -> item direct edition [message #52572 is a reply to message #52464] |
Mon, 10 March 2008 13:36 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
This is precisely why I use the ASTView, myself, in my debugging.
:-)
cW
Victor Sanchez wrote:
> Hello again!
>
> (Bad luck with my posts which I have to be constantly updating)
>
> I did only take a superficial glance a screenshot of Miguel's OCL ASTView
> and I based my comments on that. Now that I have given it a closer look
> (at the same screenshot), I see that the AST information comes along with
> the original OCL text. In that case, it is an excellent tool, an
> unbeatable one, for parser maintainers, such as, I suppose, yourself,
> Christian. As for myself, I usually work with models as input, which are
> somehow detached from the source OCL text.
>
> See you!
>
> Victor Sánchez
|
|
|
| Re: CollectionItem -> item direct edition [message #52599 is a reply to message #52518] |
Mon, 10 March 2008 13:42 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
Right, this looks more like what I would expect. I agree that the "temp2"
doesn't stand out as being generated by the parser. There is no
traceability in the AST to its origin as an implicit variable because, even
if you knew the Environment in which the expression was parsed, the
variable definition that knows whether it is implicit would already have
been removed from that environment.
In any case, the verbosity is helpful to indicate clearly which feature
calls are sourced in which implicit variable.
Consider this:
context Teacher
inv: self.class.student->forAll(isHappy implies grade > passing)
which, assuming that different teachers assign different thresholds for
passing grades, might expand to:
context Teach
inv: self.class.student->forAll(temp2 : Student |
temp2.isHappy implies temp2.grade > self.passing)
(notice the resolution of self as an implicit target, in addition to temp2).
Cheers,
Christian
Victor Sanchez wrote:
> Sorry again!!! Another mistake in my reasonings. Believe me, it is not
> my intention to flood this thread with more messages! :D
>
> Ok, back to the example:
>
> context Teacher
> inv: self.class.student->forAll(isHappy)
>
> I did not assume that the 'isHappy' body is some sort of expression
> involving each iterated student. Let's say a Property Call Expression. In
> that case, assembled text for the inv: expression would look more like:
>
> self.class.student->forAll(temp2 : Student | temp2.isHappy)
>
> and it would be way harder to get rid of the implicit 'temp2' identifier,
> basically because the original text is not involved in this process,
> and temp2 is supposedly not distinguishable from any other regular
> variable in the model.
>
> Regards!
>
> Victor
|
|
|
| Re: CollectionItem -> item direct edition [message #52625 is a reply to message #52447] |
Mon, 10 March 2008 13:46 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
Right, well, I'm not usually so hard to convince of the value of providing
useful capability :-)
MDT OCL really should be providing the "standard" implementation of
the .Edit and .Editor code, which is why the bugzilla isn't resolved as
WONTFIX. The problem is a matter of determining how to package it, to make
downloads available. I wouldn't want it to be included in the standard
run-time and SDK downloads; it would have the status more of an example, I
think. I would like to get it worked out in time for M6.
Cheers,
Christian
Victor Sanchez wrote:
> Hello, Christian! In-line replies follow :)
>
>>>> I'm not sure about the value of having the item providers render the
>>>> concrete syntax of sub-expressions. That will end up making a very
>>>> verbose editor, which either will be hard to read or will have much
>>>> ellipsis truncation. Do you not find it so?
>>>
>>> As I see it it is a blessing. It works like a charm. I mean, verbosity
>>> is what someone would ask for when not present while exploring OCL (or
>>> QVT, which are more in tune with my experience) models.
>>>
>>> As it can be customized to suit your needs, you could easily end with
>>> graph roots whose text contains a lot of things, or be more conservative
>>> and break the information into parts which will be assigned to their
>>> children. Either way, children themselves show the same or more
>>> complete information than their parents.
>>
>> In general, the tree-based generated editor can be expected to be hard to
>> use. The structure of the AST for even the simplest OCL text is quite
>> complex, and using the editor to construct a well-formed expression is
>> very difficult.
>
> I cannot agree more. We can add to that the already mentioned fact that
> inspection of OCL models won't happen very often. At least, for standalone
> usage. However, there may be people (like me) who, for whatever reason,
> need to analyze portions of OCL AST instances, and sometimes, even create
> them from scratch, and in such cases text customization can help us avoid
> getting lost while navigating ASTs. This may be (a little bit) more
> usual if we consider support efforts for OCL language extensions, for
> which I recall two particular cases, namely OMG's QVT and MOF2Text.
>
>> For debugging the AST, I use Miguel's OCL ASTView plug-in. Have you seen
>> it? It's included in the initial contribution of the MDT OCLTools
>> component.
>
> Cool! I see what you mean. This is even more verbose than an attempt to
> come up with text more or less in tune with the expected concrete syntax.
> In fact, it does not seem to be an attempt to mimic concrete syntax at
> all, which does not limit its usefulness whatsoever! The problem I
> have with that is that I also need text enhancements for languages
> extending OCL, such as the QVT suite, and for practical purposes it is
> more useful for me to redefine them in the Sample Ecore Model Editor.
>
> My text customization might be seen as a double check you can make
> upon assembled OCL models to assess their correctness or semantic
> equivalence against source textual instances, which is one of the purposes
> we use it for with QVT models obtained out of parsing execution.
>
>>>> Speaking of iterators expressions, how do you render iterators with
>>>> implicit variables?
>>>
>>> Whatever (meta)property is implicit or optional and not specified it is
>>> left out of the text rendering. If something is required and still not
>>> defined, a particular error string is shown in its place.
>>
>> I don't mean property values or objects missing from the AST, but
>> iterator variables that were implicit in the OCL source text. e.g.,
>>
>> context Teacher
>> inv: self.class.student->forAll(isHappy)
>>
>> in which the iterator variable is unnamed.
>
> Haha, nice example! Ok, so my previous answer was still right, only that I
> forgot to mention that I was referring exclusively to models when talking
> about optional (if this is possible!) or not specified artifacts. My
> particular text customization cannot distinguish between implicit or
> explicit concrete variables, so for the provided example, the IteratorExp
> node would currently end up displaying something like this:
>
> self.class.student->forAll(temp2 : Student | isHappy)
>
> even though 'temp2' does not participate in the rendered text for the body
> section. Which is fine in case we really want to track down what exactly
> the tree is composed by and which node contributes what. Optionally, the
> body can be substituted by an ellipsis. On the other hand, it would be
> easy to check for occurrences of 'temp2' inside the body portion text, and
> conditionally disable the render of the whole 'temp2' iterator variable
> portion. This kind of micro-customization tweaks could further be applied
> upon the java code on a personal basis.
>
> I agree, though, that Miguel's ASTView also offers important missing
> information from the original, EMF automatically generated, OCL editor and
> the (semantically equivalent) concrete syntax.
>
>> I gather from your other reply that you are now planning to incubate
>> your enhancements in UMLX? That sounds like a good idea, as the edit
>> plug-in is already semi-supported, there. I will definitely need to
>> look into how that is being used, why UMLX has defined this, in order to
>> determine whether it really should be provided by MDT OCL.
>
> Yeah that's exactly what I plan to do. Dr. Willink is still awaiting
> reception of my contribution to take a look at it. As I see it UMLX is a
> great site for the contribution in question. Adolfo's plugins concerning
> the QVT Operational Mappings support are (or will be, I'm not sure of the
> details) hosted there as well. Also, once text redefinition is
> incorporated in the ocl.ecore.edit plugin, QVT .edit plugins will be able
> (have) to follow. In any case, everything will be available from a
> centralized site, which is good news.
>
> By the way, Dr. Willink has already contributed a comment to bug# 196973
> with a lot more insight than what I would have said in his stead so
> I've been left without words to add and withdraw
> from further comments. :)
>
>>> Ok. I think I will wait for your feedback (provided you have time, etc.,
>>> no obligation here implied) before I make such an enhancement request.
>>> I'll let you know when and where this plugin is made available. Should I
>>> use a post to the news with a subject starting with "[Announce] ..."?.
>>> That would be most fun! :)
>>
>> Anyone can, in theory, announce the availability of cool OCL-based
>> plug-ins or other components on the newsgroup. Why not?
>
> Thanks again, Christian. I didn't know whether there is some kind of
> etiquette for these kinds of things or to what extent there is one. :)
>
> Cheers!!!
>
> Victor Sánchez
|
|
|
Goto Forum:
Current Time: Fri Dec 27 00:44:18 GMT 2024
Powered by FUDForum. Page generated in 0.04994 seconds |
] 
Search
Help
Register
Login
Home
