Thanks Alex, that was partially my initial approach, I'm going to try to
expose it as a style so I could define it using CSS so people wouldn't need
to re-implement all the skins. As stated before, my goal is to preserve the
current behavior as the default one.
On 18 July 2014 06:14, Alex Harui
Yes, this is why FlexxJS has beads. Even simple things like
enable/disable can have different implementations.
I took a quick look at SkinnableComponent. It looks like it might be
possible for the skin to detect the state change and override the
mouseEnabled/mouseChildren change then implement s
On 17 July 2014 12:48, Tom Chiverton wrote:
> On 17/07/14 12:43, DarkStone wrote:
> > But after all, this is just my own opinion, others may disagree with me.
> I don't see any other way to achieve changes in behaviour in a base
> class extended by some many other ones ?
>
> I suppose I'd just ha
Hi,
>Isn't this what happens to every single inherited behavior? Aren't
>components created with this in mind? To provide multiple options on
>case-by-case scenario?
Well, the enabled setter is a functionality, the default behavior of this
functionality should be suit for common use case not ed
On 17 July 2014 12:43, DarkStone wrote:
> Hi
>
> >I repeat, my plan is to keep the current behavior as the default, only if
> >you enable the new functionality trough a flag/style/whatever...
> Ok, I got your idea. Adding through a flag/style/whatever is doable, but
> from the perspective of the
On 17/07/14 12:43, DarkStone wrote:
> But after all, this is just my own opinion, others may disagree with me.
I don't see any other way to achieve changes in behaviour in a base
class extended by some many other ones ?
I suppose I'd just have an 'enable helper' I could call in my app that
would w
Hi
>I repeat, my plan is to keep the current behavior as the default, only if
>you enable the new functionality trough a flag/style/whatever...
Ok, I got your idea. Adding through a flag/style/whatever is doable, but from
the perspective of the program design, it's not a very good idea.
I mean t
I repeat, my plan is to keep the current behavior as the default, only if
you enable the new functionality trough a flag/style/whatever, the new
behavior will kick in so current projects will behave like they always did.
As I told you previously, subclassing is not an option since I plan to have
al
Sorry but setting mouseChildren and mouseEnabled won't work for their
customSkin since skinnableComponent does check if the component is enabled
and skip the call to super.mouseChildren/mouseEnabled. Subclassing is not
an option in this case because it would require the entire spark components
to b
Sorry but setting mouseChildren and mouseEnabled won't work for their
customSkin since skinnableComponent does check if the component is enabled
and skip the call to super.mouseChildren/mouseEnabled. Subclassing is not
an option in this case because it would require the entire spark components
to b
I believe it made for less processing / runtime overhead. But I agree
there are situations you would still like to be able to use events or at least
a simple toolTip text.
I know a few people that created their own child of say something like a
button. They then override the enabled p
11 matches
Mail list logo
