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"));
}
}
2.
override public function commitProperties():void
{
super.commitProperties();
if (titleBarRendererChanged)
{
commitTitleBarRenderer();
titleBarRendererChanged = false;
}
}
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).
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.
Mike
On Thu, Oct 30, 2008 at 11:44 AM, Amy <[EMAIL PROTECTED]> wrote:
> --- In [email protected] <flexcoders%40yahoogroups.com>,
> "Michael Schmalle"
> <[EMAIL PROTECTED]> wrote:
> >
> > Clarification;
> > > Children can be created at any time AFTER super().
> >
> > Since we all design software with a design, any property committal
> in a
> > super() call has nothing to do with an instance of a child you
> create in the
> > subclass (this is bad design). Thus, the above logic holds true.
>
> But someone subclassing your Class may not have the same
> understanding of your design that you do, and it is quite common for
> developers to try to set properties on child objects in
> commitProperties. I've even been advised to do so in this forum by
> people I respect. Maybe in retrospect it was a bad idea to take such
> advice, but new developers are going to continue getting such advice
> and taking it.
>
> So it very much matters where you create children when _other people_
> are going to be subclassing your work.
>
> -Amy
> -Amy
>
>
>
--
Teoti Graphix, LLC
http://www.teotigraphix.com
Teoti Graphix Blog
http://www.blog.teotigraphix.com
You can find more by solving the problem then by 'asking the question'.
