> When components you are creating, framework you will want to use, no?

I don't know if I understand exactly what you are asking but, if it is "When I create components that are .as files and subclass a framework class, do I want to use the Template Method Pattern of the flex framework?"

The answer would be yes of course.

I would put it this way.

If you are developing a car and you are an engineer, you would use the schematics of the car design, the way the car was engineered to run to add a specific add in subsystem in the internal workings of the car.

Now, If I was an outside company that created addd-ons for that car, I would use the 'macro' schematic verses the micro of the actual car engineering.

The thought is, the tighter you integrate your design into the frame of the target, the tighter your component becomes and actually becomes PART of the car not an addon.

If I was creating an mxml component, I would tend you use events more because in my view, an mxml component is an addon not an inherent subsystem of the framework.

I don't advocate creating anything in mxml that needs to be subclassed in the future because although it gets rendered into an as3 class, it is not extensible like an as3 class file because the development pattern differs in respect to creating a subsystem of the actual framework.

Anyway, rambling aside, events belong to clients. The framework belongs to subsystems of that framework. If you have a composite component(client of the component) inside your subclassed as file, by all means use events. Just don't use events in a component to talk to itself.

Performance wise, this pattern will always beat events.

Peace, Mike

On 8/23/06, tddclare <[EMAIL PROTECTED] > wrote:

perfect. the cache of the old values seems to be the right way. it's actually how Im
handling many of my other internal properties, since they can ASK for a property to be set
to a value, but it may or may not be in the allowable range (specific to my component).
Don't know why I didn't think of that.

When components you are creating, framework you will want to use, no?



--- In flexcoders@yahoogroups.com, "Michael Schmalle" <[EMAIL PROTECTED]> wrote:
>
> opps, missed one;
>
> 5a) myComponent.commitProperties()
>
> 5b) myComponent.measure()
>
> Peace, Mike
>
>
> On 8/23/06, Michael Schmalle <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > There is a RESIZE event but...
> >
> > If you are actually creating a custom component, I wouldn't recommend
> > attaching events that actually are going to effect your updateDisplayList()
> > and commitProperties().
> >
> > Ok, If a client calls width or height, you are going to get an
> > invalidateProperties(), invalidateSize() and invalidateDisplayList().
> >
> >
> >
> > Lets see, the sequence would be...
> >
> > 1) myComponent.width = 350;
> >
> > 2) myComponent.invalidateSize()
> >
> > 3) myComponent.invalidateProperties()
> >
> > 4) myComponent.invalidateDisplayList()
> >
> > 5) myComponent.commitProperties()
> >
> > 6) myComponent.updateDisplayList()
> >
> > You will get this always.
> >
> > The trick would be to check your cached properties in commitProperties(),
> > then if they have changed, switch a flag that says(as aggregated as you
> > want)
> >
> > var baseCalc:int = blah;
> >
> > if (baseCalc != cachedBaseCalc)
> > {
> > cachedBaseCalc = baseCalc;
> > rightBoxInvalidateFlag = true
> > }
> >
> > Then...
> >
> > In you call that happens next in the updateDisplayList() you now have a
> > fine grained access point to only update the calcs that have changed.
> >
> > IE updateDisplayList()
> >
> > If(rightBoxInvalidateFlag)
> > {
> > //redraw only right box since it's metrics changed
> > rightBoxInvalidateFlag = false;
> > }
> >
> > I hope that helps and doesn't confuse. hehe I develop some pretty big
> > components and using events IN your component, well my opinion is nah don't
> > do it.
> >
> > Use the framework Luke. ;-)
> >
> > Peace, Mike
> >
> >
> >
> >
> >
> >
> >
> >
> > On 8/23/06, tddclare <[EMAIL PROTECTED] > wrote:
> > >
> > > I'm creating a custom component extending UIComponent.
> > >
> > > Much of the component is drawn by the Drawing API during the
> > > updateDisplayList using
> > > settings calculated during the commitProperties. Works great.
> > >
> > > The problem arises when the end developer USING the component changes
> > > the size of it
> > > manually (example: the height and width are 150, and they create a
> > > button whose click
> > > changes the component's width to 300).
> > >
> > > My commitProps and updateDispList are VERY conditional - only redrawing
> > > the elements that
> > > NEED to be redraws to increase performance.
> > >
> > > What I can't find / missed is how to know the component itself resized
> > > and to set a flag that
> > > will tell my commitProps and updateDispList to redraw everything. What
> > > is that event / how
> > > do I tell they resized me?
> > >
> > > Thanks!
> > >
> > > -- TC
> > >
> > >
> > >
> >
> >
> >
> > --

> > What goes up, does come down.
> >
>
>
>
> --
> What goes up, does come down.
>




--
What goes up, does come down. __._,_.___

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com





SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to