ariatemplates/editor-frontend-eclipse

Eclipse plugin editor for AT

Aria Templates - JavaScript Framework

Aria Templates (aka AT) is an application framework written in JavaScript for building rich and large-scaled enterprise web applications. Developed since 2009 by Amadeus for its professional products, it has been designed to build web apps used intensively that need to display and process a high amount of data with a minimum of bandwidth consumption.

Some details

Aria Templates in a nutshell:

• MVC based framework
• powerful templating engine
• data binding and automatic refresh
• widgets libraries
• lots of utilities libraries

The MVC's terminology in AT:

• model -> JSON-based data model stored in DOM nodes corresponding to templates
• view -> template (.tpl file)
• controller -> module controllers and template scripts (.js files)

Templates can either be evaluated client-side or precompiled at build time.

Getting started

To get started with Aria Templates, you have several options:

• you can clone our Git repository / download a ZIP from GitHub and then include bootstrap.js file in your HTML page, to run the original, development source code,
• after obtaining our source code, you may run Grunt build and then include a packaged, minified (much faster) version of the framework in your page,
• or to use the framework in your NodeJS application, issue npm install ariatemplates in the command line, then call require('ariatemplates') from your code to load the framework.

Head to README.md files in src and build folders to read more.

License

Apache License 2.0

Browser support

• Firefox latest
• Chrome latest
• Edge latest

For accessibility, we support the combination of Edge (latest) with Jaws 2021.

Dependencies

The framework itself doesn't have any external dependencies.

We use Grunt, JSHint, UglifyJS, attester and a couple of other tools for building and testing.

Tools & apps

Syntax highlighters:

• Notepad++ syntax highligher for Aria Templates
• Sublime syntax highlighter for Aria Templates
• We're working on a syntax highlighter & full blown editor plugin for Eclipse

Other tools:

• Yeoman generator for AT project scaffolding
• Snippets and even more snippets for Sublime Text
• Aria Templates aware JS Deminifier plugin for Firefox/Firebug

Feel invited to contribute highlighters for editor of your choice, or other useful tools!

Testing

• Attester is the tool we use for running Aria Templates tests. You may also use it for running tests of your project.
• Aria Templates TDD guide can help you writing tests for AT widgets and templates

Releases & backward compatibility

We release a new minor version (1.3.5, 1.3.6, ...) every 3 weeks, containing new features and bugfixes. Each version is thoroughly tested before the release. These releases are backward compatible. Occasionally we also backport important fixes to some of the older releases (1.3.1A, 1.3.1B etc.) - see tags.

Twice or three times a year, we issue a non-backward-compatible release, bump the the second digit (e.g. 1.3.x -> 1.4.1) and provide migration guide.

Before removal, items are marked as deprecated for at least 9 weeks (usually much more). We inform about deprecation in the docs, release notes and by flooding your console -- you won't overlook it.

Support & contributing

If you spotted some code problems in the framework, please open an AT issue or ideally, a pull request with the fix and a test.

See more in CONTRIBUTING.md and TDD guide for Aria Templates.

editor-frontend-eclipse's Issues

Fallback to a standard plain text editor when an a fatal error occurs with the backend

In fact, the idea can be expressed more generically:

never block the user because of a malfunctioning of the backend

or

always allow the user to edit a file in acceptable conditions, even in a degraded mode (without backend features)

Put constants in a separate file

Lets put all constant files in a Constants.java file to reduce clutter and enhance manageability. Better, if these can be added in a properties file for easy configuration.

For example Backend.java

Installation failure

When trying to install the plugin from the update site http://aria/ateditor/repository, I got the following error:

Cannot complete the install because some dependencies are not satisfiable
  com.ariatemplates.tools.ide.feature.feature.group [0.1.0.201405071744] cannot be installed in this environment because its filter is not applicable.

I am using Eclipse Helios Service Release 2.

Adding a VO instead of a hashmap is better OOP

