From: Sylvain Vieujot [mailto:[EMAIL PROTECTED]
Subject: Re: Vote for new displayValueOnly attributeSean & 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
