A few days ago someone in the Flex 4 prerelease forums posted an interesting question: how do you create a rounded clip area for a spark container? Not knowing the answer off the top of my head, I thought this would be a good opportunity to teach myself some specifics about creating custom container components in Flex 4.
First I tried the obvious, which was to set up two elements and make one the mask of the other, like so:
- <!-- maskee -->
- <s:Group id="cpmaskee" width="400" height="250" top="20" left="20"
- <!-- this is the content -->
- <mx:Image source="@Embed('wallpaper-halo-3-01.jpg')" x="-100" y="-100"/>
- <!-- mask -->
- <s:Graphic id="cpmask" top="20" left="20">
- <s:Rect width="400" height="250" radiusX="20" radiusY="20">
- <s:SolidColor color="0xCCFFCC"/><!-- can be any color -->
Which resulted in a nice rounded mask over the content:
But this was not quite what I wanted. The entire image was still being rendered, only not visible through the mask. So the edges of the image needed to be clipped regardless of whether the corners were rounded. And to be able to see a rounded border.
Usually, when adding new upgraded SDKs to Flex Builder, say to version 3.4, I’ll go to the adobe open source site and download them from here. Problem is, I’ve then got to hunt around for the download link for the datavisualization components and the automation components (not that I use them all that much, I just like to have them handy).
This page on Adobe’s website tells you that the datavisualization components and the automation components are available on this page. And yet you go there, and no download link. Turns out that the actual download page was listed on the Flex Team’s blog, which leads you to the correct download page here. Good thing I bookmarked it, or I might have a real hard time finding it, cause it sure doesn’t show up on a simple Google search.
And then I’ve got to merge the upzipped datavisualization and automation folder structures with the unzipped Adobe SDK download, to get a “complete” SDK.
What a huge pain.
But there’s an easier way.
While I was installing Flex Builder to a new machine, including migrating all my SDK version folders, I thought, why not take a peek at the latest Flash Builder 4 Beta 2 application installation?
And lo and behold, versions of the following SDKs, which include datavisualization and automation components:
- Flex SDK version 220.127.116.1184 (stable build)
- Flex SDK version 18.104.22.16885 (milestone build)
(You can find the full SDK version number in the flex-sdk-description.xml file in the root of the SDK folder.)
So all I did was copy those folders from the Flex SDK 4 Beta 2 sdk folder to the Flex Builder 3 sdk folder, et voilà! :)
NOTE: the Flex SDK 4 Beta 2 download from the Adobe Labs page is incorrectly named as version 22.214.171.124509 in the filename. This zip file is in fact version 126.96.36.19985, and is the exact same zip file as the milestone listed on this page, which you can download here.
Except for one thing…
I’m going to throw my hat in the ring here: I think naming Flex Builder as Flash Builder is a good thing overall. Part of the challenge for developers today is that there are now so many interconnecting technologies under the umbrella of the Flash Platform, that some of the naming needs to catch up with technology, and I believe that’s what’s happening here.
The Flash Platform now consists of a technological system comprised of multiple runtimes, tools, frameworks, and languages, so that simple words such as “Flash” and “Flex” no longer suffice to differentiate what we’re talking about anymore. In fact, I personally wrote an entire chapter in our book Professional Flex 3 on describing the Flash Platform and the “Flex ecosystem of technologies” just to clear the matter up.
Personally, associating the word “Flex” with an SDK (consisting of a framework and a compiler), a development tool, a framework and an overall development methodology, in my experience has led to a lot of confusion. Using the word “Flash” generically has also lead to a lot of confusion — is it a runtime, an IDE, the file you run in the browser, or an approach to rich media development? What is Flash? What is Flex?
I think the time has come to drop the generic use of the words “Flash” and “Flex”. Or at the very least, for the sake of tech pundits and journalists who may not have the in-depth knowledge of us designers and developers, to assign the word “Flash” as meaning “the Flash Platform” or “the Flash Player”, and have “Flex” mean either “the Flex framework” or “Flash Platform enterprise/RIA development.” That would be my vote, and how I have come to think of those two words in generic terms.
In rebranding Flex Builder to Flash Builder, what we are seeing here is a move away from using the word “Flex” as describing “enterprise or RIA development in the Adobe technology space” (amongst its other uses) toward using the word to describe simply the Flex framework and associated tools. By moving back toward the use of the term “Flash,” Adobe is slowly rebranding Flex as being a subset of the Flash Platform, not a complete technological ecosystem in and of itself, which on the whole is a lot clearer and more balanced. And I’m all for making things simpler and clearer for clients to understand and adopt the technology.
When I am coding a large class file with several nested code blocks such as methods, try/catch statements, if statements, for loops, I have to use Notepad++ to have access to Indentation Guides, because this feature is not built into Flex Builder. Indentation guides are vertical lines in the editor that follow the tab stops in the document so that code blocks can be visually tracked.
To me this is an essential feature: it is a crucial element of code assist, enabling me to keep track of all the open and closed blocks. I wish Flex Builder had this feature, which is found in several other code editors. If you want to see this feature in Flex Builder, please go vote for Feature Request #17634 on Adobe JIRA:
[#FB-17634] Indentation Guides in Flex Builder
It is with great concern that I have learned on Deepa’s blog that Adobe will be going forward with the FxClass prefix naming scheme for Gumbo and ditching namespaces for Gumbo components. It sounds like others aren’t too thrilled about it either. I’ve logged feature request SDK-17854 on the Adobe Bug System, so please vote for it if you think namespaces are a better idea than class prefixing.
The reasons I don’t think it makes sense to adopt a Fx class prefix instead of a new namespace are:
- It introduces inconsistency in the implementation of the MXML 2009 specification (which will be updated with this change soon).
- It reduces the amount of choice offered to developers, and the flexibility of the Gumbo workflow. With namespaces, the developer has the option of choosing their own namespace name for the Gumbo and Flex 3 components, or omitting the namespace altogether if they wish.
- It’s not intuitive. Having to remember that I have to type FxButton for a Button class, every time, even if code completion helps me type the “Fx”, forces my overloaded brain to work that much harder.
- It will create forward compatibility issues. What will they name the Flex 5 components? <Fx2Button /> ? <GxButton /> ? Adobe, think of the children… : )
- It makes Flex harder to learn for beginners. Having trained many Flex beginners and written many beginner Flex tutorials, I can say unequivocally that introducing an inconsistency in the specification at such a core level will present yet another Flash Platform “Quirk” for beginners to cram into their heads, and will make Flex 4 harder to learn for beginners (if only by a small bit). I’m not saying it will be a deal breaker, but Adobe won’t be doing the Flex 4 adoption rate any favours.
What I’ve proposed in the feature request is that Adobe keep namespaces for Gumbo components, and introduce some added intelligence in the code completion to make it easier to avoid mistaking <mx :Button/> for <fx :Button/>
Please go vote for it and change Adobe’s mind on this one.