Flex states in an inherited component : MXML inheriting base properties

2 04 2008

Problem: I have some component that I’ve created and I want to extend it. However, in the subclass, I’d like to use states with MXML.

Version: Flex 3

Issue: Flex tells you that <mx:states> must belong to the base of the component. The nifty little “lowercase property” feature (I’ve dubbed it thusly) that allows you to define some property of a component in MXML terms doesn’t seem to pickup inherited properties.

For example:

say BasePanel.mxml is my generic panel across my Application

<mx:Panel xmlns:mx=”http://www.adobe.com/2006/mxml” width=”400” height=”300>

</mx:Panel>

Then in PanelResults.mxml I will extend this panel, but I want to declare states using MXML

<jjm:BasePanel xmlns:mx=”http://www.adobe.com/2006/mxml” xmlns:jjm=”com.justinjmoses.examples.mxmlproperties.*>

<mx:states>

</mx:states>

</jjm:BasePanel>

This will not compile.

The states property that is inherited from Panel will not be detected using the MXML namespace. This is the same for all properties you want to inherit and define using MXML (like transitions, transform, etc).

SolN: Use the same xml namespace as your base component to load up the property, even though it is inherited.
PanelResults.mxml

<jjm:BasePanel xmlns:mx=”http://www.adobe.com/2006/mxml” xmlns:jjm=”com.justinjmoses.examples.mxmlproperties.*>

<jjm:states>

</jjm:states>

</jjm:BasePanel>

Advertisements

Actions

Information

14 responses

28 08 2008
Marc

Interesting post, however, I was not able to make this work. in PanelResults.xml I get the message “AN unknow item declared at root element…”.

28 08 2008
Justin J. Moses

Marc,

I believe the problem has arisen because you are trying to execute PanelResults.xml as the main application. Is that what’s happened?

PanelResults a component that is a subclass of BaseResults and should be included in another MXML file that has a root Application tag, rather than trying to execute PanelResults directly.

Still having troubles?

29 08 2008
Marc

Hi Justin,

Thanks for replying so promptly.
Yes, I am still having problems and I am not trying to execute PanelResults.
I tried posting the code, but wordpress is discarding my comment.

29 08 2008
Marc

Parent

<ee:Parent xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns:ee=”org.test.*”>

</ee:Parent>

29 08 2008
Marc

Parent.xml:

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Panel xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns:ee=”org.test.*”>
<mx:states>
<mx:State name=”showUsers”/>
<mx:State name=”detail”/>
</mx:states>
</mx:Panel>

29 08 2008
Marc

Application:

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns:ee=”org.test.*”>
<ee:Child>

</ee:Child>

</mx:Application>

the first file is actually child component. (Sorry for flooding comments.)

29 08 2008
Justin J. Moses

Marc,

No worries about the multiple comments. Are you still getting the same error message when you compile your application? “AN unknown item declared at root element…” ?

Also, I doubt it is this, but your Parent.mxml didn’t include an XML header declaration – was that just an accidental omission?

Another thing, are you saving your mxml components in the right folder? Flex by default checks for files in their namespace folders. That is, your Application file would be in the /src folder, but the Parent and Base classes should be in the /src/org/test folder. That’s how Flex knows how to associate your components with the namespaces you’ve assigned to them.

Justin

29 08 2008
Marc


Another thing, are you saving your mxml components in the right folder? Flex by default checks for files in their namespace folders. That is, your Application file would be in the /src folder, but the Parent and Base classes should be in the /src/org/test folder. That’s how Flex knows how to associate your components with the namespaces you’ve assigned to them.

You nailed it! My component mxml files (Parent.mxml and Child.mxml) were not placed in the correct directory.

Thanks Justin

26 01 2011
Geoff

I know this is an old thread, but I’m having a similar problem. The difference for me is that the base class and the subclass both have a state definition. The base state is listening for state changes to do something based on the state, but what it’s getting in the event is state information from the subclass, so it just skips the block of code it should be executing.

It’s as if the base state declaration is overriding the base state definition.

FYI: 3.3SDK, and both classes are coded using the code-behind technique.

Thanks, Geoff

26 01 2011
Justin J. Moses

Hey Geoff, can you reproduce it in a brief example?

(FWIW – Flex 4 is really gonna help you with state management if you can justify the migration)

26 01 2011
Geoff

Unfortunately, Flex 4 is a long way off for this project. 150,000 lines of code is not easily/quickly converted. :-/

Basically, here’s the scenario. All of the main UIs (30 of them) are based on a custom NavigationPane class that has a state where we show a toolbar at the top. One of the ‘concrete’ implementations of NavigationPane also has a state defined.

The NavigationPane class is listening for the StateChangeEvent to make modifications to the toolbar. What I want is for the NavigationPane class to process it’s state change independently from the subclasses state change. However, what I’m seeing is that the StateChangeEvent handler is only picking up change events from the subclass. So when I inspect the event.newState property, it’s showing a value from the subclass, not the base class.

Hope I explained that clearly.

Geoff

27 01 2011
Geoff Bell

I wrote a small test app and it appears that the subclass’s state overrides are overriding the super class’s state overrides. I guess the better way to attack this scenario is to use the invalidation/validation paradigm for the base class and create my toolbar, if needed, in the commitProperties() method.

27 01 2011
Justin J. Moses

Hi Geoff,

Apologies – I’ve been a little busy of late.

Yea, honestly the state mechanism in Flex 3 has these little idiosyncrasies that makes it difficult to work with. I think going lower level – as you’ve suggested – is the better option. It will be a bit of a headache ensuring you’re covering every scenario, but it should lead you to a better solution in the long run.

Justin

1 02 2011
Hans VDK

Awesome post, thanks!!
You just saved me a whole lotta time 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: