myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: 2.1-windowId branch
Date Fri, 16 Nov 2012 15:40:30 GMT
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 <struberg@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 <mkienenb@gmail.com>
>> To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg <struberg@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 <struberg@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
>>>
>>

Mime
View raw message