Wednesday, February 9, 2011

Upgrading Your Flex 3 application to Flex 4 - Part II

In Part I of this series we discussed the impact of upgrading your Flex 3 application to Flex 4.  In Part II we continue to survey the areas of greatest impact.


Additional areas of consideration when upgrading my your Flex 3 application?
  • your teams' grasp of the Flex Graphics Classes and FXG in Flex?
  • refactoring your CSS
  • refactoring the layout classes in MXML
  • the evolutionary stage of your application
Your Teams' grasp on the Graphics classes in Flex/ Actionscipt 3.0

In Flex 4, we spend a considerable amount of time skinning our applications.  In doing so we often use the following Graphics classes to build the layout for our Skins:
  • BitmapFill
  • BitmapImage
  • ColorTransform
  • Definition
  • Ellipse
  • GradientEntry
  • Grpahic
  • Line
  • LinearGradient
  • Path
  • Rect
  • and Many More...
All the Graphic classes can be found in the spark.primitives package

Learn more here:
Adobe Help on Graphics Classes

Getting a grasp on how they work and where to use them can be a tedious.  This requires an understanding of not only skinning, but also the difference between the Graphics classes and the use of Skin Parts in your Skin

There are actually two versions of the Classes:  those that belong to the FXG world and the native Flex based equivalent.

FXG is a XML based file format specification developed by Adobe that allows cross-application graphic file support.  Its found in Adobe Illustrator, PhotoShop, Flash, Catalyst, and Flex.  The FXG format is useful in the Designer/ Developer workflow and allows the  Designer to have greater control over the "look and feel" independent of it's function.  It allows you to use Vector Graphics vs Bitmap graphics in your application which can have HUGE impacts on the size and performance of the application.

Learning how to implement and build applications using these specfications isn't extremely difficult but takes time, but can have huge impacts on your overall application layout and design.

Bottom line:  Learning Curve Impact - medium, Impact to delivery - high, cultural adoption - low

Refactoring Your CSS

In Flex 4, CSS has changed substantially.  With the addition of new namespaces, as mentioned in Part I, the implementation of CSS in Flex 4 had to change as well.

In your CSS document, you are now required to define the namspaces you use in your application.  For instance:

@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/mx";

These namespaces plus and custom namespaces you may use in your applications allow developers to have greater control over the use of Type Selectors, Class Selectors, etc

Within our CSS documents we can now use the following:

Type Selectors:
                s|Button{
                      color: #FFCC00
               }
Class Selectors:
              .headerText{
                    font-size: 12pt;
                    color: #CC00CC;
              }
Descendant Selectors:
                   s|Panel s|Button{
                       fontSize: 12pt
                       color: #CCFF00;
                  }
idSelectors:
            #submitButton{
               color:#FF0000;
            }
Pseudo Selectors:

           s|Button:down{
             ....
           }
           s|Button:up{               .
             ...
           }
           s|Button:over{
               ....
           }

Getting used to the new CSS specification, can be a daunting task (spoken like true developer).  It obviously helps if you are familiar with CSS in the HTML world.  This does not mean that the CSS implementation translates word for word in the Flex world by any means, but we are now closer than we were in Flex 3.

Bottom line:  Learning Curve Impact - low-medium, Impact to delivery - medium, cultural adoption - low

Refactoring your layout classes in Flex 4
This is one of the higher impact areas since Adobe threw us a curve ball in Flex 4 with new Layout classes that use composition vs inheritance.

The layout classes have changed and it would be best to study the change before trying to hack your way through.

Yes, you can change the tag to and get much of the same effect, but that doesn't mean you should.
The new layout classes are as follows:

Non-Skinnable
      Group...
      Datagroup...

Skinnable Containers
       Skinnablecontainer....
       Skinnabledatacontainer....
       Panel....
       Application....
       Bordercontainer.....


plus others...

This has had an impact on how we approach layout.  On top of that, each of these containers have their own layout classes that we can use to control how the children are rendered in the containers themselves.

