--- In [email protected], "Michael Schmalle"
<[EMAIL PROTECTED]> wrote:
>
> Amy,
> I have read all that you have written. 2 years of sales, no
complaints on
> the algorithm I use.
>
> > So it very much matters where you create children when _other
people_ are
> going to be subclassing your work.
>
> I have created a sub template in commitProperties(); That can
> be overridden from any subclass since it separates operations into
hooks.
>
> 1.
>
> public function set titleBarRenderer(value:IFactory):void
> {
> if (_titleBarRenderer != value)
> {
> _titleBarRenderer = value;
> titleBarRendererChanged = true;
> invalidateProperties();
> dispatchEvent(new Event("titleBarRendererChanged"));
> }
> }
This is working with a child that may change over time. So right
there, this is something that needs _more_ than createChildren().
However, I think in most places where this kind of behavior is needed
in the Framework code, a default version of the child is created in
createChildren() so it is available for subclasses to work with in
commitProperties(). There's an implicit assumption on the part of
most developers that all components have been created before
commitProperties() is called, and by not having a child available the
_first_ time commitProperties runs, you may have a developer doing
what he thinks is right and stumbling over your logic.
> 2.
>
> override public function commitProperties():void
> {
> super.commitProperties();
>
> if (titleBarRendererChanged)
> {
> commitTitleBarRenderer();
> titleBarRendererChanged = false;
> }
> }
And all you need to break this is some developer overriding your code
like this:
override public function commitProperties():void
{
if (_styleChanged) {
_titleBar.setStyle('color', 0xFFFFFF);
}
super.commitProperties();
}
> 3.
>
> protected function commitTitleBarRenderer():void
> {
> createTitleBar();
> }
>
> 4.
>
> protected function createTitleBar():void
> {
> _titleBar = PartFactory.createComponentPart(
> TITLE_BAR_NAME, this, rawChildren,
> DisplayObject(_titleBar));
> }
>
> 5.
>
> tk_internal function partAdded(name:String, instance:Object):void
> {
> if (instance == _titleBar )
> {
> .... configuration
> }
> }
>
> As far as not releasing code, this next iteration of products will
have
> source code, but the template is still the same.
>
> I hear you on the "I listen to respected developers on this list"
but, this
> way works even better than how the framework is set up (for
subclassing).
...yeah. ;-)
> Adds more method calls but, it's impact is irrelevant since these
calls are
> not 100 every minute. I also use this template for other properties
that are
> not processor intensive or called to frequently.
So far, you've been lucky. Either the developers who use your
components are familiar enough with the right way that they haven't
broken anything, or they're too new to be messing where they
shouldn't. All you need is one intermediate developer charging
through the middle of your code, and you'll have a problem.
And, to get back to the OP, it's clear he was looking for guidance in
best practices. You and I may disagree on when it's ok to bend or
break the rules, but when someone _doesn't_ know the rules, it's
probably better not to jump him to the bending/breaking stage.
-Amy
