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.
Difference between revisions of "Unified EL Design Tasks"
(→Composite Type Descriptor) |
(→Managed-Bean Data) |
||
(11 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: |
− | - | + | * 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 == | == Design-Time EL Context Framework == | ||
+ | |||
+ | Please see: [[EL_Context_Framework_Design]] | ||
A new extension point-based, extensible framework that: | A new extension point-based, extensible framework 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. | ||
== 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. |
Latest revision as of 19:48, 3 October 2006
Contents
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.