Hi all,
I've committed the base implementation of @FacesDataModel to the
Mojarra 2.3 trunk, and wrote a blog post about it here:
http://arjan-tijms.omnifaces.org/2015/07/jsf-23-new-feature-registrable.html
The current implementation does NOT allow overriding build-in
wrappers, but we can work on finding out how to best implement that in
a next step. I think that even without the ability to override the
feature is already useful, and with the base code in the followup
discussions are likely easier.
There are currently two different approaches to allow overrides:
1. We perform the analysis that Manfred requested and based on that
may relocate the check for user provided datamodel wrappers to the
beginning of the chain (as presented in a previous mail).
2. Annotate all existing JSF wrappers with @FacesDataModel (the
programmatic equivalent thereof actually) so there's no difference
anymore between the "magic chain" of build-in wrappers and the ones
that are registered. Depending on a switch JSF will then either only
look for @FacesDataModel, or will work through the chain such as is
done in the current commit.
My preference would be for option 2. Apart from the switch this is
actually what the original issue asked for and IMHO seems to be the
way forward. It's also quite similar to how the new EL resolving works
- with one value of a switch the JSF native EL resolver chain is used,
while with an other value this is left to CDI.
Thoughts?
Kind regards,
Arjan Tijms