Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Xtext/Documentation/Xtext New and Noteworthy"

m (removed dummy text)
m (typos)
Line 14: Line 14:
  
 
== Lazy Linking ==
 
== Lazy Linking ==
The linking is done lazy now.
+
The linking is done lazily now.
 
The solves two different issues.
 
The solves two different issues.
 
1) You don't have to care about the order of linking anymore
 
1) You don't have to care about the order of linking anymore
Line 21: Line 21:
 
== Content Assist (reworked)==
 
== Content Assist (reworked)==
 
The content assist is finally in the shape we wanted it to be.
 
The content assist is finally in the shape we wanted it to be.
The behavior in the editor is closely aligned to what is know from Eclipse JDT and the APIhas also been improved.
+
The behavior in the editor is closely aligned to what is know from Eclipse JDT and the API has also been improved.
  
 
See [[Xtext/Documentation#Content_Assist| Content Assist]]
 
See [[Xtext/Documentation#Content_Assist| Content Assist]]
Line 38: Line 38:
 
== Declarative Scoping ==
 
== Declarative Scoping ==
 
Implementing scopes can be done in a more declarative way now.
 
Implementing scopes can be done in a more declarative way now.
See [[Xtext/Documentation#Declarative_Scope_Provider| Declarative Scope Provider]];
+
See [[Xtext/Documentation#Declarative_Scope_Provider| Declarative Scope Provider]]
  
 
== Toggle Comment ==
 
== Toggle Comment ==
Line 57: Line 57:
  
 
== Manifest Merging ==
 
== Manifest Merging ==
The generator merges entries, that are contributed by generator fragments, into the existing MANIFEST.MF files of your plugins. This prevents the user from missing required entries and custom entries don't get lost. Altough it is not a bullet proof solution it is quite useful even in its current shape.
+
The generator merges entries, that are contributed by generator fragments, into the existing MANIFEST.MF files of your plugins. This prevents the user from missing required entries and custom entries don't get lost. Altough it is not a bulletproof solution it is quite useful even in its current shape.
  
 
== Alternative assignments ==
 
== Alternative assignments ==
Line 78: Line 78:
  
 
== Xtext Parser supports full backtracking ==
 
== Xtext Parser supports full backtracking ==
Our own parser implementation now supports full backtracking. Usually packrat parsers only track back to the last alternative, but don't question successfully parsed optional sections. The xtext parser now does so (Antlr already did).
+
Our own parser implementation now supports full backtracking. Usually packrat parsers only track back to the last alternative, but don't question successfully parsed optional sections. The Xtext parser now does so (Antlr already did).
  
 
== API policy ==
 
== API policy ==
Line 102: Line 102:
 
In UI there are now three points where validation is triggered. Each points passes different user data into the validation, so that validators can
 
In UI there are now three points where validation is triggered. Each points passes different user data into the validation, so that validators can
 
decide what constraints should be evaluated. Those three different modes are defined in org.eclipse.xtext.validator.CheckType
 
decide what constraints should be evaluated. Those three different modes are defined in org.eclipse.xtext.validator.CheckType
 
  
 
  public enum CheckType {
 
  public enum CheckType {
Line 112: Line 111:
 
# during editing with a delay of 500ms, only FAST is passed
 
# during editing with a delay of 500ms, only FAST is passed
 
# on save NORMAL is passed
 
# on save NORMAL is passed
# an action, which can be optionally generated for you DSL explicitely evaluates EXPENSIVE constraints
+
# an action, which can be optionally generated for you DSL, explicitely evaluates EXPENSIVE constraints
  
 
== EMF generator included ==
 
== EMF generator included ==

Revision as of 07:50, 16 December 2009

Xtext 0.7 has been developed from scratch to meet scalability and flexibility requirements.

New & Noteworthy M7

Enum Rules

It's now possible to use EMF enums in grammars. Example: enum Foo :

  FOO='foo' |
  BAR='bar';

See Enum Rules

Lazy Linking

The linking is done lazily now. The solves two different issues. 1) You don't have to care about the order of linking anymore 2) Things which are not navigated are not linked, hence no deep, transitive linking anymore.

Content Assist (reworked)

The content assist is finally in the shape we wanted it to be. The behavior in the editor is closely aligned to what is know from Eclipse JDT and the API has also been improved.

See Content Assist

Template Proposals

Template proposals are now activated by default. Just put a templates/templates.xml in place and you're done. There's even a preference page allowing to export/import and edit templates at runtime.

Xtext template proposalspref page.png


Syntax Coloring Preference Page

The syntax coloring can be changed at runtime using a preference page.

Xtext syntax coloring pref page.png

Declarative Scoping

Implementing scopes can be done in a more declarative way now. See Declarative Scope Provider

Toggle Comment

Xtext ships with a generic implementation of "Toggle Comment" as known from JDT. If your grammar has a rule SL_COMMENT, your editor will provide the functionality to comment / uncomment code automagically.

New & Noteworthy M6

New pluggable generator API

In M6 the generator has been redesigned. The generator generating the language infrastructure from one (or more) grammar file is composed of so called GeneratorFragments. Each generator fragment gets different callbacks to participate in the generation process. A fragment can

  1. contribute to plugin.xml
  2. declare required bundles
  3. declare exported packages
  4. contribute to Guice modules

In addition each fragment gets a primary callback where it can generate arbitrary artifacts into the runtime or ui bundle.

Manifest Merging

The generator merges entries, that are contributed by generator fragments, into the existing MANIFEST.MF files of your plugins. This prevents the user from missing required entries and custom entries don't get lost. Altough it is not a bulletproof solution it is quite useful even in its current shape.

Alternative assignments

Alternatives can be used in assignments or cross references to create advanced language features and convenience. The following short example documents the feature. The input:

entity entityName extends 'other entity with spaces'

can be described with this short grammar snippet:

Entity:
  'entity' name=(ID|STRING) 'extends' parent=[Entity|(ID|STRING)];

Non-assigning actions

It is possible to use non-assigning actions in parser rules, to instantiate semantic objects of a special type. One can write the following grammar snippet, to create a specific type without any assignment.

FooOrBar :
   'foo' {Foo}
 | 'bar' {Bar};

Xtext Parser supports full backtracking

Our own parser implementation now supports full backtracking. Usually packrat parsers only track back to the last alternative, but don't question successfully parsed optional sections. The Xtext parser now does so (Antlr already did).

API policy

We've identified some stable API (very few at this point). More important we've described how we handle API lifecycle and contracts in general (see Xtext/Documentation/API).

Convenient EValidator

We've created a AbstractDeclarativeEValidator class, which lets you specify constraints in a declarative manner using annotations. Example:

public class XtextValidator extends AbstractDeclarativeValidator {

  @Check
  public void checkGrammarUsesMaxOneOther(Grammar grammar) {
    assertTrue("You may not use more than one other grammar.", XtextPackage.GRAMMAR__USED_GRAMMARS, grammar
                 .getUsedGrammars().size() <= 1);
  }
}

EValidators are created by Guice, so that you can use injection.

Different validation hooks

In UI there are now three points where validation is triggered. Each points passes different user data into the validation, so that validators can decide what constraints should be evaluated. Those three different modes are defined in org.eclipse.xtext.validator.CheckType

public enum CheckType {	
  FAST,	
  NORMAL,	   
  EXPENSIVE; 	
}
  1. during editing with a delay of 500ms, only FAST is passed
  2. on save NORMAL is passed
  3. an action, which can be optionally generated for you DSL, explicitely evaluates EXPENSIVE constraints

EMF generator included

The EMF generator fragment reuses EMF's generator. So we now have Java API for the derived meta model. This is done transparently, the genmodel cannot extensively be configured. Programming against the generated API is not only far more convenient the generated implementations also perform much better.

Use of MinimalEObject

Xtext now uses the MinimalEObject implemention introduced in EMF 2.5. This has significantly reduced the memory footprint and at the time (surprise) is a bit faster.

Xtext Wizard

The Xtext project wizard has been reworked, to reflect the latest changes. You can now start working with MWE and Xpand as used to in oAW Xtext.

Navigation

The navigation accross different resources is much more convenient now. You can use go to declaration (F3 by default) on almost any cross link to find the definition of its referenced instance. The hyperlink support has been enhanced, too.

Outline

XtextSampleOutline.png

Back to the top