I don't have a vote, but it seems kind of weird to specify this in JSF
2.2 and then say that this only works on a container that ships with
such an implementation. The fact that this code is so self-contained
screams out that it does not need to be in the specification. Instead
we should be creating a bucket of everything that we want to do that has
a dependency on EE7 and if we have copious time to work on designing
those features instead of cleaning up everything we have talked about in
JSF 2.2, we can and we can do a quickie JSF 2.3 release as a follow on
to EE7. In general, I would rather have one good feature than ten
poorly specified features that will haunt us forever.
I understand the allure of working on nice self-contained features, but
if those features don't need to be in the spec we probably shouldn't be
spending time on them for two reasons:
1) The opportunity cost--the time we spend talking about, specifying and
implementing these features is time we don't spend solving problems that
our customers can not solve themselves
2) If we let a third party go first, we can leverage their experience
and avoid specifying the wrong behavior.
3) When features don't clearly fall in our bailiwick, there is a risk of
contention with other parts of the EE platform. For example, I could
easily see the EL specification wanting to specify a number of these
kinds of EL functions.
-- Blake Sullivan
On 6/29/12 9:56 AM, Imre Oßwald wrote:
> +1
>
> Imre
>
>