[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [faces-dev] Faces 5.0 release plan
|
Hi,
I strongly support deprecating old
"time" objects and use Java Time API where possible. And align
with ISO 8601 standard formats.
On 22. 06. 24 12:57, Arjan Tijms via
faces-dev wrote:
p.s.
Regarding compatibility with Date, we probably should
follow the example set by Jakarta Persistence and deprecate it
for removal.
Kind regards,
Arjan Tijms
Hi Also,
1. Can project stage be sent in another way ? other than
having to change always in web.xml before prod deployment ?
2. Is it time to consider something like omini-faces
SelectItemConveter ?, and use a FaceConveter if one is
available ?
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?
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev