OK now I see the states generated code. I've seen this before. Right, it's
creating a new SetStyle instance. It's creating that at the document level.
I hear your points and they are valid. I think we could work around it.
I'm not saying there won't be conflicts but there are conflicts now with
CSS when you declare and set a style twice. In that case it's handled by
specificity. When creating transitions there is plenty of room for errors
as well.
But I think it will be OK to modify setStyle(). With the setStyle() API it
only accepts two arguments. We could add two more optional arguments and
that would not cause any backwards compatibility issues since they will
continue to work the same.
OLD:
public function setStyle(styleProp:String, newValue:*):void
{
// If there is no module factory then defer the set
// style until a module factory is set.
if (moduleFactory)
{
StyleProtoChain.setStyle(this, styleProp, newValue);
}
else
{
if (!deferredSetStyles)
deferredSetStyles = {};
deferredSetStyles[styleProp] = newValue;
}
}
NEW:
public function setStyle(styleProp:String, newValue:*, state:* = null,
documentState:Boolean = true):void
{
// If state is set then do new stuff
if (state)
{
// do new stuff here - Alex writes this part
}
else { // do previous stuff
// If there is no module factory then defer the set
// style until a module factory is set.
if (moduleFactory)
{
StyleProtoChain.setStyle(this, styleProp, newValue);
}
else
{
if (!deferredSetStyles)
deferredSetStyles = {};
deferredSetStyles[styleProp] = newValue;
}
}
}
The part where it says do new stuff here we could dynamically create the
mx.states.setStyle action and add it to the overrides. Or we dynamically
create the new CSSCondition("pseudo", "up"); and create a new selector.
There would be the possibly for the same property or style to be assigned
twice as you mentioned. We could create a warning, throw an error at
runtime or just let the last one in win.
On Tue, Mar 10, 2015 at 11:19 AM, Alex Harui <aha...@adobe.com> wrote:
> Hi Judah,
>
> I think your example from a few posts ago didn’t actually have a
> state-dependent attribute. Maybe try something like this:
>
> <s:states>
> <s:State name=“jude” />
> </s:states>
> <controls:ImageButton id="myButton" label="a long label test"
> icon.jude="assets/lagoon.jpg" />
>
>
> I think there might be too many backward-compatibility risks with changing
> the API signature of setStyle. The compiler could certainly generate a
> call to another API though, but I think if you look at the generated code
> for a state-dependent attribute you’ll see that the compiler doesn’t
> generate call to setStyle but actually uses a States class like
> mx.states.SetStyle.
>
> -Alex
>
> On 3/10/15, 10:48 AM, "jude" <flexcapaci...@gmail.com> wrote:
>
> >The TL;DR was what if we treat inline pseudo states MXML like it is an
> >inline style or like we treat CSS pseudo style declarations? When we
> >encounter an attribute formatted like so, icon#up="myUpIcon.png" we,
> >meaning the compiler, write out:
> >
> >temp.setStyle("icon", "myUpIcon.png", "up", true); // create a css pseudo
> >condition for the "up" state
> >
> >Normally if we encounter a style inline we write out:
> >
> >temp.setStyle("icon", "myUpIcon.png"); // generated by the compiler for
> >the
> >inline style. see the previous email
> >
> >We would have to add support by adding additional parameters to setStyles
> >for different states in the setStyle method at the very least.
> >
> >Basically, <s:Button id="myButton" icon#up="myUpIcon.png" /> would be the
> >same as writing this:
> >
> >s|Button#myButton:up {
> > icon:"myUpIcon.png"
> >}
> >
> >which is the same as or similar to:
> >
> >condition = new CSSCondition("pseudo", "up");
> >style =
> >styleManager.getStyleDeclaration("com.flexcapacitor.controls.ImageButton:u
> >p");
> >style.factory = function():void
> >{
> > this.icon = "myUpIcon.png";
> >};
> >
> >But we create that code above specifically for that button instance at
> >runtime when setStyle("icon", "myUpIcon.png", "up", true) is called. We
> >might even be able to get rid of some generated style declarations if we
> >can use setStyle() to create the CSSConditions.
> >
> >@Kessler - I didn't notice that method before. I'll check it out.
> >
> >@Alex - I'll look at the states generated code again too. There might be
> >collisions with the states generated code.
> >
> >you wrote,
> >"I think you missed some of the generated code for the state-dependent
> >properties and styles. Take a look at how the assignment for a
> >state-dependent style attribute look"
> >
> >I'm looking at the generated files and I don't see anything. What MXML
> >would generate this or what files should I be looking for? In my last
> >message I copied in the generated code for an MXML declared Spark Button
> >and the generated code for a CSS declaration for a pseudo state. Both of
> >the codes appeared in the generated application file,
> >PseudoStatesExample-generated.as. Is this the same as what you were
> >referring to? Sorry the original was so long.
> >
> >
> >On Tue, Mar 10, 2015 at 9:41 AM, Alex Harui <aha...@adobe.com> wrote:
> >
> >> Maybe, but the way the code currently works is that the states are
> >> declared in an MXML document and all state-dependent data is generated
> >>for
> >> that same document. While that state-dependent code does set styles and
> >> properties on other instances declared in that document, some of those
> >> instances are themselves MXML documents for which their state-dependent
> >> code has already been generated, probably when it was compiled into a
> >>SWC.
> >> There’s no way to modify that generated code, so we need a different
> >>way
> >> to determine when a state changes in a child object (yes, there events
> >>for
> >> that) and then make the appropriate changes and figure out how to deal
> >> with potential conflicts and what to do if the child object (or
> >>actually,
> >> its skin) doesn’t support the state you think it does.
> >>
> >> -Alex
> >>
> >> On 3/10/15, 4:53 AM, "Kessler CTR Mark J" <mark.kessler....@usmc.mil>
> >> wrote:
> >>
> >> >Is this something that could be accomplished by overriding the
> >> >stateChanged[1] protected method since it's used for setting styles
> >>when
> >> >the state changes?
> >> >
> >> >[1]
> >> >
> >>
> >>
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/cor
> >>e
> >> >/UIComponent.html#stateChanged()
> >> >
> >> >
> >> >-Mark
> >>
> >>
>
>