Each container has a VerticalLayout, HorizontalLayout, BasicLayout, or TileLayout you can apply.  You can also create your own layout classes at will by extending the LayoutBase class.

Bottom line:  Learning Curve Impact - medium, Impact to delivery - high, cultural adoption - low

The Evolutionary stage of your application'

Before upgrading the application to Flex 4, you should think about level of effort.  Possibly your application is not at a stage in the life cycle to bother with the refactoring effort.  There is an old addage:  "If it a'int broke, don't fix it".  Same applies here.

If you just started the application and are considering the move..."Make it now".  Its better to start anew vs building and refactoring.

If you are new to Flex 4 and haven't learned Flex 3 yet, I propose you move directly to Flex 4 and spend more time there.  It is useful to have an understanding of the MX controls and containers as you can't avoid their use all of the time (i.e.

Bottom line:  Learning Curve Impact - medium-high, Impact to delivery - high, cultural adoption - low
I hope this has helped in thinking through the impact of upgrading your application from Flex 3 to Flex 4.


Mudd Brick Inc, provides Web Consulting and Training services.  Check us out at http://www/muddbrick.com

Monday, January 10, 2011

Upgrading Your Flex 3 application to Flex 4 - Part I

I recently received a question while mentoring a developer on upgrading their Flex 3 application.  The question was "how hard is it to upgrade my Flex 3 application to utilize the Flex 4 SDK?"

My answer :  It depends...I knew I should be a consultant from age 10...:-)

Here is the link to the Migration guide for Flex 4.

And a Technical Guide to Upgrading Flex 4 applications
 
What should I consider when upgrading my Flex 3 application?

Since this post is not a regurgitation of the technical details, let's look at the 30 thousand foot view on the impacts of upgrading:
  • Flex 4 introduces new namespaces
  • What's your investment in Flex 3 View States?
  • Have you invested in building Flex 3 Custom Components?
  • Do you have a clue about the Flex Graphics Classes in Flex?
  • Have you invested in CSS?
  • Which layout classes in MXML have you used?
  • The evolution stage of your application?  Are getting ready to deploy to production?
The above questions and more will surely impact your choice on when and how you may plan to "upgrade" to the Flex 4 SDK.  It's not so much about "how hard it is"  vs the learning curve of your developers, impact to the delivery of your application, and adoption of the new cultural shift in development mindset.


Introduction of new namepaces

The new UI Component framework really threw me for a loop early on as my mindset had to change from one of inheritance to composition.  What the hell does that mean?  In Flex 3 the containers we use literally contain everything.  If I need a border, there is an attribute for that.  If I need to turn on or off scroll bars, there is an attribute for that...

Flex 4 is different, in that the components and containers are lighter weight.  The containers contain layout rules as they did in Flex 3, however the functionality is separated from the  look and feel of the component.  In other words, we have greater control over the look and feel of the component and containers through a process called "skinning".

The power skinning provides far outweighs the impact on the project timeline, but you can't forgo the thought that it won't impact your project timeline or delivery.   My experience with this relates to poorly managed projects where a new feature is introduced and adopted before we had an opportunity to deliver Phase I. #FAIL 

Skinning is like freedom, there is a price to pay!!!

Bottom line:  Learning Curve Impact - medium-high, Impact to delivery - medium, cultural adoption - low


Flex 4 View States

Flex 4 introduces a massive shift in the use and implementation of View States.  Frankly, I use View States but in a limited fashion.  I have seen developers "over use" View States to manage View changes and transitions where pure Actionscript 3 would probably do the trick.  View States are cool, but sometimes offer more traps as the UI become more and more complex.

If you have invested heavily in View States in Flex 3 then refactoring those to fit the Flex 4 model could have a significant impact on delivery.  The learning curve impact isn't that significant as View States in Flex 4 are easy to learn and allow you to control your Views children with greater ease.  But, converting them from Flex 3 View States could be a refactoring nightmare. 

