@thomas: +1 if we don't need to use producers here, we should drop them again. (if someone would use it as a kind of "component-binding", it would be broken in almost every case.) -> the el-resolver approach mentioned by thomas is the only reliable way here. if we have to keep those producers, we have a spec. issue here and the best chance to limit the possible side-effects to a minimum are dependent-scoped instances and/or subclass-proxies which intercept all public method-calls to resolve the current instance lazily.
regards, gerhard 2017-09-01 9:42 GMT+02:00 Thomas Andraschko <[email protected]>: > Hi, > > i just checked the FacesScopeObjectProducer: > > @Produces > @Named("component") > @FacesScoped > public UIComponent getComponent() > { > return UIComponent.getCurrentComponent(FacesContext. > getCurrentInstance()); > } > > @Produces > @Named("cc") > @FacesScoped > public UIComponent getCompositeComponent() > { > return UIComponent.getCurrentCompositeComponent(FacesContext. > getCurrentInstance()); > } > > I wonder if this is this the right scope for it? > Shoudln't it be @Dependendent as the component changes multiple times? > Not sure about the performance then... I think it would be perform much > slower as in 2.2. > Does 2.3 force us to use @Named instead ElResolver for it? > > Regards, > Thomas >
