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 22:55  |
 Kirsten M. Z.
Messages: 132
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 22: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 06:36  |
Ed Willink
Messages: 7669
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 08:51 |
Kirsten M. Z.
Messages: 132
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  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)
|
|
| | | | | | | |
Goto Forum:
Current Time: Tue Sep 10 07:44:22 GMT 2024
Powered by FUDForum. Page generated in 0.05292 seconds |
] 
Search
Help
Register
Login
Home
