On 9/3/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > Guess I didn't leave adequate time. I took the lack of response in a > days time to be no negative opinion. I can always move them back out > and put them into jsf-comp as I know people will make use of them.
That'd be great, thanks. > Let > me know of any procedures that are in place for any new component > ideas. For starters, it's Labor Day weekend... For finishers, no comment is in fact a really good argument for *not* putting it in. If the idea seems good, people will pipe in with "+1, sounds good". Broadly speaking, Trinidad is rather conservative w/regard to adding new components. This is a *good thing*. Saying "no" is one of the most important things that any open-source project can do to keep its focus. This is particularly important for a project like Trinidad where we make every possible effort to avoid any backwards-incompatible API changes going forward. That said, for component contributions we should: - Look for alternative implementations - can this be done some other way? - Review the name of the component and name of any new attributes - Make sure the community agrees it's generally useful Lack of consensus (much less lack of any comments) means "don't put it in (yet)". BTW, this also goes for new public APIs: adding an API to RequestContext with no public discussion isn't a great thing either. > In the meantime, if you don't like them, I'd like to hear the > opposition and the alternatives. I have yet to hear any suggestions > for an adequate solution for supporting PPR re-rendering on command > clicks that produce conversion and validation errors. As always, I am > willing to hear alternatives. I've given you an alternative more than once! For starters, the idea that end users should need to add any component at all, or set a single attribute at all, just to get their server-side messages to show up is not good. The fact that they don't show up correctly today is *a bug*, and one that should get fixed. > Supporting only client-side messages updates is not sufficient though > to capture use cases that users will need. Message components cannot > be assumed to be the only components that want to react to conversion > and validation errors. That statement needs justification; and, if we fix server-side messages, then it is certainly the case that the benefit of these new components appears to be greatly reduced. -- Adam > > On 9/3/07, Adam Winer <[EMAIL PROTECTED]> wrote: > > I have to admit, I'm not at all convinced that either of these two > > new components should be added, and think there should have > > been more discussion before you'd checked them in. If we're > > going to have components added without general agreement, we > > need a sandbox where they can be tried out and played with. > > > > -- Adam > > > > > > On 8/30/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: > > > 2 questions for the Trinidad developers: > > > > > > (1) It seems like Trinidad is using some kind of generator for taglib, > > > tld, Tag, and possibly other classes. Is this documented anywhere? I > > > was looking around the SVN trunk and did not see any boilerplate or > > > configuration code that would provide such information to a maven > > > plugin. Can someone point me to the location in SVN that I can start > > > poking around to get an understanding of how this works? > > > > > > (2) Are there any comments on the following enhancement "bugs" for new > > > components? > > > > > > https://issues.apache.org/jira/browse/TRINIDAD-663 > > > https://issues.apache.org/jira/browse/TRINIDAD-664 > > > > > > If not would there be any objections to me checking in the code into > > > the Trinidad trunk (once I figure out the answer to #1 of course)? > > > > > > Thanks, > > > Andrew > > > > > >
