Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL
[OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1033146] Wed, 03 April 2013 18:55 Go to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
Hi there,

I basically love the OCLInEcore editor. It simply works and everyone could save hours using text instead of clicking through the model. I also love the idea that OCLInEcore does not require an additional file, so everything stays in sync even if a team mate would use another editor. So first of all, thanks for this marvelous project.

However, I am very sad, that I still cannot use OCLInEcore for our models. The reason is the formatting of the OCLInEcore code. We usually have lots of OCL constraints, also more complicated ones. Using meaningful indentation is essential then. I think we all know that complicated OCL without meaningful formatting can be very cryptic. Formatting OCL constraints (manually) works if using reguar ecore editors as they are saved as strings within the model (of course, with all whitespaces, new lines etc.).

If I open the file with the OCLInEcore editor all the indentation trouble was for nothing. The OCLInEcore editor is a steamroller which flattens everything. I know that internally xtext is used, OCL constraints are not handled as strings in order to allow context help etc, but destroying helpful indentation is not a solution efficient development can live with. Do you think there is an easy (technical) option which can be integrated into the OCLInEcore editor?

Another desire would be the integration of comments/documentation. This is not that important, because one can place special annotations as a workaround. However, this could also be the idea of integrating comments/documentation: let the OCLInEcore editor transform regular comment ('//') to documenting annotations implicitly. Do you think this is a good idea?

I also want to mention, that I know *.oclinecore (text) files. However, I don't like the inconvenient translation steps (*.ecore <=> *.oclinecore). I already had problems with that, and I doubt that it is possible to sync them without trouble. In addition, the text editor also formats OCL badly, if I call the formatting operation (which is very useful for the rest of the model, of course).

Besides this main topic: are there other mature text editors for ecore which could fit our needs? I know Emfatic and I also tried EMFText. To be honest, I am disappointed. EMFText did not work out-of-the-box, Emfatic has a strange syntax and OCL support. However, if you recommend any editor, I will continue my research. BTW, I would love to model UML or XMI files (so arbitrary models based on ecore meta models) as text as well. I tried TextUML, for example, but without success. Seems that it is not maintained any more, and it does not work (editor is read-only, don't know why).

[Updated on: Wed, 03 April 2013 18:59]

Report message to a moderator

Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1033355 is a reply to message #1033146] Thu, 04 April 2013 02:36 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4027
Registered: July 2009
Senior Member
Hi

On 03/04/2013 23:55, Kirsten M. Z. wrote:
> I basically love the OCLInEcore Editor. It simply works and everyone
> could save hours using text instead of clicking through the model. I
> also love the idea that OCLInEcore does not require an additional
> file, so everything stays in sync even if a team mate would use
> another editor. So first of all, thanks for this marvelous project.
Thanks for the encourgement.
> However, I am very sad, that I still cannot use OCLInEcore for our
> models. The reason is the formatting of the OCLInEcore code. We
> usually have lots of OCL constraints, also more complicated ones.
> Using meaningful indentation is essential then. I think we all know
> that complicated OCL without meaningful formatting can be very
> cryptic. Formatting OCL constraints (manually) works if using reguar
> ecore editors as the are saved as strings within the model, of course,
> with all whitespaces, new lines etc.
>
> If I open the file with the OCLInEcore editor all the indentation
> trouble was for nothing. The OCLInEcore editor is a steamroller which
> flattens everything. I know that internally xtext is used, OCL
> constraints are not handled as strings in order to allow context help
> etc, but destroying helpful indentation is not a solution efficient
> development can live with. Do you think there is an easy (technical)
> option which can be integrated into OCLInEcore?
OCLinEcore also saves its OCL as string in EAnnotations, so it is
actually a very simple change to save the user's source string rather
than the pretty-printer's 'improvement'. It should be possible to ensure
the reformatting only occurs via Ctrl+Shift F. I'll take a look.
> Another desire would be the integration of comments/documentation.
> This is not that important, because one can place special annotations
> as a workaround. However, this could also be the idea of integrating
> comments/documentation: let the OCLInEcore editor transform regular
> comment ('//') to documenting annotations implicitly. Do you think
> this is a good idea?
Easy. Just use /* ... */ comments. As of the Juno release, these are
persisted as genmodel documentation annotations.
> I also want to mention, that I know *.oclinecore (text) files.
> However, I don't like the inconvenient translation steps (*.ecore <=>
> *.oclinecore). I already had problems with that, and I doubt that it
> is possible to sync them without trouble. In addition, the text editor
> also formats OCL badly, if I call the formatting operation (which is
> very useful for the rest of the model, of course).
The formatter is a standard Xtext facility that has been intermittently
tailored to be more acceptable. It's
org.eclipse.ocl.examples.xtext.essentialocl.formatting.AbstractEssentialOCLFormatter
if you want to try harder.

I have never seen any consensus on 'good' OCL layout style. For short
(10 token) expressions there are many alternatives with no obvious best.

