As someone who has experience in attempting to use Trinidad, I think #3 is a requirement for short term usage and #2 as the goal.
What I mean by this is that rendereds should make an effort to expose functionality even if it isn't thought through so that ppl can get work done, and then have users ask for the equivalent functionality to be promoted to the API in a later release. If people do not mind being broken by new releases, why should we try to prevent them from being able to do what they need to do to be able to write their products? Saying #2 only is a sure way to stop the myfaces community from using Trinidad. On 4/11/08, Andy Schwartz <[EMAIL PROTECTED]> wrote: > Hey Martin (and all) - > > It seems to me that what this comes down to is how we view classes in > trinidadinternal. There are a range of possible views here: > > 1. These classes are entirely private/off-limits, and if you want to > extend one of these tough luck. No love for you. Go away. > 2. These classes are entirely private/off-limits, however, if there is > functionality here that our users legitimately need to extend, then we > should try to facilitate that by promoting the functionality in > question over to the public API (trinidadapi package), accepting the > burden that this is, now, from here on out, part of our public API. > 3. Hey, well, we all know that these classes are off-limits in spirit, > but guess what, people are going to extend them, not for malicious > purposes but because they are trying to solve a real problem. While > moving functionality to the public API is the "correct" solution, we > also recognize that this requires significantly more effort, and > requires us to sacrifice future flexibility. Instead of paying this > price, we prefer live with the fact that, yes, some small set of users > might extend these, and that we might even need to make some tweaks in > order to facilitate that, though we aren't willing to claim that these > APIs are officially supported, and we make no guarantee that we won't > break things in a future release. > 4. The APIs in trinidadinternal should be part of our public API, > officially supported, guaranteed not to change. > > I don't think that anyone is lobbying for #1 or #4. I think that > Scott is in favor of #2. Note that this doesn't mean no love for > Christi and the problems that he is trying to solve. Just that > Scott's preferred way to solve these problems is by defining public > APIs rather than have people depend on unofficial/unsupported/internal > APIs. > > It sounds like several people are in favor of #3. > > I am somewhere on the fence between #2 and #3. I think that #2 is the > correct thing to do, but I also believe that this is a significant > burden, so I am tempted by #3 as a way to ease some of the > frustration. > > Before we discuss questions like whether we should be breaking out > renderers into smaller sub-renderers, or whether particular methods > should be final/private/protected/whatever, I think we need to agree > as a community what our stance is on on the question of how we view > trinidadinternal. > > Andy >
