Flex 4 CSS Namespaces: Annoying Migration Issues

by Gordon. 4 Comments

I started playing around with the beta of the Flex 4 sdk the other day. The purported features of the new version are very exciting to me, especially the support for advanced CSS selectors as well as enhanced component skinning capabilities.

Based on the backwards compatibility with Halo, my initial idea was to migrate one of my existing side projects from Flex 3 to Flex 4 and then incrementally switch over to Spark components as development progressed. In theory this sounded fairly easy, but ultimately this required lots of overhaul to my CSS files and lots of additional bloat. This is due to a design pattern that I favor which heavily depends on reusable custom components and CSS type selectors.

The design pattern is simple: I create custom reusable composite components which consist of several other components and then I style those components in a separate CSS File using type selectors. For instance, I will have a component called UserView which, for simplicity, would just consist of a VBox component containing Image and Label components. This would then be styled in an external css file, style.css, as follows:

UserView { .... }

This component would then be reused in many locations throughout the application. This worked great in Flex 3, however due to Flex 4 requiring all CSS type selectors being qualified with a namespace, this breaks in Flex 4, resulting in none of the styles being applied. The workaround is to create a namespace inside the css file:

@namespace "com.mypackage.views.*"; 
UserView { .... }

Now it works. The problem is, however, in large projects I normally have a multitude of these components in lots of different packages. Thus, since the CSS namespace spec requires that all the namespaces be declared at the top of the file, I have a huge number of namespaces at the top of the file and each component needs to be qualified. E.g:

@namespace views "com.mypackage.views.*"; 
@namespace forms "com.mypackage.forms.*";
...
views|UserView { ... }
forms|Login { ... }
...

This is frustrating because not only does it bloat the code, but it also decreases the spatial locality of the code, requiring me to jump around to mentally resolve namespaces.

If my classes were inside of a flex library, I could give them all the same namespace, e.g. http://ns.mycompany.com/2009, but I cannot find a convenient way to do this for classes which are part of a normal flex project and not pulled in from an external library.

Flex 4 is still great and by no means is this a deal breaker. Other people have overstated this as an EPIC FAIL and others have oversimplified it as a one-line fix (which is only true if you are styling components from a single namespace). It would be nice if there was something like the following:

@namespace "com.mypackage.**";

Or at the very least:

"com.mypackage.views.*"|UserView { ... }

Avoiding the requirement of having lots of declared namespaces.

  • http://www.karenyseba.net/ Sebastian Bernstein

    It might sound like a problem, in fact I also noticed that also changed the way you register CSS Styles into the CSSManager since what use to be “UserView” now is “com.mypackage.view.UserView” forcing you to rewrite a lot of code if you use the way Adobe recommended to define the default styles to a class.

    Still don’t be to hasty to complain, this is just a minor change compare to what it takes to go from hallo to spark on a program including the way some stuff has been changed from the core like the way text is processed.

    If you’ve been a flash programmer since the beginning all this should not be a surprise to you.Every mayor version of flash (this is every 2 years) comes with vast changes on the programming architecture that force you to learn all over again, I still remember what it was to go from the first version of FLASH to when they make it actionscript emacs4 compliant, or when they went from FLASH to Flex.

    I think they are moving in the right direction, and even I’ve just started my learning process of Flex 4, I’ve already realized that there are some mayor changes on how things has been rethinked and probably I’ll have to rewrite most o what I have to take advantages of this changes, in the end of course I’ll end up with a program that is a lot more up to date to programming trends :) .

    Still there is a point on what you are saying, as actionscript becomes more powerful and applications get more complex, Adobe should restrain itself of doing this huge changes on the way the code is written since each time the overhaul gets a lot harder.

  • http://www.karenyseba.net/ Sebastian Bernstein

    It might sound like a problem, in fact I also noticed that also changed the way you register CSS Styles into the CSSManager since what use to be “UserView” now is “com.mypackage.view.UserView” forcing you to rewrite a lot of code if you use the way Adobe recommended to define the default styles to a class.

    Still don't be to hasty to complain, this is just a minor change compare to what it takes to go from hallo to spark on a program including the way some stuff has been changed from the core like the way text is processed.

    If you've been a flash programmer since the beginning all this should not be a surprise to you.Every mayor version of flash (this is every 2 years) comes with vast changes on the programming architecture that force you to learn all over again, I still remember what it was to go from the first version of FLASH to when they make it actionscript emacs4 compliant, or when they went from FLASH to Flex.

    I think they are moving in the right direction, and even I've just started my learning process of Flex 4, I've already realized that there are some mayor changes on how things has been rethinked and probably I'll have to rewrite most o what I have to take advantages of this changes, in the end of course I'll end up with a program that is a lot more up to date to programming trends :) .

    Still there is a point on what you are saying, as actionscript becomes more powerful and applications get more complex, Adobe should restrain itself of doing this huge changes on the way the code is written since each time the overhaul gets a lot harder.

  • Ruben Swieringa

    if you’re frustrated with having to make a namespace for each class-package you should look into manifest files, it’ll allow you to map a range of components under a certain url (that you define). ..pretty much the way Adobe does it with Flex native classes.

    http://www.adobe.com/livedocs/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocsBookParts&file=compilers12343.html

  • Ruben Swieringa

    if you're frustrated with having to make a namespace for each class-package you should look into manifest files, it'll allow you to map a range of components under a certain url (that you define). ..pretty much the way Adobe does it with Flex native classes.

    http://www.adobe.com/livedocs/flex/201/html/wwh…