jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: OpenAjax has ceased operations. Should we remove it from JSF?

From: Ted Goddard <ted.goddard_at_icesoft.com>
Date: Tue, 17 Dec 2013 09:28:10 -0700

I agree it should be removed as well. One useful function
of OpenAjax was namespace reservation, and this is something
the JCP could provide (whether JavaScript developers would
adhere to a JCP standard is another question).

Ted.


On Dec 17, 2013, at 4:17 AM, Cagatay Civici <cagatay.civici_at_gmail.com> wrote:

> +1 on removal,
>
> Regards,
>
> Cagatay Civici
> PrimeFaces Lead
> PrimeTek Informatics
> www.primefaces.org
> On Tuesday 17 December 2013 at 10:30, Bernd Müller wrote:
>
>> Hello,
>>
>> I think we should remove it because it's awkward to build on "legacy"
>> specs/systems.
>>
>> Bernd
>>
>> Am 16.12.2013 23:15, schrieb Edward Burns:
>>> Hello Volunteers,
>>>
>>> We were talking about Ajax on JSR-362 and I suggested they use OpenAjax
>>> over there like we do in JSF. I looked into it and here's what I found.
>>>
>>>>>>>> On Tue, 10 Dec 2013 12:00:17 -0800, Edward Burns <edward.burns_at_oracle.com> said:
>>>
>>> EB> Hello Volunteers,
>>> EB> As promised, here is the text from the JSF spec about usage of OpenAjax
>>> EB> in the jsf.js file.
>>>
>>> EB> 8<---------------
>>>
>>> EB> 13.2 JavaScript Namespacing
>>>
>>> EB> JavaScript objects that are not enclosed within a namespace are global,
>>> EB> which means they run the risk of interfering, overriding and/or
>>> EB> clobbering previously defined JavaScript objects. This section defines
>>> EB> the requirements for implementations intending to use the JavaServer
>>> EB> Faces 2.0 JavaScript API.
>>>
>>> EB> The Open Ajax Alliance is an organization of leading vendors, open
>>> EB> source projects, and companies using Ajax. Their prime objective is to
>>> EB> accelerate customer success with Ajax, through the use of open
>>> EB> standards. The Open Ajax Registry is an industry-wide Ajax registration
>>> EB> authority managed by the OpenAjax Alliance. The Registry maintains
>>> EB> industry- wide lists of Ajax runtime libraries to help prevent object
>>> EB> collisions.
>>>
>>> EB> There is a top level namespace jsf that is registered with the Open Ajax
>>> EB> Alliance:
>>>
>>> EB> Java Ajax: {
>>> EB> namespaceURI:"http://www.sun.com",
>>> EB> version:"1.0",
>>> EB> globals_to_approve:["jsf"],
>>> EB> comments: "Used in the JSF 2.0 specification.",
>>> EB> specificationURI:"http://www.jcp.org/en/jsr/detail?id=316",
>>> EB> email: "jsfaces_at_sun.com"
>>> EB> }
>>>
>>> EB> [P1-start openajax registration]If the OpenAjax library is available,
>>> EB> libraries must register themselves using OpenAjax.registerLibrary() at
>>> EB> the time when the JavaScript files are fetched and parsed by the
>>> EB> browser\u2019s JavaScript engine. [P1-end]
>>>
>>> EB> if (typeof OpenAjax != "undefined" &&
>>> EB> typeof OpenAjax.hub.registerLibrary != "undefined") {
>>> EB> OpenAjax.hub.registerLibrary("jsf", "www.sun.com", "1.0",
>>> EB> null); }
>>>
>>> EB> --
>>> EB> 8<---------------
>>>
>>> EB> Unfortunately, I now see this text on the website:
>>>
>>> EB> "The following organizations were Members of OpenAjax Alliance at the
>>> EB> time OpenAjax Alliance terminated formal operations:" A little research
>>> EB> revealed this email about the termination:
>>>
>>> EB> http://openajax.org/pipermail/steeringcommittee/2012q4/001015.html
>>>
>>> EB> And this article, now nearly four years old.
>>>
>>> EB> https://devcentral.f5.com/articles/5-years-later-openajax-who#.UqdusoG7liw
>>>
>>> EB> Basically, it seems OpenAjax is dead. Anyone care to comment on whether
>>> EB> we should bother with it in JSR-362?
>>>
>>> My question here in this group is: should we remove our mention and
>>> usage of OpenAjax in the JSF spec?
>>>
>>> Ed
>