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 "Unified EL Design Tasks"

(Facet Mechanism for Framework Selection)
(Managed-Bean Data)
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Facet Mechanism for Framework Selection ==
 
== Facet Mechanism for Framework Selection ==
 +
 +
Please see: [[EL_Versioned_Framework_Selector]]
  
 
A mechanism based on WTP-based facets that:
 
A mechanism based on WTP-based facets that:
Line 17: Line 19:
  
 
== EL Variable Support ==
 
== EL Variable Support ==
 +
 +
Please see:  [[EL Variable Support]]
  
 
A generic mechanism by which non-JSF sources contribute design time EL symbol information.  Emphasis is on supporting JSTL tags like c:forEach.
 
A generic mechanism by which non-JSF sources contribute design time EL symbol information.  Emphasis is on supporting JSTL tags like c:forEach.
  
 
== Java 1.5 Support ==
 
== Java 1.5 Support ==
 +
 +
Please see: [[Java_1_5_Support]]
  
 
Type signatures and semantic analysis mechanisms must be updated to support Java enumerations and generics.
 
Type signatures and semantic analysis mechanisms must be updated to support Java enumerations and generics.
  
 
== Composite Type Descriptor ==
 
== Composite Type Descriptor ==
 +
 +
Please see: [[Composite_Type_Descriptor]]
  
 
Type descriptors are currently used to describe the type of a variable or property and what child properties they have.  Currently a symbol can only be described as being of a single type.  A composite type descriptor needs to be added to support the fact that an EL symbol may be of multiple types.  For example a managed bean may be considered to be a JavaBean but may also be treated as a List or Map if it implements these interfaces.
 
Type descriptors are currently used to describe the type of a variable or property and what child properties they have.  Currently a symbol can only be described as being of a single type.  A composite type descriptor needs to be added to support the fact that an EL symbol may be of multiple types.  For example a managed bean may be considered to be a JavaBean but may also be treated as a List or Map if it implements these interfaces.
  
 
== EL Validation Rules ==
 
== EL Validation Rules ==
 +
 +
Please see: [[EL_Validation_Rules]]
  
 
The validation rules used for EL expressions both in JSF 1.1 and 1.2 need to be enumerated.  This will feed a new piece of configuration UI that allows the tool end-user to modify the enablement and severity of different problems found by the validator in a similar way to that which JDT currently provides with Java problems.
 
The validation rules used for EL expressions both in JSF 1.1 and 1.2 need to be enumerated.  This will feed a new piece of configuration UI that allows the tool end-user to modify the enablement and severity of different problems found by the validator in a similar way to that which JDT currently provides with Java problems.
  
 
== Managed-Bean Data ==
 
== Managed-Bean Data ==
 +
 +
Please see: [[Managed-Bean Data]]
  
 
Managed bean data can be embedded with the bean declaration in the faces-config.xml file. This data can be used to improve what the EL framework knows about managed beans and can improve validation and content-assist features.
 
Managed bean data can be embedded with the bean declaration in the faces-config.xml file. This data can be used to improve what the EL framework knows about managed beans and can improve validation and content-assist features.

Latest revision as of 19:48, 3 October 2006

Facet Mechanism for Framework Selection

Please see: EL_Versioned_Framework_Selector

A mechanism based on WTP-based facets that:

  • allows the end-user to define which version of Unified EL is in use. This is done indirectly by the selection of JSF facet version.

Design-Time EL Context Framework

Please see: EL_Context_Framework_Design

A new extension point-based, extensible framework that:

  • parallels the ELContext API provided by Unified EL.
  • allows third-party contributors to add design time analogous to runtime ELResolvers, FunctionMapper and Variable Mapper objects.
  • provides a context-based mechanism (extending context resolvers) for selecting the correct ELContext to resolve a unified EL expression.
  • a simple, comprehensive mechanism through which tool end-users can configure third-party contributions in use.

EL Variable Support

Please see: EL Variable Support

A generic mechanism by which non-JSF sources contribute design time EL symbol information. Emphasis is on supporting JSTL tags like c:forEach.

Java 1.5 Support

Please see: Java_1_5_Support

Type signatures and semantic analysis mechanisms must be updated to support Java enumerations and generics.

Composite Type Descriptor

Please see: Composite_Type_Descriptor

Type descriptors are currently used to describe the type of a variable or property and what child properties they have. Currently a symbol can only be described as being of a single type. A composite type descriptor needs to be added to support the fact that an EL symbol may be of multiple types. For example a managed bean may be considered to be a JavaBean but may also be treated as a List or Map if it implements these interfaces.

EL Validation Rules

Please see: EL_Validation_Rules

The validation rules used for EL expressions both in JSF 1.1 and 1.2 need to be enumerated. This will feed a new piece of configuration UI that allows the tool end-user to modify the enablement and severity of different problems found by the validator in a similar way to that which JDT currently provides with Java problems.

Managed-Bean Data

Please see: Managed-Bean Data

Managed bean data can be embedded with the bean declaration in the faces-config.xml file. This data can be used to improve what the EL framework knows about managed beans and can improve validation and content-assist features.

Back to the top