I wholeheartedly disagree the need for an additional context param to
enable new features. Either do it automatically, or do the opposite
(disable by context param). This has always worked that way across previous
JSF versions. E.g. enable restore view 1.1 compatiblity, validate empty
fields, partial state saving, etc.
The idea was always been to get started to full extent with zero
configuration.
Cheers, B
On Tue, Jun 16, 2015 at 12:11 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> In thread 1078-DataModelRegistrable the issue came up about configuration
> to enable new features/behavior in JSF 2.3.
>
> Perhaps it's a good idea to discuss this separately in a new thread.
>
> The issue at hand is that from JSF 2.3 m03 on there's an explicit context
> parameter needed to activate a major new behavior; letting CDI resolve
> named beans, aka the EL implicit objects (see eg
> http://javaevangelist.blogspot.nl/2013/04/jsf-2x-tip-of-day-jsf-expression.html).
> E.g. things like "application", "facesContext", etc. Due to the way CDI
> works all these things are simultaneously available for injection by the
> same mechanism.
>
> Now there are basically two options:
>
> 1. By default JSF 2.3 does things in the latest and best way. If the old
> behavior is required this can be configured.
>
> 2. By default JSF 2.3 does things in the old and not best way. If the new
> behavior is desired this can be configured.
>
> Each option has pros and cons.
>
> With option 1, someone who starts with JSF and that version happens to be
> version 2.3 likely does not care about (for this person) obscure behavior
> from an old JSF version. So for this use case in particular it's best that
> the latest way is the default way.
>
> With option 2, someone who already uses JSF 2.2 or older has a higher
> chance to run an older JSF 2.2 application unchanged on JSF 2.3. So for
> this use case it's best that the old way is the default way.
>
> There's historical precedent for option 1. E.g.
>
> * JSF 1.1/1.2 com.sun.faces.enableRestoreView11Compatibility (default was
> the new behavior; throwing ViewExpiredException, old behavior could be
> configured)
> * JSF 1.2/2.0 javax.faces.PARTIAL_STATE_SAVING (default was the new
> behavior; saving state partially; old behavior (full state saving) could be
> configured).
>
> A particular disadvantage of option 2 would be that if you kept doing
> this, then 5 versions later you may potentially have to start a brand new
> JSF application by a mandatory configuration of 5 options for all the
> things that were introduced since JSF 2.2, which is somehow a "blessed"
> base version that's always the default no matter what the actual JSF
> version is (2.3, 2.4, 3.0, 4.1, etc).
>
> In a way there's a third option as well; have the old behavior be the
> default for one version, then make the new behavior the default in a later
> version.
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>