Tuesday, March 31, 2009

Using the EditingDomain to modify Ecore models

EditingDomain editingDomain = AdapterFactoryEditingDomain.getEditingDomainFor(eClass);
...
Command cmd = AddCommand.create(editingDomain, eClass, null, eOper);

editingDomain.getCommandStack().execute(cmd);


The above code snippet shows an improvement over the modifications done to the Ecore model in the posting about creating new actions for the Ecore Editor. The previous version had the drawback, that the changes to the model couldn't be undone. That is going to change now forever, just by exploiting the EditingDomain which is provided by EMF.

In order for this code to run, you will need to add org.eclipse.emf.ecore.edit to your list of plugin dependencies. I will continue to post some examples and make the editor available on sourceforge.net. Keep listening for more information.

Monday, March 30, 2009

Using Xtext in standalone mode

public static void main(String[] args) {
MyDslStandaloneSetup.doSetup();
ResourceSet resourceSet = new ResourceSetImpl();
URI uri = URI.createFileURI("src/test/test.mydsl");
Resource resource = resourceSet.getResource(uri, true);
Model model = (Model) resource.getContents().get(0);
for (org.xtext.example.myDsl.Class clazz : model.getElements()) {
System.out.println(clazz.getName());
}
}

Today we look at using the new TMF Xtext Framework which is currently available as beta version in standalone mode.  Things got considerably easier since the current version. The example has been built using Eclipse 3.5M6. The DSL is the one which is generated after creating a sample Xtext project. TMF Xtext will be available from June onwards.

Looking at the code snippet above they only thing which is worth mentioning is the class MyDslStandaloneSetup which is generated as part of your Domain Specific Language. It does all the required setup work. Xtext is using guice for its dependency management and configuration, but we do not not need to worry about that. The static doSetup method is doing all the work.

After initialising we can simply create a resource. All the required factories have already been registered using the StandaloneSetup class. Because Xtext is now also using generated classes which are derived from the ecore model, querying the model is even easier than before. No more dynamic EMF is required! The Model and Class classes are examples for the generated classes.
Questions? Post a comment!

Sunday, March 29, 2009

Creating useful actions for the EMF Ecore Editor

When using the Ecore editor to produce models which can be used to generate code, it is often a tedious task to create some of the required artefacts.
Such as:
  • create an operation with ready made annotation for inclusion of an operation body in the generated code
  • create a validator constraint operation
  • create a derived, volatile attribute
  • ...
Create a new plugin project, e.g. org.softwarepoets.emf.ecore.editor.extensions

Open the manifest and add this to your plugin.xml file:
<extension
point="org.eclipse.ui.popupMenus">
<objectContribution id="org.eclipse.emf.ecore.editor.CreateEOperationWithAnnotation"
objectClass="org.eclipse.emf.ecore.EClass">
<action id="org.eclipse.emf.ecore.editor.CreateEOperationWithAnnotation"
label="Codegen Operation"
menubarPath="additions" class="org.softwarepoets.emf.ecore.editor.extensions.CreateEOperationWithAnnotation"
enablesFor="1"/>
</objectContribution>
</extension>

In the dependencies section of the manifest add org.eclipse.emf.ecore.

Create a new class org.softwarepoets.emf.ecore.editor.extensions.CreateEOperationWithAnnotation:

public class CreateEOperationWithAnnotation extends ActionDelegate implements
IActionDelegate {

protected EClass eClass;

public CreateEOperationWithAnnotation() {
super();
}

The run method:

@Override
public void run(IAction action) {
InputDialog dialog = new InputDialog(PlatformUI.getWorkbench()
.getActiveWorkbenchWindow().getShell(), "Enter Operation name",
"Enter the name of the operation without parameters using valid java naming conventions.", "", new JavaNamingValidator() );

if (dialog.open() == InputDialog.OK ) {
String name = dialog.getValue();
EOperation eOper = EcoreFactory.eINSTANCE.createEOperation();
eOper.setName(name);
eClass.getEOperations().add(eOper);
EAnnotation eAnnotation = EcoreFactory.eINSTANCE.createEAnnotation();
eOper.getEAnnotations().add(eAnnotation);
eAnnotation.setSource(GenModelPackage.eNS_URI);
eAnnotation.getDetails().put("body","");
}
}


The implementation of the run method will also display a small dialog in order to ask the user for the operation name.




How to decide on which class the operation should be added and if the action should be enabled:
@Override
public void selectionChanged(IAction action, ISelection selection) {
if (selection instanceof IStructuredSelection) {
Object object = ((IStructuredSelection) selection)
.getFirstElement();
if (object instanceof EClass) {
eClass = (EClass) object;

action.setEnabled(true);
return;
}
}
eClass = null;
action.setEnabled(false);
}

The validator class, to validate the input of the user (draft version, can be improved a lot):
class JavaNamingValidator implements IInputValidator {
public String isValid(String newText) {
if (newText == null || newText.length() == 0)
return "You must enter an operation name.";
// maybe include an elaborate regular expression here...
// otherwise ok
return null;
}
}



After you are done, you can start a new runtime workspace, create an Ecore model, select an EClass and right click. You should see the additional action in the popup menu. After completing the dialog you should see something like this:

Friday, March 27, 2009

Happy Birthday Futurist Manifesto

Filippo Tommaso Emilio Marinetti of italien origin, born in Egypt and died in Italy, wrote the first version of his famous Futurist Manifesto on February, 20th 1909. Brimful of hatred against the established academic art world and full of anger, it created a turbulent view on a world, which adored machines, speed and rejected any kind of tradition.

Literature has up to now magnified pensive immobility, ecstasy and slumber. We want to exalt movements of aggression, feverish sleeplessness, the double march, the perilous leap, the slap and the blow with the fist.
We declare that the splendour of the world has been enriched by a new beauty: the beauty of speed. A racing automobile with its bonnet adorned with great tubes like serpents with explosive breath ... a roaring motor car which seems to run on machine-gun fire, is more beautiful than the Victory of Samothrace.
Whether the later links to facism in Italy were inevitable due to their special philosophy or not, should not be discussed here. Rather by joining the birthday celebrations we'd like to highlight the existence of the Manifesto of the Futurist Programmers whose programme we share beyond doubt. Written in 1991 it is equally important as a document which point sus to believing into fast software, good software, working software as opposed to modular, reusable and designed software.

1. To destroy the cult of the past, the obsession with all things old, academic pedantry, and formalism
2. To cast our scorn profoundly on every last form of imitation
3. To exalt every form of originality, even if foolhardy, even if extremely violent
4. To bear bravely and proudly the smear of "madness" with which they try to gag all innovators
5. To look on the lot of computer "scientists" as at one and the same time useless and dangerous
6. To rebel against the tyranny of the words "extensible" and "reusable" expressions so elastic that they can just as easily be used to demolish the art of Atkinson, Baumgart and Deutsch as well
7. To sweep out of the mental field of programming all themes and subjects already exploited
8. To render and magnify the life of today, incessantly and tumultuously transformed by science triumphant
Without the Futurist Manifesto, no Manifesto of the futurist programmers. Throw your documentation in the bin, pump up the volume of your MP3 player and start celebrating! Happy Birthday! Leave a comment if you couldn't agree more.