+1 on that idea, especially given the jsf.js 2.2 dependency.
On Fri, Nov 16, 2012 at 7:45 AM, Mark Struberg <strub...@yahoo.de> wrote: > > > When client-window api get > > stable, we can backport it to 2.1 in one step, knowing the changes > > done and the implications. > > Ok, seems we agree now. Because this is exactly what I proposed: do the > clientWindow stuff in 2.2 to a point it is usable and the JSF API is stable > and then port it back to 2.1.x > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Leonardo Uribe <lu4...@gmail.com> > > To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg < > strub...@yahoo.de> > > Cc: > > Sent: Friday, November 16, 2012 4:40 PM > > Subject: Re: 2.1-windowId branch > > > > Hi > > > > Really the advantage to work in 2.1.x-client-window is if people is > > working in 2.2.x, there are chances that by some commit, the code gets > > unstable for some time. Since 2.1.x-client-window is JSF 2.1 + client > > window api does not contain any additional new feature, you can work > > safely with those artifacts. If there is a change there, we can run a > > merge and push them in 2.2.x (run that task is fairly simple). > > > > My suggestion is work in 2.1.x or 2.2.x. When client-window api get > > stable, we can backport it to 2.1 in one step, knowing the changes > > done and the implications. > > > > regards, > > > > Leonardo Uribe > > > > 2012/11/16 Mark Struberg <strub...@yahoo.de>: > >> I remember this a bit different. But maybe I'm wrong. > >> > >> Gerhard and I created all that windowId stuff in the first place in > CODI > > and pushed this feature to the spec as well (3 hours late night > discussion with > > Ed at the last con-fess) . The idea was to get this 'right' in JSF-2.2 > > first and only backport it to 2.1 later. > >> It's much easier to do all the testing in vanilla because that's > > the only way you can get the javax.faces API stable and mature. And > after that > > is done we can backport it. Maintaining this branch is pure pita and > costs > > enormous amount of time without gaining much benefit right now. This is a > > sandbox feature - it's by far finished yet. So I personally see no need > to > > maintain it twice. Even worse if it's only an almost 1:1 clone. Pure > waste > > of manpower. > >> > >> Let's get this properly done in 2.2.x and if it looks ok port it over > > to 2.1.x > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >> ----- Original Message ----- > >>> From: Mike Kienenberger <mkien...@gmail.com> > >>> To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg > > <strub...@yahoo.de> > >>> Cc: > >>> Sent: Friday, November 16, 2012 1:55 PM > >>> Subject: Re: 2.1-windowId branch > >>> > >>> My understanding is that there was no 2.2 to work in when this branch > >>> was started. > >>> > >>> The idea was to "get it right" in 2.1 in our proprietary > >>> implementation, and then use that to insure that the 2.2 spec worked > >>> in practice as well as in theory. > >>> > >>> On Fri, Nov 16, 2012 at 3:20 AM, Mark Struberg > > <strub...@yahoo.de> wrote: > >>>> I checked the work done in there and Imo this is far from usable. > > Let's > >>> get the windowId right in 2.2 an backport it later. > >>>> > >>>> > >>>> It doesn't make any sense to have 2 branches to do try & > > error in > >>> this area. To stress your butterfly analogy: there is a difference > > between a > >>> cocoon and a hydra ;) > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>> > > > -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
