Comments for GhoUl

Comment on Reflective tree editor for Xtext-based languages by Hendy Irawan

Hendy Irawan — Tue, 21 Feb 2012 09:34:11 +0000

Thank you!

It’s indeed very cool

Comment on Reflective tree editor for Xtext-based languages by Zoltán Ujhelyi

Zoltán Ujhelyi — Tue, 21 Feb 2012 08:58:06 +0000

Basically, editing is much effective in the text-based editor. However, when developing the language or the tooling, it is often nice that you could view the textual and the EMF version side by side (think writing code generators for example).

Yeah, I know, for end-users this feature is less appealing, but during development we missed it. Its possible to develop without such a view, but makes coding often easier.

Comment on Reflective tree editor for Xtext-based languages by Reflective tree editor for Xtext-based languages | Eclipse | Syngu

Reflective tree editor for Xtext-based languages | Eclipse | Syngu — Tue, 21 Feb 2012 06:42:36 +0000

[...] Xtext is a great technology. I really mean it. After 15-30 minutes (depending on your previous domain knowledge) you can get a really fancy textual editor, that parses your text into an EMF model. Xbase is even better: you can simply include Java-like expressions into your language, that can be easily translated into pure Java code.However, while using Xtext I found some minor “paper-cuts”. One of the most problematic of them was the fact that I cannot open my textual models using the Sample Reflective Ecore Model editor, as I get an exception: java.net.MalformedURLException: unknown protocol: java.A similar exception occurred if I tried to open the files programatically (but without the help of the generated Xtext editor). When I asked in the Eclipse forums how to open Xtext model files programatically, I was answered (btw. very quickly – kudos for that ) that a specific ResourceSet implementation is needed that refers to model files and classes available in a Java project.This gave me the idea to create an Xtext extension that allows opening an EMF tree editor, the Xtext Reflective Tree Editor. The plug-in consists of two parts:An extended version of the org.eclipse.emf.ecore.presentation.EcoreEditor class, that opens its ResourceSet using the Xtext API (more specifically, uses an injected ResourceSet);And an Xtext generator fragment, that can be used to generate a new editor extension to the ui project (with the corresponding dependency added to the reflective editor plug-in).UsageTo use the plug-in, just follow the following simple steps:Add hu.cubussapiens.xtext.reflectiveeditor as a dependency to your language project.Extend your editor generation workflow:Import the generator package: import hu.cubussapiens.xtext.reflectiveeditor.generator.*Add the new generator fragment at the end of the generator (file.extensions is the list of file extensions defined in the default workflow):fragment = ReflectiveXtextEditorFragment { fileExtensions = file.extensions }Regenerate your language.Unless the plugin.xml files are updated automatically, you have to copy the newly generated editor extension from the end of the plugin.xml_gen file of the ui plug-in to the plugin.xml file. The simplest way to do this is to select both files, and open the compare editor from the popup menu (Compare with/Each other…), the copy the changes manually.Finally, open the runtime workbench, and open your textual model files from the popup menu using Open with/«LanguageName» Reflective Editor. The result should be similar to the screenshot below.The Xtext Reflective EditorIn my case, the editor shows both the domain model generated from the file directly (the Pattern Model element), the inferred JVM model classes (the various JVM Generic Type instances), and also the referred Java classes as external resources (the resources beginning with the java:/ URIs).DownloadIf you are interested in the plug-in in action, download it from our update site: http://eclipse.cubussapiens.hu, or take a look at the repository on Github: https://github.com/ujhelyiz/xtext-reflectiveVersion 0.5.3 is already available, and hopefully works well for all languages. Eclipse Read the original post on Planet Eclipse… [...]

Comment on Reflective tree editor for Xtext-based languages by Hendy Irawan

Hendy Irawan — Tue, 21 Feb 2012 05:27:23 +0000

Wow! Very cool!

However, it begs the question.. Why would someone, like you, want to use the reflective editor instead of a text-based editor? Isn’t editing textually much faster and efficient ?

Comment on EMF-IncQuery @ EclipseCon Europe ’11 by Applications of high-performance model queries @ OMG/Eclipse workshop | GhoUl

Mon, 13 Feb 2012 12:46:46 +0000

[...] the last EclipseCon Europe, my collegue, István Ráth presented our incremental model query approach in the Modeling [...]

Comment on Custom markers and annotations – the bright side of Eclipse by Zoltán Ujhelyi

Zoltán Ujhelyi — Sat, 11 Feb 2012 09:16:35 +0000

I am not sure whether the annotationTypes or the markerAnnotationSpecification extension causes my annotation type to appear in the preferences (I think, the annotationTypes).

If you have the annotation type defined, you could create such annotations by attaching them to the document model; or if you also have markerAnnotationSpecification, you could simply create a marker for the file, and the corresponding annotation would be created automatically.

Comment on Custom markers and annotations – the bright side of Eclipse by Mol

Mol — Sat, 11 Feb 2012 07:02:43 +0000

Sir i need the full code to create the annotation…..as I want to create a new annotation and show it on the preferences(Annotation type). Please Help me..

Comment on Generating Java code from EMF models automatically by Stampie

Stampie — Wed, 28 Dec 2011 13:46:30 +0000

@?: Thank you again for pointing out the errors of my script. I updated the script with more detailed comments about the eclipse.build steps, and state that they are provided by Buckminster.

These steps are not required, so if you manage to refresh/build your projects otherwise, feel free to remove them.

Comment on Reusing PDE in modeling context by Stampie

Stampie — Sun, 13 Nov 2011 19:45:31 +0000

Oh, the evergreen question of to-rollyourown-or-nottorollyourown implementation. Because I don’t like the mentioned approach, I try to outline, what shall be implemented when choosing the referenced projects direction…

For being domain-specific, I see only a single way: to provide an expression language (or API), that helps deciding whether a selected project provides something needed. When these expression language is present, then the resulting project type could either be generated, or the defining model interpreted.

Luckily, the Core Expressions could be extended to incorporate such concepts (on the other hand, those expressions are a hell to write and debug ). But they (1) exist, (2) are defined on Resources and (3) can be extended using various property testers easily (already done it ).

Otherwise, creating a project type (or nature) that supports versioning is comparatively easy (and maybe the manifest file could be hijacked when it exists to reuse the existing functionality). And then such an API would be easy to provide you described in this post.

Comment on Reusing PDE in modeling context by Balage

Balage — Sun, 13 Nov 2011 19:00:43 +0000

Yes, I must agree with everything you say, I know about the problems. I also know about the “referenced projects” feature, but it lacks a lot of functionality which makes PDE so powerful (version handling, using models which are not located in the workspace but from installation – like a common library, etc..).

The complete solution would be a PDE-like feature for EMF projects with similar functionality, but in a domain specific way. It is just easier to reuse existing functionality than to write my own code.