Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EL Versioned Framework Selector

Overview

Note: this framework is currently proposed to solve the narrow problem of EL entity selection, but we may decide to generalize ELVersionSupport to simply VersionSupport and support the versioning of any common entity

The framework requirements for design-time EL differ significantly between Unified EL and previous versions. Both syntantic and semantic changes have been made to the specification. Wholesale changes have also been made to the mechanism for symbol resolution and new types of symbols, like EL variables, have been added. Therefore the Unified EL exists as a separate framework from prior versions, sharing design and code only where backward compatibility needs to be supported.

To support two separate versions of the EL framework co-existing in the tooling at one time a mechanism is necessary to allow users of the framework to transparently select the correct version based on the version of the application being edited.

EL Version Selector

ELVersionSupport.png

The class that manages the versioned support of framework objects is ELVersionSupport. ELVersionSupport manages zero or more VersionedEntity objects. Each VersionedEntity represents a particular framework facility that provides different functionality depending on the underlying version in use. Thus, each VersionedEntity has one or more related entities: one for each supported version.

An example of the use of a VersionedEntity is a symbol resolver interface for EL. When requesting a symbol resolver, a client can make a request to ELVersionSupport for the versioned entity and then request a specific Entity for the desired version. The sequence diagram below shows this flow:

VersionedEntitySelection.png

In the case of EL symbol resolvers for JSF, if the EL version in use is for JSF 1.1, then a DTVariableResolver or DTPropertyResolver would be returned. For Unified EL, a DTELContext or DTELResolver would be returned. The client must know what it expects to get back for a particular entity. A wrapper class may need to be defined to provide a common object that can be returned if the entities for each supported version differ radically from one another.

Facet-based Versioning

ELVersionSupport also supports an automatic entity mode that determines the "current version" in use by querying a project's facet. For example, if a client requests an EL parser for the current project, ELVersionSupport queries the dynamic web and JSF project facet version configuration and internally selects the appropriate Entity instance to return to the client. This allows client code to be decoupled from the version of an entity it is using.

Defining a VersionedEntity

A VersionedEntity is defined using the "versionedEntity" extension point. This extension point allows a contributor to define a unique key for the entity and a wrapper class that returns the actual entity. On initialization, ELVersionSupport loads all "versionedEntity" extensions. For each unique id defined by a "versionedEntity", a second extension called "versionedEntityInstance" can be used to specify a specific instance of an Entity.

Automatic version selection

To support the ability for ELVersionSupport to automatically select the current version of an entity, the "versionEntity" extension point also supports a "versionSelection" option. This option supports a similar syntax to the Project Facet versioning constraints system for specifying matching rules that determine what the 'current' version of a entity is based on in the currently configured Project Facet versions.

Back to the top