>>>>> On Thu, 28 Jun 2012 10:29:44 -0700 (PDT), Phil Webb <pwebb_at_vmware.com> said:
PW> I would prefer to not see a mandatory dependency but don't have a
PW> big problem with optional dependency. Still, my gut feeling is that
PW> adding a jsonToMap() function is something that the developer should
PW> be doing themselves for now rather than being provided.
PW> Perhaps in the future, when JSR-353 is final, passThroughAttributes
PW> could be changed to support JSON Strings directly?
EB> I'm in the process of finding out the status of JSR-353 relative to
EB> EE7.
It is planned to be in for EE7.
EB> In the meantime, I propose we modify the spec for this function to
EB> say that it is only required to work in containers that have a JSON
EB> parser available. Given how strongly the community feels about
EB> this, and how isolated and self-contained it is, I'd like to leave
EB> it in.
EB> Does that sound good?
PW> That sounds good to me.
FC> +1
>>>>> On Fri, 29 Jun 2012 18:09:45 +0200, Bernd Müller <bernd.mueller_at_ostfalia.de> said:
BM> sounds good for me
>>>>> On Fri, 29 Jun 2012 12:38:11 -0400, Kito Mann <kito.mann_at_virtua.com> said:
KM> +1
>>>>> On Fri, 29 Jun 2012 18:56:08 +0200, Imre Oßwald <ioss_at_pmx.jevelopers.com> said:
IO> +1
>>>>> On Fri, 29 Jun 2012 10:43:54 -0700, Blake Sullivan <blake.sullivan_at_oracle.com> said:
B> I don't have a vote, but it seems kind of weird to specify this in JSF
B> 2.2 and then say that this only works on a container that ships with
B> such an implementation. The fact that this code is so self-contained
B> screams out that it does not need to be in the specification. Instead
B> we should be creating a bucket of everything that we want to do that has
B> a dependency on EE7 and if we have copious time to work on designing
B> those features instead of cleaning up everything we have talked about in
B> JSF 2.2, we can and we can do a quickie JSF 2.3 release as a follow on
B> to EE7. In general, I would rather have one good feature than ten
B> poorly specified features that will haunt us forever.
B> I understand the allure of working on nice self-contained features, but
B> if those features don't need to be in the spec we probably shouldn't be
B> spending time on them for two reasons:
B> 1) The opportunity cost--the time we spend talking about, specifying and
B> implementing these features is time we don't spend solving problems that
B> our customers can not solve themselves
B> 2) If we let a third party go first, we can leverage their experience
B> and avoid specifying the wrong behavior.
B> 3) When features don't clearly fall in our bailiwick, there is a risk of
B> contention with other parts of the EE platform. For example, I could
B> easily see the EL specification wanting to specify a number of these
B> kinds of EL functions.
This is a tough call. I hate to pull it out because it is so
self-contained, but Phil and Blake are right that it's wrong to ask
users to gather such detailed information about their implementation
just so they can use a feature.
Considering that JSR-353 is planned for EE7, perhaps we can put it back.
I'll take it out (again) and make the source available on the issue
tracker issue for 1089.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 10 Business days til JSF 2.2 Public Review to EG