On 12/15/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
Adam Winer wrote:
>> Therefore if these or other things arise, having an API for a global
>> cofigurator will be more flexible in the future because we'll be able to
>> add to this API would breaking binary compatibility. If we start
>> returning normal Configurators form these API's it will force us to
>> "cast" the object or add the methods to the base configurator object.
>> In short, I think there are (or could be) sufficient difference between
>> the GlobalConfigurator and the normal Configurator to justify the extra
>> class even though the API's are not currently present.
>
> I don't see why our "global" configurator will have to
> comply with this API. It's our own thing. We don't
> need to comply or not comply with any external API.
>
> So, nope, please kill it.
Adam. Because other configurators may have to use it. That's what I'm
saying. If other renderkits or renderkit extensions are build of
Trinidad, we want them to be able to be able to access any utilities
provided by this class. I'm not worried about the internal
implementations as much as I'm worried about supporting this API going
forward given the current unknowns. And frankly, I'm not sure why "at
the moment" one extra method in one extra class is worth locking us into
a pre-existing implementation that isn't sufficient to run inside of a
portal that well.
You MAY be 100% correct that no extensions will have to be made to this
object in the future, but you could also be wrong. All I'm asking is
for us to remain flexible. And at such a small cost, I don't think it's
a huge issue.
>
> NONE of it should be public unless it is 100%, no two ways
> about it, absolutely required.
ok
> Then set a request attribute, whatever, to turn off our wrappers.
> Any behind-the-scenes fiddling is WAAAY better than all of
> this extra code.
Well it still doesn't eliminate the problems we're going to have with
anyone else's stuff, and I think that's a real tradegy. But I'll pull
the code out.
I don't know what problems those'll be, other than hypothetically
that maybe there might be perhaps. In which case, we could
certainly look at that *at that point*. Adding lots of extra
public code on the theory that it *might* be necessary down the
road is not a good tradeoff.
So I guess basically I'm making one last appeal on the
GlobalConfigurator thing. If you still want it removed I'll get rid of
it. But I honestly think we're backing ourselves into an unnecessary
corner. I'll give in on everything else and make a new patch for the
jwaldman portal branch.
I just don't get how we're getting extra flexibility. Can you give
me a hypothetical scenario where having a different "global"
configurator class (rather than just an instance) proves a big
win? I don't see it yet. As best as I can see, my proposal
still allows full access to the global instance to external
developers. It just doesn't require a bonus class to do that.
-- Adam
