Re-architecting the designer-developer workflow

2,850 views

Published on

These slides are from a presentation at 360Flex DC on 21 September 2010.

Most application development follows a pattern where the designers design it then the developers build it. Any change in the design requires more work from the developers, who have to implement each change request.

It doesn’t have to be this way. By modifying the application architecture, we can enable the developer to do their work before the designer, leaving the designer free to alter the design as frequently as they wish without recourse to developer time.

This frees designers to respond to client requests in a timely manner and frees developers to work on a more strategic level, adding functionality to the tools the designers use without being bogged down in day-to-day client projects.

In this session I’ll describe this new architecture, how and why I developed it, the benefits and pitfalls of its use, and how to implement it using any of the current dependency injection frameworks.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,850
On SlideShare
0
From Embeds
0
Number of Embeds
1,159
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide













































  • Re-architecting the designer-developer workflow

    1. 1. LFPUG, July 2010 Re-architecting the designer-developer workflow Richard Lord twitter.com/Richard_Lord Technical Architect www.richardlord.net BrightTALK www.brighttalk.com
    2. 2. Coming Up A story Lots of code A new architecture
    3. 3. The Set-up
    4. 4. At BrightTALK we do webcasting
    5. 5. At BrightTALK we do webcasting
    6. 6. We have a set of standard players on our website and we create custom players for specific clients.
    7. 7. Old workflow Client Designer Developer
    8. 8. May 2008
    9. 9. A new player (using Cairngorm!)
    10. 10. Restyling with CSS
    11. 11. Goran (Lead Designer)
    12. 12. November 2008
    13. 13. Another client project (using Mate)
    14. 14. Meanwhile, Goran did something very un-designer
    15. 15. He built a widescreen player Using the code from another player
    16. 16. This gave me an idea
    17. 17. Since our designer can write MXML, can we enable him to build an app using only MXML?
    18. 18. January 2009
    19. 19. Components version 1
    20. 20. Too much influence from Mate Too many non-visual components
    21. 21. Can we build an app using only visual MXML?
    22. 22. May 2009
    23. 23. Smart components
    24. 24. Smart components contain the view and associated functionality.
    25. 25. Smart components can find and talk to each other.
    26. 26. Designers choose smart components based on user-interface functionality.
    27. 27. Designers assemble the user-interface, and the application just works.
    28. 28. Designers apply skins and css to the smart components to design the app
    29. 29. The approach • Flex 3 • Dependency injection (with SmartyPants-IOC) • Simple event bus • Test driven development • Lots of refactoring • MVC is NOT a requirement
    30. 30. ... Live Code ... (a twitter client)
    31. 31. One non-visual element remains, the context, to handle application configuration
    32. 32. MXML <mx:Application> <tw:TwitterContext/>    <mx:VBox> <tw:TweetsList/>        <mx:TextInput  id="searchInput"/>        <tw:SearchButton  label="Search"  searchTerm="{searchInput.text}"/>    </mx:VBox> </mx:Application>
    33. 33. Search Button public  class  SearchButton  extends  Button  {   [Inject]   public  var  manager  :  SearchManager;   [Inspectable]   public  var  searchTerm  :  String;   public  function  SearchButton()   {     addEventListener(  MouseEvent.CLICK,  performSearch  );   }     public  function  performSearch(  event  :  MouseEvent  )  :  void  {     manager.search(  searchTerm  );   } }
    34. 34. Search Manager public  class  SearchManager  { [Inject] public  var  service  :  SearchService; [Inject] public  var  tweetCollection  :  TweetCollection; [PostConstruct] public  function  setUpListeners(  injector  :  Injector  )  :  void  { service.addEventListener(  TweetEvent.TWEETS_LOADED,  updateTweets  ); }   public  function  search(  searchTerm  :  String  )  :  void  { service.send(  searchTerm  ); }   private  function  updateTweets(  event:TweetEvent  ):void  { tweetCollection.assign(  event.tweets  ); }   }
    35. 35. Search Service public  class  SearchService  extends  EventDispatcher  { [Inject] public  var  request  :  TwitterRequest; [PostConstruct] public  function  setUpListeners(  injector  :  Injector  )  :  void  { request.addEventListener(  ServiceEvent.COMPLETE,  parseResults  ); } public  function  send(  searchTerm  :  String  )  :  void  { request.url  =  "http://search.twitter.com/search.atom"; request.sendData  =  new  URLVariables(); request.sendData.q  =  searchTerm; request.sendAndLoad(); } private  function  parseResults(  event  :  ServiceEvent  )  :  void  { var  tweets  :  TweetCollection  =  parseFeed(  event.data  as  XML  ); dispatchEvent(  new  TweetEvent(  TweetEvent.TWEETS_LOADED,  tweets  )); } }
    36. 36. Tweet Collection public  class  TweetCollection  extends  EventDispatcher  { private  var  _tweets  :  Array; [Bindable(  event="tweetsChanged"  )] public  function  get  tweets()  :  Array  { return  _tweets; } public  function  set  tweets(  value  :  Array  )  :  void  { if  (  value  !=  _tweets  )  { _tweets  =  value; dispatchEvent(  new  Event(  "tweetsChanged"  )  ); } } public  function  assign(  other  :  TweetCollection  )  :  void  { tweets  =  other.tweets; } }
    37. 37. Tweets List public  class  TweetsList  extends  List  { [Inject] public  var  tweetCollection  :  TweetCollection; private  var  tweetsWatcher  :  ChangeWatcher; [PostConstruct] public  function  setUp(  injector  :  Injector  )  :  void  { tweetsWatcher  =  BindingUtils.bindProperty( this,  "dataProvider",  tweetCollection,  "tweets"  ); } }
    38. 38. The Architecture (Twitter Smart Components)
    39. 39. At the component level SearchService SearchButton calls method calls method dispatches event SearchManager updates data TweetList is bound to TweetCollection
    40. 40. It is MVC(S) SearchService SearchButton CONTROLLER SERVICE SearchManager TweetList MODEL VIEW TweetCollection
    41. 41. Traditional Flex MVC View Controller Model Service
    42. 42. Smart Components MVC M M M M M M M M M M V V V V V V V V V V C C C C C C C C C C S S S S S S S S S S Each component is a slice of functionality implemented using MVCS architecture
    43. 43. A component set is • A collection of smart components that work together. • Each component set has a context component for its dependency-injection configuration. • Each component set has an event bus for components to talk to each other.
    44. 44. The application architecture • An application is created in MXML using components from one or more component sets.
    45. 45. Is it new? • The architecture feels new. • Although I gained a lot of ideas from other peoples work.
    46. 46. Is it new? • On reflection, it has a strong similarity to MVC in Smalltalk-80, which is 30 years old! • Although our components are smarter than those in Smalltalk-80.
    47. 47. BrightTALK component Library The BrightTALK component library is • 110 components • 418 classes • 24,650 lines of code Working very well so far. We now build all our projects this way.
    48. 48. New workflow Developer Client Designer
    49. 49. New technologies we could use Since we started, new technologies have emerged. • This architecture would work with Flex 4 components • This architecture could be implemented using Swiz, Robotlegs, or Parsley • We now use Signals instead of Events
    50. 50. That's all folks www.richardlord.net twitter.com/Richard_Lord

    ×