|Re: [mojarra-dev] Mojarra.Next|
how can i subscribe to the new mailing list?
I will just post my wishes now - Probably we should do something like a mail on the mailing list + voting for each part?I think you also have many wishes as OmniFaces provides also many util features.Also, what about removing deprecated things or add more depreactions?Will the new version 2.4 or 3.0?
If 3.0 -> we should really do a cleanup >if possible<...@ManagedBeans, JSP, JSTL, ...?I think there are many more.Never the less - Here are my personal wishes......from a JSF enduser perspective:- https://github.com/javaee/javaBoth of those features are really simple and i use it in my daily work very often. I could also provide them and lead the development as i have developed or helped with those features in DeltaSpike:
Observer phases via CDI Observer (https://deltaspike.apache.org
/documentation/jsf.html#Eventb) roadcastingThis is really useful to observe those events in backing beans. This would maybe require to switch PhaseId to a enum - or maybe other solutions.- Observe JSF system events via CDI Observer (https://deltaspike.apache.org /documentation/jsf.html#Eventb) roadcastingUsefull feature to listen e.g. on PostConstructApplicationEvent, when @Initialized(ApplicationScoped ) is to early if you need a FacesContext.
- f:autoUpdate. Simple TagHandler that can be attached to every component to enable auto-updates on every request.
We must also add a additional flag then to f:ajax, which marks the request as "don't execute autoUpdate's". We call it "ignoreAutoUpdate".I did this in PF, i could lead this change.- https://github.com/javaee/java
support all the new html5 events (like oninput)- on a update, the focus from the input(s) is lostI remember there was a discussion for 2.3. The problem is here that we don't replace just the value or style attribute, we replace the whole markup.If we implement this correctly, this could really boost JSF to a more modern level. Take a look at the new JS frameworks, they never replace the whole markup.This MAY be a performance boost and usability boost (reduce flickering, lost focus..) but we have to discuss this very wisely.- partialSubmit (maybe be quite hard to support in the spec, we have to discuss this)- JSTL - should we search for alternatives + deprecate the usage? c:forEach/ui:repeat was always very confusing for the users.Are there improtant tags? c:set?
- Nice to have, not important: A CDK- Repeat interface vs fix Mojarra ui:repeat (can't remember the exact details but there was a discussion for 2.3. We did a workaround in PF and introduced p:repeat)- https://github.com/javaee/java- Nice to have, not important: https://github.com/javaee/java
Allow NavigationMode via Method-Annotation instead of "?faces-redirect=true" in the string...from a developer perspective:
API to add AttachedObjectHandler. This is currently the only real impl specific Hack in whole PrimeFaces.
Add a ClientWindowScope (we already have our ClientWindow...)
- Nice to have, not important: Better window modes - we have some of them in DeltaSpike but as the web changes quite fast, i'm not sure if we should define them
Best regards,Thomas2018-01-08 19:16 GMT+01:00 arjan tijms <arjan.tijms@xxxxxxxxx>:Hi everyone,I'm not sure how many people are already subscribed to the Mojarra dev mailing list at Eclipse, but let's start with writing a first message here ;)While the transfer from Oracle to Eclipse is still in progress, it might be a good idea to start discussing some ideas for the next version of Mojarra here. Since the release of 2.3, I've been personally working on a refactoring in the master over at https://github.com/javaserv
erfaces/mojarraBefore long I'd like be looking at creating a fork to experiment with some potential new features for JSF.Next, which can then later be donated to the JSF spec.Thoughts?
Back to the top