Bottom line:  Learning Curve Impact - low, Impact to delivery - medium-high, cultural adoption - low

Investment in Flex 3 Custom Components 

Using Flex 3 to build custom components in your application required an investment in the Flex Component Lifecycle.  Developers really had to understand the utilization of CreateChildren(), UpdateDisplayList(), CommitProperties(), and Measure() and how that impacted the creation of new children in the View Component.

Since Flex 4 separates Form (the Skin - How the Component looks - graphics, skin parts) from Function (the Custom Component - the implementation of a View), new challenges are introduced as to how the Children are created and displayed and how they function once displayed.  The beauty of it is your developer no longer has to understand the difference between "rawChildren" and "regular" children in the this scope.

Flex 3 Components are still useful but the implementation of the new Flex 4 approach is a mind set change.  This may impact how fast your developers adopt the new approach.  With learning comes effort and effort takes time.  The learning curve impact here might be more so a shift in mindset vs technical know how.  As with learning anything, first start with understanding the terminology:  States, Skin parts, etc

The new approach is this: 1. Create a Custom Component.  2.  Specify it's States  3.  Extend the new Skinnable Container  4.  Build a new Skin Class with HostComponent parts and graphics defined and 5. implement the skin using the SkinClass. 
*** note: There is more to it as your component becomes even more complex, but those are the general steps

Check these links out for more information:

Dan Orlando - Creating Custom Components in Flex
Ryan Stewart - Building Custom Components in Flex 4
Christophe Coenraets - Building Flex 4 Components

Bottom line:  Learning Curve Impact - medium-high, Impact to delivery - medium, cultural adoption - medium

In Part II, we'll explore the impact of:
  • your developers grasp of the Flex Graphics Classes and FXG in Flex?
  • refactoring your CSS
  • refactoring the layout classes in MXML
  • the evolutionary stage of your application
Mudd Brick Inc, provides Web Consulting and Training services surrounding these issues in Rich Internet Application development.  Check us out at http://www/muddbrick.com
 

Tuesday, January 4, 2011

You don't have to be a Thought Leader to blog, my montra for 2011?

  How will you define yourself in 2011?

As we start into the new year, 2011 brings with it many opportunities as well as challenges.  Usually around this time of year, I begin to think of new ways to stay on the cutting edge, which for me, after 15 years in the industry, becomes more and more of a task.  In Tweetland, I am beginning to hear more and more about what it takes to stay 'cutting edge'.  No longer does your resume stand for itself, it's now your blog posts, tweets, books you've read, linked-in profile and Facebook statuses that define who you are in the industry.

I started thinking about this a few months ago and had to chew on it for a little while so I could figure out what to write about.  Ever heard the term Thought Leadership?  Are you a Thought Leader, a Thought Translator, a Thought Implementer?  Not Sure?  It "doesn't matter, just blog, tweet and read!"

What is Thought Leadership? 

First, I guess we have to define what Thought Leadership is really all about.  I decided to forgo the cliche 'wiki' or 'webster' definition and search for a definition I liked.  I am not sure it's the most scholarly approach but who cares!

Here goes:  
"Thought Leadership is establishing a relationship with and delivering something of value to your stakeholders and customers that aligns with your brand/company value. In the process you go well beyond merely selling a product or service and establish your brand /company as the expert in that field and differentiate yourself from your competitors" - Craig Badings  http://bit.ly/gjGURI

I don't know Craig or his business but I feel like he hit the nail on the head.  It's about IDEAS and how you use them to add VALUE to your customers/ community.  It's also about differentiation and branding yourself/ your company as an expert!

Thank God for the Thought Leaders in our industry.  BUT, do you HAVE to be a thought leader to be successful?

What about a Thought Translator?  (I, er...um made this up btw)

