+1 on the Sylvain/Martin approach.
Korhonen, Kalle wrote:
------------------------------------------------------------------------ *From:* Sylvain Vieujot [mailto:[EMAIL PROTECTED] *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
