| Re: [mojarra-dev] Mojarra.Next |
Hi,On Mon, Jan 8, 2018 at 8:23 PM, Thomas Andraschko <andraschko.thomas@xxxxxxxxx> wrote:how can i subscribe to the new mailing list?It's done here; https://accounts.eclipse.org/mailing-list/mojarra-devI 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?That's up to us to decide I guess.What we could do is release an (official) 2.4 as soon as the Mojarra and Spec projects are transferred. I haven't been informed about any timeline yet, but if it would "soon-ish" we could release a 2.4 almost as the master is now. So no or very little new features. Perhaps just the wrapper class that Bauke recently suggested as new API.Then for 3.0 at least remove a lot of deprecated things indeed.
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/javaserverfaces-spec/issues/1443:Both 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#Eventbroadcasting)This 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#Eventbroadcasting)Usefull feature to listen e.g. on PostConstructApplicationEvent, when @Initialized(ApplicationScoped) is to early if you need a FacesContext.+1 for both. Indeed, that's continuing the "CDI-ify" story that was started in JSF before. There's other ways to do event like functionality in CDI, like intercepting the artefacts that emit them, but events in addition to that have their place too, I think.Others:
- 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/javaserverfaces-spec/issues/1419:
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?Specifically about this one; JSTL has its uses, but indeed, it's also incredibly confusing. And this confusion is not only for the users of JSF, but also for the implementors. Keeping track of modifications to the component tree done by JSTL is non-trivial.- 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/javaserverfaces-spec/issues/1150:- Nice to have, not important: https://github.com/javaee/javaserverfaces-spec/issues/1426
Allow NavigationMode via Method-Annotation instead of "?faces-redirect=true" in the string...from a developer perspective:
- https://github.com/javaee/javaserverfaces-spec/issues/1420
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 themAbout that last one, there were various ideas floating around (for a long time even) about reducing some of the clutter around creating components by making better use of runtime annotations. See e.g. my own post here: http://arjan-tijms.omnifaces.org/2014/07/jsf-23-wish-list-part-i-components.htmlA CDK such as used by both MyFaces and PrimeFaces (and I think RichFaces had something earlier too) is strongly related to that.All of these are good suggestions though, and I'd like to start with something practical here before long. Since there's no spec process active yet, that would have to be done in experimental forks then.Kind regards,Arjan TijmsBest 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/javaserverfaces/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?_______________________________________________
mojarra-dev mailing list
mojarra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mojarra-dev