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: [PORTAL] Changes and API review?
Date Thu, 21 Dec 2006 18:12:08 GMT
Scott,

OK, well, I just went ahead and implemented what I was trying
to say, to see if I'd run into the problems you're describing.  I didn't...
(It's possible I've broken something in portlet land - I only tested
the changes in a servlet environment.)

On 12/21/06, Scott O'Bryan <darkarena@gmail.com> wrote:
> Adding getInstance() to the configurator will either force us to cast in
> a bunch of different places

No, it doesn't.  No casts were required at all, much
less in a bunch of places, and most of the code now
doesn't even have references to the impl class at all.

> or to expose the GlobalConfiguratorImpl's
> api to the rest of the world (which I don't want to do because they are
> applicable ONLY to global configurator.  And it won't lock us into an
> API we may have to expand later.
>
> As for simply putting the Boolean on the request map, either I'll have
> to make a protected constant on the Configurator interface (which has no
> bearing on any of the configurators except the global configurator so it
> shouldn't go into the ancestor) or I add a porotected (isDisabled)
> method (which, again, is only applicable to the GlobalConfiguratorImpl
> and therfore shouldn't do into it's Ancestor).

See the code checked in, which does not suffer these probems.

> I've never been one to include a feature into an interface or a class
> that is applicable in only one instance of that class because it
> violated basics OO design principals.  The only other option I see here
> is to define the constant used to store the boolean in BOTH classes and
> hope they remain in sync, but I've never been a big fan of that either.

Again, see the code checked in.

-- Adam

Mime
View raw message