Skip to main content
[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.
-- 
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx

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




On Fri, 21 Jun 2024 at 21:54, Edwin Amoakwa via faces-dev <faces-dev@xxxxxxxxxxx> wrote:
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 ?



On Fri, Jun 21, 2024 at 5:42 PM Arjan Tijms via faces-dev <faces-dev@xxxxxxxxxxx> wrote:
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




  

























  Back to the top