Even as a purist, I don’t think I agree. Containers need to have conrol over the visibility, position and other properties of their contained components.

Either you do this by handling an event of some kind that triggers a handler that changes these properties, or you have this Flex 4 state syntax which is doing the same thing in a more distributed fashion….each property is invisibly bound to a state change event and the property gets updated.

It may be a little more difficult to trace and group property changes relative to an event, but I would argue the new syntax is a much more intuitive way to match a state to a view (or other non visual property).

You can always choose to use it only for visual view states if you fear the traceability challenges but for the example cases I’ve seen, it creates much more intuitive code. One problem I am having is using the syntax with actionscript – don’t think it works there – but I have a couple of uses where it is very helpful and I don’t see the risks you point out.

Why would it be an improvement for components to have code specific to their host container?? This implementation violates basic software design practices and obfuscates what properties/components change when the state is changed.

Not only that but the components that set properties for a given state (e.g. visible.State1=”true”) will have problems if the component doesn’t dictate the behavior for other states as well…i.e. components will disappear, have their text reset, etc. when they specify properties for one state but do not have a setting for other states. This isn’t just breaking behavior from Flex3 — it’s bad behavior.