I recently had to try to understand a 500 token constraint from UML 2.5
that refrained from factoring out intermediates steps as helper
attributes/operations. For this there seemed to be a sensible layout
with a new line preceding all non-trivial navigations, so that
indentation shows nesting an new lines show algorithmic progress. At
first sight lots of lines starting with -> or . look odd, but I think it
works.

I might revisit it.
> Besides this main topic: are there other mature text editors for ecore
> which could fit our needs? I know Emfatic and I also tried EMFText. To
> be honest, I am disappointed. EMFText did not work out-of-the-box,
> Emfatic has a strange syntax and OCL support. However, if you
> recommend any editor, I will continue my research. BTW, I would love
> to model UML or XMI files (so arbitraty models based on ecore meta
> models) as text as well. I tried TextUML, for example, but without
> success. Seems that it is not maintained any more, and it does not
> work (editor is read-only, don't know why).
Xcore is the strongest/stronger competitor to OCLinEcore. Much better
for Java, dubious for OCL.

There is an open Bugzilla on promotion of OCLinEcore to perhaps
OCLinUML; most of the support is already there since the underlying code
has UML support; just needs a concrete syntax for a (subset of) UML.

Regards

Ed Willink
Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1033468 is a reply to message #1033355] Thu, 04 April 2013 04:51 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
> > If I open the file with the OCLInEcore editor all the indentation
> > trouble was for nothing. The OCLInEcore editor is a steamroller which
> > flattens everything. I know that internally xtext is used, OCL
> > constraints are not handled as strings in order to allow context help
> > etc, but destroying helpful indentation is not a solution efficient
> > development can live with. Do you think there is an easy (technical)
> > option which can be integrated into OCLInEcore?
> OCLinEcore also saves its OCL as string in EAnnotations, so it is
> actually a very simple change to save the user's source string rather
> than the pretty-printer's 'improvement'. It should be possible to ensure
> the reformatting only occurs via Ctrl+Shift F. I'll take a look.

This would solve the mentioned problem.

At a first glance I thought that this solution is not optimal, because 'Ctrl+Shift F' is not allowed any more, so the rest of the document cannot be formatted. In fact, this is no problem because reloading the document rebuilds and 'formats' the rest of the document. So instead of 'Formatting' the 'Reload' button can be used. Nice!

Hopefully, it is no big deal. Then I will wait for the changes like a little kid for christmas Wink Thanks a lot!

> The formatter is a standard Xtext facility that has been intermittently
> tailored to be more acceptable. It's
> org.eclipse.ocl.examples.xtext.essentialocl.formatting.AbstractEssentialOCLFormatter
> if you want to try harder.
> I have never seen any consensus on 'good' OCL layout style. For short
> (10 token) expressions there are many alternatives with no obvious best.
> I recently had to try to understand a 500 token constraint from UML 2.5
> that refrained from factoring out intermediates steps as helper
> attributes/operations. For this there seemed to be a sensible layout
> with a new line preceding all non-trivial navigations, so that
> indentation shows nesting an new lines show algorithmic progress. At
> first sight lots of lines starting with -> or . look odd, but I think it
> works.

So AbstractEssentialOCLFormatter is subsequently used for embedded OCL if pressing 'Ctrl+Shift F'?

I realize that there is some effort for formatting the OCL, but I was never satified with the automatic formatting yet (more than three lines). Most important is the separation of 'larger' logical group (using new lines), e.g. in a chain of AND/OR links. Breaking long lines is another thing. I can imagine that there is never a "best" way (compare to conditions in Java 'if'). As long as there is no (good) guideline, preventing the change of manual formatting is necessary, I think.

Marginal question: does the essential OCL implementation support inline comments? (Thinking about the automatic formatting this would not have been meaningful yet, right?)

> > Another desire would be the integration of comments/documentation.
> > This is not that important, because one can place special annotations
> > as a workaround. However, this could also be the idea of integrating
> > comments/documentation: let the OCLInEcore editor transform regular
> > comment ('//') to documenting annotations implicitly. Do you think
> > this is a good idea?
> Easy. Just use /* ... */ comments. As of the Juno release, these are
> persisted as genmodel documentation annotations.

Just awesome! Something I missed.

> Xcore is the strongest/stronger competitor to OCLinEcore. Much better
> for Java, dubious for OCL.

Ahh, yes! I have tried Xcore some time ago. It is really a VERY promising project and works gracefully. However, as you said it is focused on Java integration and 'programming'.

> There is an open Bugzilla on promotion of OCLinEcore to perhaps
> OCLinUML; most of the support is already there since the underlying code
> has UML support; just needs a concrete syntax for a (subset of) UML.

I will have a look and maybe promote...
However, I am still wondering why a generic (text) editor for models seems to be ... hmh ... unpopular? I mean, there is a generic ecore model editor, why not a textual alternative? A specific concrete syntax is optimized, ok, but I doubt that creating a concrete syntax for each and every meta model is the right way. Even if it is easy with frameworks like EMFText. And I still wonder why there is no 'generic' solution in the EMFText syntax zoo (http://www.emftext.org/index.php/EMFText_Concrete_Syntax_Zoo)

Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1034572 is a reply to message #1033468] Fri, 05 April 2013 11:53 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
Am I right that the syntax for commenting is '/** ... */' not '/* ... */'? This works in my Kepler M6.

In addition, I want to report that removing comments is not possible in my version. I can add and change comments. However, if I remove comments and save, the documentation tag remains unchanged within the ecore file. Therefore, the comment appears again after reloading.

Did you inspect the OCL formatting issue already?
Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1034589 is a reply to message #1034572] Fri, 05 April 2013 12:16 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4027
Registered: July 2009
Senior Member
Hi

It used to be /** .. */ but that had problems so it's just /* .. */ in
the grammar, but that doesn't work for me now.

The changes for formatting an whitespace preservation are nearly all there.

But it's been a bad day... maybe late tomorrow.

Regards

Ed


On 05/04/2013 16:53, Kirsten M. Z. wrote:
> Am I right that the syntax for commenting is '/** ... */' not '/* ...
> */'? This works in my Kepler M6.
>
> In addition, I want to report that removing comments is not possible
> in my version. I can add and change comments. However, if I remove
> comments and save, the documentation tag remains unchanged within the
> ecore file. Therefore, the comment appears again after reloading.
>
> Did you inspect the OCL formatting issue already?
Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1034600 is a reply to message #1034589] Fri, 05 April 2013 12:40 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
Awesome, then I will check the nightly builds next week.

Concerning the commenting issue(s) I am puzzled a bit, because I have a very recent version. I also didn't get the point if it should work or not (also removing comments).

To keep it simple and to stop bothering you, I will just wait for the next versions. Thank you!
Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1036248 is a reply to message #1034600] Mon, 08 April 2013 02:06 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4027
Registered: July 2009
Senior Member
HI

http://www.eclipse.org/downloads/download.php?file=/modeling/mdt/ocl/downloads/drops/4.1.0/N201304080119/mdt-ocl-Update-tools-N201304080119.zip

should be rather better, identifying and propgating /*..*/ comments
consistently and preserving whitespace in embedded OCL expressions. The
auto-formatting is a bit better so that Xtext bugs on formatting may be
less annoying.

Regards

Ed Willink


On 05/04/2013 17:40, Kirsten M. Z. wrote:
> Awesome, then I will check the nightly builds next week.
>
> Concerning the commenting issue(s) I am puzzled a bit, because I have
> a very recent version. I also didn't get the point if it should work
> or not (also removing comments).
>
> To keep it simple and to stop bothering you, I will just wait for the
> next versions. Thank you!
Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1036396 is a reply to message #1036248] Mon, 08 April 2013 06:25 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
'preserving whitespace in embedded OCL expressions' works perfectly! Thank you very much. Even comments in ('--') can be used now.

/*..*/ now works as you explained. However, one problem remains.

Consider saving

	/* Test */


This becomes (save & reload)

/*
	 * Test
	 */


Next to this unimportant indentation issue, there is a problem if saved a second time. Then it becomes:

/*
	 * * Test
	 */



/*
	 * * * Test
	 */


And so on...
Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1036407 is a reply to message #1036396] Mon, 08 April 2013 06:37 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4027
Registered: July 2009
Senior Member
Hi

The bad indentation of the first comment attached to an indented element
is a reported Xtext bug.

The growth of *'s is my Bug, please raise a Bugzilla.

Regards

Ed

On 08/04/2013 11:25, Kirsten M. Z. wrote:
> 'preserving whitespace in embedded OCL expressions' works perfectly!
> Thank you very much. Even comments in ('--') can be used now.
>
> /*..*/ now works as you explained. However, one problem remains.
>
> Consider saving
>
> /* Test */
>
> This becomes (save & reload)
>
> /*
> * Test
> */
>
> Next to this unimportant indentation issue, there is a problem if
> saved a second time. Then it becomes:
>
> /*
> * * Test
> */
>
>
> /*
> * * * Test
> */
>
> And so on...
Re: [OCLInEcore] Automatic formatting in editor destroys all efforts for readable OCL [message #1036696 is a reply to message #1036407] Mon, 08 April 2013 13:46 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4027
Registered: July 2009
Senior Member
Hi

On 08/04/2013 11:37, Ed Willink wrote:
> The bad indentation of the first comment attached to an indented
> element is a reported Xtext bug.
Couldn't find it, so
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405184 raised.
> The growth of *'s is my Bug, please raise a Bugzilla.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405145 is fixed now, I hope.

Try:
http://www.eclipse.org/modeling/download.php?file=/modeling/mdt/ocl/downloads/drops/4.1.0/N201304081308/mdt-ocl-Update-tools-N201304081308.zip

Regards

Ed Willink
Previous Topic:[EMF/OCL/CDO] Accessing EClass with embedded OCL - problems under certain circumstances
Next Topic:OCL check programmatically
Goto Forum:
  


Current Time: Sat Aug 23 01:36:19 EDT 2014

Powered by FUDForum. Page generated in 0.03110 seconds