In Backend.java, we are using HashMap, instead of that a VO will add more OOP features to it.

For example in below code snippet:

Instead of:

Map<String, Object> object = new HashMap<String, Object>();

lets use a VO:

public Map<String, Object> rpc(String module, String member, Object argument) throws ParseException, IOException, JsonSyntaxException, BackendException {
    Map<String, Object> object = new HashMap<String, Object>();
    object.put(Backend.KEY_MODULE, module);
    object.put(Backend.KEY_MEMBER, member);
    object.put(Backend.KEY_ARGUMENT, argument);

    String json = gson.toJson(object);

    StringEntity content = new StringEntity(json);
    this.rpc.setEntity(content);

    return this.postJson(this.rpc);
}

Change the base classpath of the source

In other words: change the root package classpath.

The root package is named poc for now. This was fine only while the project was actually at a stage of Proof of Concept. However this is not really the case anymore, and anyway it will have to change in the future.

This should be something more standard - i.e. following Java conventions - and related to the context of the project.

This could be something like com.ariatemplates.tools.editors.

Don't prefix class names with "POC" anymore

First, as issue #4 relates, POC doesn't have sense anymore. Then, namespacing should be enough for semantics.

Finally, only name collision is the issue. Either find a better prefix or use fully qualified names?

Implement the packaging of the plugin, embedding the backend server

The plugin must be able to embed the code of the backend server and to launch and manage an instance of it properly.

For now it's easier for the Eclipse plugin to communicate with an already running backend instance, that is launched externally.

There is still some work to do to enable the plugin to launch a backend packaged with it, especially because it is developed externally.

There are two kinds of environments to consider:

• development: just have a quick and dirty solution to make it work in development mode
• production: make it work in the context of a packaged plugin

For development, the sources of the server are available, and can be put inside the project. Therefore to launch it ( without hardcoding paths!! ), there is just a need to resolve the relative paths inside the project (i.e. equivalent to programatically find the path of the project).

For production, the problem is different.

