Hi,
With Jakarta Faces 4.1 being released, it's maybe a good time to file the official release plan for Faces 5.0 targering Jakarta EE 12.
We had of course filed that plan before, but we later renamed it to 4.1 and moved some of the features around.
The following items for 5.0 were already closed/done:
- Move API sources from Mojarra project to here
- API will be split off from the implementation code - step 1
- Introduce FacesServletFactory
- Add context param attributes to @FacesConfig
Deprecation / clearing up signatures:
- Faces 5.0: remove things marked @Deprecated(forRemoval = true, since = "4.0")
- Remove UIComponent.bindings field
- Missing Generics in Faces Standard Converters
- Make SelectItem#value generic
- Remove deprecated code (composite:extension, PreDestroyCustomScopeEvent, PostConstructCustomScopeEvent, UIComponent.bindings)
CDI:
- CDI: Allow non-component Faces events observeable by CDI
- CDI: Allow listing to PhaseEvents via @Observes
- Create TypeLiteral Constants
Other:
- Allow redirect via Annotation on action
- Allow refreshable ValueExpression for validator/converter/behavior tags
- Add new FacesMessage Severity "SUCCESS"
- Allow custom FacesMessage Severities
- Fix behavior attachment for composites / provide a API
- Port p:autoUpdate to Faces API?
- ui:repeat clarification on attributes, such as offset and size
- Enhance UIInput events with HTML5 like oninput
- Setting/overriding components default value
- String based context params having fixed set of allowed values should be represented by enums
- importConstants should be allowed everywhere, not only in f:metadata
- Automatically pass through all on* event attributes
- Enhance UIViewRoot#resetValues() to pass VisitHints
Questions:
- Unify NavigationHandler and ConfigurableNavigationHandler?
- Discussion: Can we make facets updateable?
- Remove class scanning and rely on CDI only?
- Specify what Faces should do when f:metadata is not a direct child of f:view
What should we put in the plan?
All of this? A subset? Some new items?
I personally would like to see if we can get the API to a state where we have no more Mojarra specific code. Moving the component implementation code however is not that easy, because of inheritance.
Thoughts?