For the longest time, I have operated under the montra of "If I am to make it in the Adobe Community as an expert, I must be a Thought Leader! I must Blog cutting edge ideas about Adobe Flex or ColdFusion, I must Tweet about new ideas, and I must to have a Facebook page sharing my company with the masses ".  For some reason, it never came to fruition in 2010 as much as I had hoped.  The reason:  I thought I had to be a Thought Leader to be successful...and the fact that I was pretty busy most of the time with client work and didn't MAKE the time to fit it into my schedule.

Recently, I received a Tweet from a buddy of mine Joel Hooks, "shout out".  It said:  "I don't think it matters that your ideas have already been published. It is your distillation that is interesting."  DISTILLATION.  So Joel, you're saying I can be a Thought Translator!?  Sweet!  I suspect so many in our community fail to blog because of this very fact.  There is absolutely a place in the community for those who have the skills to "distill" what the Thought Leaders in the industry are saying, especially for those who are new to our industry or don't have the honed skills of the Thought Leaders.  There are many skilled developers out there that have something to say...Just Say It!  Please.

My role in the industry as an Adobe Certified Instructor and senior developer has always been on the edge.  I've haven't been on the front-lines (in the field) as much as many of my collegues...you know who you are!   I spend about 50% time in the classroom 'baptizing' new members into our community and about 50% in the field either mentoring or work on project teams.  I enjoy the opportunity working with the Uber-Gods in the industry and then having the opportunity to "translate" for the masses...

Can you be successful as a Thought Implementer in our business?  Of course, you can.  Many developers are content with not being on the edge and implementing the ideas and knowledge they've learned.  They have a story to tell too.

What about a Thought Implementer?

If you are new to the industry and question whether your story is worth telling, I can completely empathize with you and how you feel.  Remember, as you learn, you grow and your growth in the community is what we want to hear about.  Tell your Story, you may find that you are a Thought Leader after all.

Conclusion

My goal in blogging for 2011 is to continue to be a Thought Translator.  There may be times where I decide to share a story of Thought Leadership and my opinions on things.  The cool thing is SO CAN YOU! 

I guess my point with this rant is that there is opportunity for all of us in 2011 and beyond to tell a STORY, to share IDEAS, and to create VALUE for yourself, your company, and the community.


Happy New Year...Here's to a successful 2011


Dan Blackman
http://www.muddbrick.com
dblackman@muddbrick.com

Monday, August 2, 2010

Dallas Techfest Preso

Hello from Dallas Techfest!  I just finished a great day of presentations.  I spent the morning discussing the details surrounding Flex 4 and the integration of ColdFusion 9 and BlazeDS services using Model Driven Development and BlazeDS Messaging and the second presentation detailed the new changes in Flex 4 with code included in both 

I have to give credit where credit is due.  Dave Ferguson presented at CF Meetup a few months back.  The link to the presentation is here  Dave used the FDMSBridge within BlazeDS to show how Ajax can leverage the Messaging Service.

I decided to go an alternate route and use Flex as the model.


Topics Covered:
  1. ColdFusion 9 Enhancements
  2. Flex to ColdFusion 9 
    • HTTPService, WebService, and RemoteObject
    • Model Driven Development
  3. Define ColdFusion 9 and Blaze DS relationship
  4. Messaging Options - FDMSBridge and Flex
  5. How to configure the messaging service
    1. Messaging Gateway
    2. Client Polling
  6. Demos

The other presontation I delivered was highlights on Flex 4.  We covered topics such as the Flex 4 Component Architecture, Flex 4 View States, and the Styling and Skinning changes

A good friend of mine Jeff Tapper from Digital Primates spoke on similar topics at various
conferences nationwide (Again, credit where credit is due).  I took a bit different approach in terms of detail and demos.  Props to Mr Tapper, his presentation can be found here