First, once installed, the plugin will reside in the Eclipse installation, among every other bundles. The thing would be - as it is for development - to resolve the path of the plugin (but in this case it's not in the context of the project but the one of the Eclipse installation). Have a look at FileLocator.find: the Bundle required in this method can be taken from the Activator class of this project.

But then there is a problem due to the fact a plugin is packaged in an archive by default. If the Java system works fine with binaries contained in archives, it is not the case of the externally made server. It relies on a standard file system access.

For that there are two solutions:

• either finding a solution to execute the server in a virtual file system - personally I don't know how
• or finding a solution to extract the files of the archive for the server. See this thread on stackoverflow talking about plugin packaging: an option to avoid archiving would be available in case we wrap the plugin in an Eclipse feature.

NB: to bring files from the backend project into the Eclipse Plugin project without versioning issues, Git Submodules can be used (I think this is more suitable in this case than the alternative solution to handle subprojects that are Subtrees)

Highlighting: keywords are not necessarily properly tokenized

There is a rule (Word) in the highlighter which is able to parse a portion of a source code considering a set of alternative words. For instance:

• true or false for boolean tokens
• +, -, *, /, etc. for operator tokens

The technique this rule uses for parsing is not perfect (or maybe the problem comes from the model of rules), since it doesn't consider white spaces. In some cases, it's fine:

• var a = false;: we indeed want false to be detected as a boolean, even though there is no white space after
• var a = 2+2: same thing for this plus operator

However, in some cases, this is not suitable. Take for instance any identifier whose name begins with false, like false_assertion. The part false in the identifier will be tokenized as being a boolean.

Add a preferences page for user settings

Externalize some data as user preferences.

For now everything in the plugin is statically configured (it is often present as final static variables in the source code). There's no command line input, neither any possibility of configuration file input.

There should be a preferences page, a standard one like those we see in other Eclipse plugin (integrated to the preferences management of the whole application).

There are several kinds of things that can be configured:

• things related to the communication (and possibly integration) of the backend
• things related to desired behavior of the backend - configuration of the services
• things related to the plugin itself solely

This list is not exhaustive, neither is the following of suggested configurations: d:

• External backend re-use
  • enable external backend re-use or not
  • port on which the external backend is running
  • GUID identification pair: in case this changes on Backend side, no need to re-deploy a new version of the plugin with new static values, just configure it
• Backend program management (that is the plugin launches and manages an instance of the backend)
  • use embedded backend or external installation: even if the plugin can launch a backend, it can be desired to use an external, possibly shared, instance of the backend
  • path of the external installation: in case we don't want to use the backend source embedded in the plugin
  • use system Node.js installation (the one in the PATH) or not (migth require a specific version)
  • custom Node.js path in case we want to use one
  • port to use when launching a backend
  • enable to find and use first available port (some additional data might be required for that, like a range, ...)
  • launch timeout before fallback

Please complete this list!

Add tests

Components of the plugin should be tested.

We can use the classical JUnit solution for that.

Use the org.eclipse.ui.editors.documentProviders extension point or not?

Should we use the org.eclipse.ui.editors.documentProviders extension point or not?

We can manage without, as it is done for now, but maybe it's better for design purposes to use it.

It used to be configured like that in plugin.xml under extensions:

<extension
     point="org.eclipse.ui.editors.documentProviders">
  <provider
        class="poc.document.DocumentProvider"
        extensions="tpl"
        id="poc.document.DocumentProvider">
  </provider>
</extension>

but as far as I remember it had some quirks.

Provide everything that is needed to be able to serve this plugin from an update site

I don't know how Eclipse update sites work, but if there is something purely specific to this project, the latter should provide it.

This way it would be easy to set up any update site to serve this plugin, and thus easy for a user to install this plugin.

Here are some paths for research:

• http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fconcepts%2Fupdate_site.htm
• http://wiki.eclipse.org/FAQ_How_do_I_create_an_update_site_%28site.xml%29%3F

Remember that there should be nothing specific to where the update site will actually be hosted.

Code improvement suggestions

I was going through few Java files. Might be you can consider below suggestions.

• Backend.java
  1. Final static variable command can be renamed to COMMAND
  2. Few variables like gson can be declared final I suppose as it is initialized in the constructor
  3. How about using an if instead of switch as it has only one case (in postJson())
• Activator.java
  1. Do we need to write default constructor?
• POCDocument.java
  1. How about changing private GUID to guid as its a not a constant?
• POCDocumentPartitioner.java
  1. How about changing types to TYPES as it is final static?
• POCDocumentProvider.java
  1. How about changing mode to MODE as it is final static?
• POCTokenScanner.java
  1. Do we really need the default constructor?

I am not sure if code formatter is being used. If not will request to add a standard code formatter.

Enhance knowledge base about Eclipse plugins creations (RCP)

Eclipse Rich Client Platform (RCP) is a huge thing to digest.

This is the whole framework to build applications based on their corresponding engine. An application is a set of plugins. Some handle the GUI, others different stuff.

So to build a component - i.e. a plugin - of an Eclipse RCP application, the same framework is used.

However, the documentation is big and not that clear. Sometimes there is a lack of details. Also, that would be good to have wrapping up schemata, explaining the architecture of all the components.

Since what we are building is specific - source code edition - we should also explain this more precisely. There's a whole architecture around text editors, source viewers, documents management, edition services, ...

Highlighting makes all freeze sometimes

Image you have a template whose content is:

{Template {
    $classpath: "..."
}}

Now put the cursor at the very end, and keep pressing backspace. When you reach this state precisely:

{Template {
    $classpath:

Everything freezes (there is a lot of errors in the console by the way when debugging).

Unable to remove alignment done using tab

Unable to use shift + tab on eclipse