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.
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.
Scott