1.  Flex 4 Component Archistecture
  • New Component - namespaces Mx, Spark, Fx
  • Skinnable Containers vs Non Skinnable Containers
  • New layout approaches
  • DataGroup vs mx Repeater class
  • Flex 4 View States vs Flex 3 View States
  • Flex Styles - Id Selectors, Descendant Selectors, Class Selectors, Psuedo Selectors
  • Flex 4 Skinning 
    • SkinClass - 4 parts
      • Host Component
      • Skin States
      • Skin Parts
      • Graphics
  • Flex Skinning - Benefits and comparisons to Flex 3 Skinning
Download Preso and files:

TechFest 1

TechFest 2 CF files


If you have questions, feel free to shoot me an email dblackman@muddbrick.com

Twitter - @muddbrick

    Wednesday, December 2, 2009

    Flex 4 - New View States Model Part II:


    In Part I of the discussion of View States, I explained the differences of Flex 4 View States vs Flex 3 View States.  In Part II, we will explore the differences in the implementation thereof.

    In Flex 4, we still use the container property currentState to handle toggling between states.  Once the states are defined:

    <s:states>
    <s:State name="image"/>
    <s:State name="progress"/>
    </s:states>

    We can use Overrides to define the containers, controls, properties, or styles we wish to include or exclude as part of a defined View State.  The cool thing is NO LONGER does this happen as part of the STATES BLOCK.

    For instance, to include the below code in the "image" view state, you would simply add an includeIn="image" to a container or control within the defined layout:

    <s:Group width="100%" height="100%" includeIn="image">

    <mx:Image id="mainImage"
    verticalCenter="0"
    horizontalCenter="0"
    width="400" height="400"
    maintainAspectRatio="true"/>
    </s:Group>

    Note:  This is much like using <mx:AddChild>in Flex 3 View States

    By adding the includeIn property for the Spark Container called Group, this "overrides" the container's default state and includes this in the image View State defined above.

    The same can be done by handling this with the reverse "excludeFrom" attribute.  The exlcudeFrom attribute omits the container or control from the View State specified. 
     Note:  This is much like using <mx:RemoveChild>in your Flex 3 ViewStates

    Note:  The use of IncludeIn and ExcludeFrom are MUTUALLY EXCLUSIVE.  Do not try to use the two attributes together in the same container/ control.  This use of the two within the same container/ control will result in an error.

    Now, properties, style and even handlers may be included in the View State as well.  To do so, we simply use Dot notation to specify the state we wish to include the property change in.

    For instance, if I want to change the width of a container from 400 to 700 when we toggle to the progress state, we simply include that in the definition of the property:


    Notice, when we begin to type the width property and then a "." after, Flash Builder automatically provides us with a drop down of the state choices for which we want to include this property.

    The finished property definition would look like this:

    <s:Group width="400" width.image="700"...>
    Note: This is much like using <mx:SetProperty> in your Flex 3 ViewStates


    The same goes for Styles in Flex 4.  We can use "Dot" notation to define the states we wish to include a specific style within for a particular container or control.




    Note:  This is much like using <mx:SetStyle> in Flex 3 View States

    By specifying the contentBackgroundColor style against the same Group, the backgroundColor of the Group will change as the currentState is set to "image".

    In this post we looked at the use of "Overrides" in Flex 4 View States and how they have changed the way we use states within our application.

    The things you want to remember:

    includeIn
    excludeFrom
    The use of dot notation for defining properties and styles as part of your new View States

    In Part III of the series, we will look at more advanced features of Flex View States!

    Mudd Brick Out


    Check out the training offerings at Mudd Brick now!

    http://www.muddbrick.com/training/


    Onsite Training in Flex, Flash, and ColdFusion available now.

    Tuesday, November 24, 2009

    Flex 4 - New View States Model Part I:



    After presenting at the Flex 4 for ColdFusion Developers seminar in Dallas, I was fascinated by the chnage in the View States Model in Flex 4.  In Flex 3, the use of View States required that you create a Base State from which you would create several additional states from the original.  Creating View States in Flex 3 was much akin to creating a Powerpoint Presentation.  In Powerpoint, we have a master slide from which we create additional slides "inherit" assets, such as a banner image, from the Master slide

    Below is a sample snippet from the Flex 3 Rich Client Applications course where we create a block with embedded tags.  These tags define each individual "Layout" of various states within your application. 

    <?xml version="1.0" encoding="utf-8"?>
    <mx:Application
    xmlns:mx="http://www.adobe.com/2006/mxml"
    layout="vertical"
    backgroundColor="#aaaaaa"
    backgroundAlpha="0">

    <mx:states>
            <mx:State name="forms">
                    <mx:RemoveChild target="{linkbutton1}"/>
                    <mx:AddChild relativeTo="{panel1}" position="lastChild">
                        <mx:HBox>
                        <mx:Form>
                          <mx:FormHeading label="Contact Us by E-mail"/>
                          <mx:FormItem label="First Name:">
                                     <mx:TextInput/>
                          </mx:FormItem>
                          <mx:FormItem label="Last Name:">
                              <mx:TextInput/>
                         </mx:FormItem>
                         <mx:FormItem label="E-mail Address:" required="true">
                             <mx:TextInput/>
                         </mx:FormItem>
                         <mx:FormItem label="Message:">
                            <mx:TextArea width="160"/>
                            <mx:Button label="Send Message" click="currentState=''"/>
                         </mx:FormItem>
           </mx:Form>


    In Flex 3, we used AddChild, RemoveChild, SetProperty, etc tags to defined the new children, styles, property changes, etc in our View.  This approach was easy given that the design view allowed us to click and create new states.

    In Flex 4, View States have changed dramatically, not so much in the Design Mode but in the underlying implementation thereof.  You can still use the design view in Flash Builder to define your Layouts, but what you'll find under the hood is dramatically different from what you might have seen in Flex 3 Builder.

    Notice in the below snippet the <s:states> block has changed quite a bit.  No longer do we create a hierarchy of code at the top of our MXML template.</s:states>

    <s:states>
    <s:State name="image"/>
    <s:State name="progress"/>
    </s:states>


    First off, the states tag in now under a completely new XML namespace.  The states block tag now belongs to the Spark Components and Containers set.  This is the new Container and Component structure introduced as part of the Flex 4 release. 

    Secondly, noticed that the states block is no longer of a hierarchical nature...You simply define the states you want to create as part of this MXML Application or View. 

    View States, in Flex 4, use the same familiar idea of creating multiple Layouts within a single MXML View. 

    Note: In the Real World, you will find the View States are created as part of your View, not so much as a part of a single MXML Application View.

    So then, you may ask, how do these Views get incorporated in the UI so I can toggle between Layouts.  Well, my friend, that's the beauty of the Flex 4 View States Model.

    Steps in creating a Flex 4 View State:
    1. Define a Custom Component using the new Spark Layout Containers
    2. Add a block to your MXML component.  (Typically located at top of the code below the defined layout)
    3. Add tag to your block and you now have a defined layout.
    4. Add the new Overrides "includeIn" and "excludeFrom" along with setting new properties, events, and styles
    In Part II, we will explore the use of  the new Overrides of the Flex 4 View State Model and how they allow us to redefine the layout WITH OUT using a hierarchical set of tags.

    Mudd Brick Out

    Check out the training offerings at Mudd Brick now!
    http://www.muddbrick.com/training/

    Onsite Training in Flex, Flash, and ColdFusion available now.

    Tuesday, November 17, 2009

    Tex Flex Preso

    I wanted to publish my slide deck from the Flex 4 for ColdFusion Developers presentation Friday.

    Here ya go.

    http://slidesix.com/view/CFFlexRoadshow-QnBDB

    Items covered:

    1.  Flash Remoting
    2.  Flash Builder connection wizards - Model Driven development
         ColdFusion Builder Wizards
    3.  Sending Typed objects back from ColdFusion
         Data Paging with Model Driven Development
    4.  ColdFusion as a Service - CFaaS
    5.  ORM Development with ColdFusion and Hybernate...