incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <darkar...@gmail.com>
Subject Re: [PORTAL] Changes and API review?
Date Fri, 15 Dec 2006 21:12:33 GMT
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


Mime
View raw message