Flex Roadmap Part I
This was an interesting session from a few different points. First the notes:
- advisory note: everything shown is in expiremental phase
- short recap for those that missed Thermo sneak
- they indicate the Flex team is excited about Thermo
- splitting into two teams, one focused solely on development features (Flex), others focused on design features (Thermo)
- recap of where Flex is atm -
- designers need freedom (drawing rounded rectangles, setting alphas on everything, etc)
- Flex SDK focuses on components
- therefore we have a high level and very low level (programmatic drawing), but nothing in between
- enter MXML Graphics
- MXML Graphics -
- simple shapes, complex paths, masking, filters, blend modes, etc all with scale 9 support
- should be run-time editable, making it easy to animate
- focused on performance
- need ability to trade off runtime editablity against memory and speed
- Re-evaluation of Framework component design -
- currently a problem with components, that goes like this:
- they expose certain styleable props of a button
- folks request that the button's label have the alpha settable
- they expose, build, test, deploy
- works great, then folks request that the button's corners not be rounded (or something)
- problem predicting what folks want to do with the views of components
- further, current code is complex
- e.g. Button is 2200 lines of code
- enter true MVC (Model View Controller) separation
- model - at its core, what does this component need to expose prop wise (e.g. the label for Button, that is it)
- controller - event handling for mouse/key input, but just with/respect to setting current states and events
- view - should be completely definable just using MXML
- big advantages
- can complete alter the look of a component, more so than is possible today
- no changes to any controller code, it is still a button
- becomes VERY easy (demo was cool) to alter component's look
- demo -
- again shows old button code, 2200 LOC
- shows new button code
- 20 lines in model
- controller code maybe a 2-300 LOC
- view is all MXML Graphics and states
- alters the MXML view of the component and immediately can make very cool looking buttons
- repeats the demo process with scroll bars and lists
- with scrollbar, some things are defined as optional
- for instance tweaks view of a scrollbar to have no buttons (thumb and track only)
- with list, makes very different animated looking lists, accordians, etc with minimal and frankly easy to understand and implement changes to MXML
- near the end of the session folks starting commenting how cool this whole thing is
- a few begin to wonder why they should even consider Flex Builder 3 at this point
- the speaker notes
a) this is still expiremental
b) they are committed to backward compatibility, so components will work in this new design
- advisory note: everything shown is in expiremental phase
- short recap for those that missed Thermo sneak
- they indicate the Flex team is excited about Thermo
- splitting into two teams, one focused solely on development features (Flex), others focused on design features (Thermo)
- recap of where Flex is atm -
- designers need freedom (drawing rounded rectangles, setting alphas on everything, etc)
- Flex SDK focuses on components
- therefore we have a high level and very low level (programmatic drawing), but nothing in between
- enter MXML Graphics
- MXML Graphics -
- simple shapes, complex paths, masking, filters, blend modes, etc all with scale 9 support
- should be run-time editable, making it easy to animate
- focused on performance
- need ability to trade off runtime editablity against memory and speed
- Re-evaluation of Framework component design -
- currently a problem with components, that goes like this:
- they expose certain styleable props of a button
- folks request that the button's label have the alpha settable
- they expose, build, test, deploy
- works great, then folks request that the button's corners not be rounded (or something)
- problem predicting what folks want to do with the views of components
- further, current code is complex
- e.g. Button is 2200 lines of code
- enter true MVC (Model View Controller) separation
- model - at its core, what does this component need to expose prop wise (e.g. the label for Button, that is it)
- controller - event handling for mouse/key input, but just with/respect to setting current states and events
- view - should be completely definable just using MXML
- big advantages
- can complete alter the look of a component, more so than is possible today
- no changes to any controller code, it is still a button
- becomes VERY easy (demo was cool) to alter component's look
- demo -
- again shows old button code, 2200 LOC
- shows new button code
- 20 lines in model
- controller code maybe a 2-300 LOC
- view is all MXML Graphics and states
- alters the MXML view of the component and immediately can make very cool looking buttons
- repeats the demo process with scroll bars and lists
- with scrollbar, some things are defined as optional
- for instance tweaks view of a scrollbar to have no buttons (thumb and track only)
- with list, makes very different animated looking lists, accordians, etc with minimal and frankly easy to understand and implement changes to MXML
- near the end of the session folks starting commenting how cool this whole thing is
- a few begin to wonder why they should even consider Flex Builder 3 at this point
- the speaker notes
a) this is still expiremental
b) they are committed to backward compatibility, so components will work in this new design

Comments