Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42822782.4030907@marathon-man.com>
Date: Wed, 11 May 2005 08:40:50 -0700
From: Grant Smith <grants@marathon-man.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322)
MIME-Version: 1.0
To: MyFaces Development <dev@myfaces.apache.org>
Subject: Re: Vote for new displayValueOnly attribute
References: 
 <BA7F50A400AF53449809C74ECDB4A79B01147698@vtg-um-e2k4.sj21ad.cisco.com>
In-Reply-To: 
 <BA7F50A400AF53449809C74ECDB4A79B01147698@vtg-um-e2k4.sj21ad.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1 on the Sylvain/Martin approach.

Korhonen, Kalle wrote:

>     ------------------------------------------------------------------------
>     *From:* Sylvain Vieujot [mailto:svieujot@apache.org]
>     *Subject:* Re: Vote for new displayValueOnly attribute
>     Sean & Kalle,
>     I agree that this discussion helped to clarify some things, but
>     I'm a quite worried by the time and efforts it takes to agree on
>     such a small feature.
>     I don't underestimate the necessity of having a well thought API,
>     but as all of you, my time is spare, and I disagree that there is
>     no harm in a prolonged discussion.
>     If it's just too much effort to decide such issues, I should
>     better do a hack on my own, and forget about including it in Myfaces.
>
> Well, this is typical open-source development with all its pros and 
> cons. If you need something for your own use, by all means, implement 
> it before you even ask whether anybody else is interested in it or 
> not. You definitely can forget about including in MyFaces if you feel 
> like it; but it's not like you are only doing a favor for somebody 
> else by contributing your code. You are also doing a favor to yourself 
> by including your contribution. You'll enjoy the benefits of lots of 
> other people verifying your code, maintaining it and improving the 
> codebase without you needing to worry about merging back to your 
> customized version of the whole. Writing code that is generic enough 
> that it works for everybody and still does something useful is hard, 
> and it is for this reason that people will and should discuss every 
> frustrating little aspect of code before reaching the single best 
> solution. Sometimes, the solution cannot be reached, at least for the 
> moment, like with tree vs. tree2, so it's better to leave alternative 
> solutions to the same problem until a better solution is reached.
>  
> We've been using MyFaces for over a year here now updating libs we use 
> every now and then, usually when forced to. Sometimes using the 
> "official" build version, often the snapshots compiled from head, and 
> sometimes with a modified version (like now until patch for UTF-8 is 
> hopefully committed). It's just open source business as usual; 
> discussing the implementation aspects shouldn't slow down its usage 
> and development.
>  
> Just my 2 cents,
> Kalle
>  
>
>     Please don't take this as an offense, it's just a general worry
>     that this would afraid others like me of contributing anything
>     else than bug fixes.
>     I also dislike this voting process, but it is an attempt to keep
>     this in a reasonable time frame, so please try to make your mind,
>     but don't ask for another week of emails & extensive explanations. 
>
> .. and no offense taken.
>
>      As for the summary of the options, I agree with the one Martin
>     just did (thanks for your help by the way).
>
>     Sylvain.
>
>     On Tue, 2005-05-10 at 15:26 -0400, Sean Schofield wrote:
>
>>> While discussing this has taken a long time, I don't see any wrong in
>>> it. It's still cheap and easy compared to implementing different
>>> components, then comparing their implementations, fixing possible bugs
>>> etc.
>>
>>I agree with Kalle that there is no harm in a prolonged discussion on
>>this.  If memory serves me, we have only been discussing this for a
>>week or so.  I think we should consider postponing the vote and taking
>>a little more time with this.
>>
>>My reasoning is that this solves a problem that many of us (including
>>myself) need to have solved.  Lets pick an approach that we can all
>>live with.
>>
>>On the other hand, we owe it to Sylvain to not drag this out.  Lets
>>try to resolve this quickly but also give it the consideration it
>>deserves.  Also, the answer to this problem involves several "design
>>principles" that we should probably agree upon.  For instance, concern
>>over bloated attributes, mutating components, etc.
>> 
>>I need some time to re-read this very extensive thread.  Maybe Sylvain
>>or Kalle can summarize the options for us (Option #1, #2, etc.) 
>>People can add new options (give them a new number) and we can have a
>>quick discussion and reference these options by # and discuss pros and
>>cons.
>>
>>> Kalle
>>
>>sean
>>      
>>