Skip to main content
A
Anonymous
March 20, 2009
Question

skinState vs. component state

  • March 20, 2009
  • 7 replies
  • 2185 views
I wrote some Gumbo prototypes recently and found it confusing that skinStates are independent of component states (currentState). I tried to imagine scenario when host component state should be different than its skin state but I cant find any.

I have found that component states are used in item renderes, which in my opinion violates of skinning concept (see ARB http://opensource.adobe.com/wiki/display/flexsdk/Gumbo+Updated+Item+Renderer )

What do you think about syncing surrentState with skinState?

In such a case it would be easier for developer to migrate from MXML inline item renderer to fully skinnable one as states of both, inline MXML component and MXML skin, will be the same.
This topic has been closed for replies.

7 replies

A
Anonymous
March 24, 2009






On 3/24/09 7:19 AM, "Tom Chiverton" < member@adobeforums.com> wrote:



> Tsk, Fx:Application :-)



Yeah, well, I was going to say Application, but then it would be ambiguous, wouldn’t it?   It’s going to be fun keeping things clear !!!



E.



F
Fletchgqc
Participating Frequently
September 16, 2010

The unmentioned difference between the two types of state is very confusing for a new Flex developer (i.e. me). All the doco about Flex 4 states and skinning talks about skin states, but never about view states. No-one even specifically points out "hey, watch out, there are two different concepts here with basically the same name!". It took me two days to figure out they were different and therefore understand why things weren't working.

This major gap in the Adobe tutorials definitely needs fixing. Thankfully there are a few guys like this clarifying things: http://saturnboy.com/2009/09/flex4-component-states-skin-states/.

I must say that syncing the two types of state is exactly the first thing I'm going to do, and the original posters thoughts definitely seem correct initially. But I don't have the experience to be able to say that this should be set in concrete.

matt_chotin
matt_chotin
Inspiring
March 24, 2009
You write your state implementations the same way.  SkinStates is just a formal mechanism for saying that your skin should support those states.   But since your skin is just like an MXML component, what you end up writing is the same. For your application components you’re simply declaring them to meet “business” rules, while in skins you’re doing it more for interaction rules.



Matt





On 3/24/09 7:37 AM, "Haykel Ben Jemia" < member@adobeforums.com> wrote:



A new message was posted by Haykel Ben Jemia in



Developers --

  skinState vs. component state



I have used skin states and thought it was the new way of using states. I was not aware that the 'old' component states are still available and can be used. Some examples on using both would probably help understand how both state types can be used together. I'll see if I can find some interesting use cases.



Haykel Ben Jemia



Allmas

Web & RIA Development

http://www.allmas-tn.com









On Mon, Mar 23, 2009 at 5:20 PM, Greenfield Eliot < member@adobeforums.com> wrote:

A new message was posted by Greenfield Eliot in



Developers --

  skinState vs. component state







We had them coupled originally. Surprisingly, if you’ve written a Spark app, you’ve already run into this.  Any time you use a skinned spark component as the root tag of your MXML file (including FxApplication), and add your own states, you’re creating component states that are separate from any skin states.



Ely.

 





On 3/23/09 3:50 AM, "Tom Chiverton" < member@adobeforums.com < http://member@adobeforums.com> > wrote:



A new message was posted by Tom Chiverton in



Developers --

  skinState vs. component state



 On Friday 20 Mar 2009, Iwo Banas wrote:

> What do you think about syncing surrentState with skinState?



I'm trying to think of use cases where the internal state of the component may

be detached from the showing of that state, and I've come up with one:

Suppose a component has two skin states - OK and FAIL, and it has to call an

external service to check something to computer the state (i.e. state

transitions are asynchronous). There might be OK, UNKNOWN and FAIL states,

but only two skins (UNKNOWN being the same as FAIL).





View/reply at skinState vs. component state < http://www.adobeforums.com/webx?13@@.59b85be2/1>

Replies by email are OK.

Use the unsubscribe < http://www.adobeforums.com/webx?280@@.59b85be2%21folder=.3c060fa3>  form to cancel your email subscription.









View/reply at skinState vs. component state < http://www.adobeforums.com/webx?13@@.59b85be2/4>

Replies by email are OK.

Use the unsubscribe < http://www.adobeforums.com/webx?280@@.59b85be2!folder=.3c060fa3>  form to cancel your email subscription.





_
_Haykel_Ben_Jemia_
Known Participant
March 24, 2009
I have used skin states and thought it was the new way of using states. I was not aware that the 'old' component states are still available and can be used. Some examples on using both would probably help understand how both state types can be used together. I'll see if I can find some interesting use cases.


Haykel Ben Jemia

Allmas
Web & RIA Development
http://www.allmas-tn.com





