incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Re: [PORTAL] Changes and API review?
Date Fri, 15 Dec 2006 23:09:41 GMT
On 12/15/06, Scott O'Bryan <darkarena@gmail.com> 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

Mime
View raw message