On Mon, Mar 23, 2009 at 5:20 PM, Greenfield Eliot < member@adobeforums.com> wrote:

A new message was posted by Greenfield Eliot in



Developers --

  skinState vs. component state








We had them coupled originally. Surprisingly, if youâve written a Spark app, youâve already run into this.  Any time you use a skinned spark component as the root tag of your MXML file (including FxApplication), and add your own states, youâre creating component states that are separate from any skin states.




Ely.


 





On 3/23/09 3:50 AM, "Tom Chiverton" < member@adobeforums.com> wrote:



A new message was posted by Tom Chiverton in



Developers --

  skinState vs. component state



 On Friday 20 Mar 2009, Iwo Banas wrote:

> What do you think about syncing surrentState with skinState?



I'm trying to think of use cases where the internal state of the component may

be detached from the showing of that state, and I've come up with one:

Suppose a component has two skin states - OK and FAIL, and it has to call an

external service to check something to computer the state (i.e. state

transitions are asynchronous). There might be OK, UNKNOWN and FAIL states,

but only two skins (UNKNOWN being the same as FAIL).







View/reply at skinState vs. component state

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.



C
ChivertonT
Inspiring
March 24, 2009
On Monday 23 Mar 2009, Greenfield Eliot wrote:

> component as the root tag of your MXML file (including FxApplication), and



Tsk, Fx:Application :-)



> add your own states, youre creating component states that are separate

> from any skin states.



I've never used states, first to admit.



--

Tom Chiverton

Helping to efficiently benchmark B2C bricks-and-clicks supply-chains as part

of the IT team of the year, '09 and '08



****************************************************



This email is sent for and on behalf of Halliwells LLP.



Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office together with a list of those non members who are referred to as partners. We use the word partner to refer to a member of the LLP, or an employee or consultant with equivalent standing and qualifications. Regulated by the Solicitors Regulation Authority.



CONFIDENTIALITY



This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500.



For more information about Halliwells LLP visit www.halliwells.com.




C
ChivertonT
Inspiring
March 24, 2009
On Monday 23 Mar 2009, Greenfield Eliot wrote:

> component as the root tag of your MXML file (including FxApplication), and



Tsk, Fx:Application :-)



> add your own states, youre creating component states that are separate

> from any skin states.



I've never used states, first to admit.



--

Tom Chiverton

Helping to efficiently benchmark B2C bricks-and-clicks supply-chains as part

of the IT team of the year, '09 and '08



****************************************************



This email is sent for and on behalf of Halliwells LLP.



Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office together with a list of those non members who are referred to as partners. We use the word partner to refer to a member of the LLP, or an employee or consultant with equivalent standing and qualifications. Regulated by the Solicitors Regulation Authority.



CONFIDENTIALITY



This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500.



For more information about Halliwells LLP visit www.halliwells.com.




A
Anonymous
March 23, 2009




We had them coupled originally. Surprisingly, if you’ve written a Spark app, you’ve already run into this.  Any time you use a skinned spark component as the root tag of your MXML file (including FxApplication), and add your own states, you’re creating component states that are separate from any skin states.



Ely.

 





On 3/23/09 3:50 AM, "Tom Chiverton" < member@adobeforums.com> wrote:



A new message was posted by Tom Chiverton in



Developers --

  skinState vs. component state



 On Friday 20 Mar 2009, Iwo Banas wrote:

> What do you think about syncing surrentState with skinState?



I'm trying to think of use cases where the internal state of the component may

be detached from the showing of that state, and I've come up with one:

Suppose a component has two skin states - OK and FAIL, and it has to call an

external service to check something to computer the state (i.e. state

transitions are asynchronous). There might be OK, UNKNOWN and FAIL states,

but only two skins (UNKNOWN being the same as FAIL).

C
ChivertonT
Inspiring
March 23, 2009
On Friday 20 Mar 2009, Iwo Banas wrote:

> What do you think about syncing surrentState with skinState?



I'm trying to think of use cases where the internal state of the component may

be detached from the showing of that state, and I've come up with one:

Suppose a component has two skin states - OK and FAIL, and it has to call an

external service to check something to computer the state (i.e. state

transitions are asynchronous). There might be OK, UNKNOWN and FAIL states,

but only two skins (UNKNOWN being the same as FAIL).



--

Tom Chiverton

Helping to proactively revolutionize interactive enterprise content as part of

the IT team of the year, '09 and '08



****************************************************



This email is sent for and on behalf of Halliwells LLP.



Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office together with a list of those non members who are referred to as partners. We use the word partner to refer to a member of the LLP, or an employee or consultant with equivalent standing and qualifications. Regulated by the Solicitors Regulation Authority.



CONFIDENTIALITY



This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500.



For more information about Halliwells LLP visit www.halliwells.com.




Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices