This document provides an overview of the Adobe Configurator 2.0 (C2) architecture. It describes the key challenges for C2, including supporting many new features. The baseline architecture uses an MVC pattern with data-driven models that provide transparency across different object types. The document outlines the evolutions made to the architecture, such as integrating the design view module and enabling extensions through plugins. Best practices discussed include refactoring to avoid code smells and composing complex logic from simple methods and objects.

1. Xiaoyan Chen
Introduction to Adobe Configurator 2.0 architecture

2. Contents
 Demo Configurator 2.0 (C2)
 Introduction to C2 architecture
 The challenges to C2
 The overall picture
 The baseline of C2 architecture
 More on the MVC
 UT
 Undo/Redo
 The evolutions of C2 architecture
 Integrating DV
 Model evolution
 Extensions through Plug-ins
 C2 architecture–put all together
 The sequence diagrams of preview
 Best practices
2

3. Demo Configurator 2.0 (C2)
3

4. The challenges to C2
 A lot of features
 Features that have big impacts on the architecture:
 Multi lingual panel (high priority feature)
 UI layout capability (high priority feature)
 Multi product support (medium priority feature)
 Flexible requirements from product manager 
 5 new features introduced after pre-release
 Result:
 Feature number: 16
 Loc: 45K (C2) + 12K (UT) + 25K (FB DB)
 Less than 5% of C2 code is legacy code from Configurator 1.0.
4

5. The challenges to C2
 Flexibility
 Add new widgets
 Logic changes in
widgets -- avoid
shotgun surgery
5
Functions
•UI layout
capability
•Multi lingual
panel
•Multi product
support
Non-Function
•Flexibility
•Testability
Constraints
•CSXS
•Point Product

6. The overall picture
6

7. The baseline of C2 architecture
 The“baseline”means:
 The guidelines at the very core of the architecture
 Unchanged things as the architecture evolves
7

8. The baseline of C2 architecture
 # 1: This is an MVC architecture
 # 2: Data driven and transparency over different kinds of
“objects”
8

9. The baseline of C2 architecture
# 1: This is an MVC
architecture
“dispatch events”from UI
to the mediator:
Drag drop a new object into
the panel
Move an object in the panel
Select object(s) in the
outline view
Change the width of object(s)
using the inspector
…
9

10. The baseline of C2 architecture
# 1: This is an MVC
architecture
UI“observe states”from
models:
Get data from models to
populate the inspector
The parent-child relationship
is changed among the models
The attribute values of the
models are changed
…
10

11. The baseline of C2 architecture
# 1: This is an MVC
architecture
Commands:
Execute moving object(s)
Execute changing the
attribute values of the models
Execute copying/pasting
…
Models
Manage data
Provide “command” APIs
to be called by commands
Provide “query”APIs for
UI and notify state
changes to UI
11

12. The baseline of C2 architecture
 # 2: Data driven and transparency over different kinds of
“objects”
 Data driven: bundle and gpc in xml
 Transparency: (considering adding a new type of object)
 The palette can display it without code change.
 The design view can manage it (move, remove, change attributes, etc) without
code change.
 The inspector can manage it (observe and change) without code change.
 The outline view can manage it (observe and select) without code change.
12

13. The baseline of C2 architecture
 # 2: Data driven and transparency over different kinds of
“objects”
 Data driven: bundle and gpc in xml
 Demo bundle and gpc snippets
 Important implication: only one model class for different objects,
which recursively form a tree structure
13

14. More on the MVC
 5 “layers”
 Principles:
 UI: thin, stupid
 Mediator: simple,
parameter adjustment
 Command: heavy
 Proxy: Simple
 VO (model): heavy
14

15. More on the MVC - UT
15

16. More on the MVC – Undo/Redo
 Bridge between PureMVC and an independent undo/redo library
 SimpleUndoCommand.execute() is final, in this method, it pushes itself
into the UndoStack.
 Subclasses of SimpleUndoCommand focus on logics, don’t care UndoStack and
UndoGroup.
 IUndoCommand.canMergeWith(IUndoCommand)
16

17. More on the MVC – Undo/Redo
 The sequence diagram of pushing a Undoable command into the stack
17

18. More on the MVC – Undo/Redo
 The sequence diagram of undoing a command
18

19. The evolutions of C2 architecture–integrating DV
 Integrating the design view (DV) of Flex Builder 3.0
 DV is a module in FB 3.0 implemented in AS (about 25K LOC).
 DV supports MXML editing in a WYSIWYG way.
 DV communicates with the other parts (Java code) of FB via ExternalInterface.
 The architectural decisions involved:
 Implementing the DV functions from scratch in C2 vs.Integrating FB’s DV
 If integrating FB’s DV, how to integrate it?
 Eliminate the statics in DV or not?
19

20. The evolutions of C2 architecture–integrating DV
 The solutions that was taken:
 Make code changes to DV as minimal as possible
 Compile the DV code to a swf representing a separate DV application.
 Simulate what FB does.
20

21. The evolutions of C2 architecture–integrating DV
21
Flex Builder 3.0 C2
Host the DV Use flash player Use a SWFLoader in a
separate
Calls from non-DV part
to DV
Callbacks register via
ExternalInterface
Get the DVFacade (a new
wrapper) and call its
Calls from DV to non-
DV part
ExternalInterface.call Inject an object
(DVCallHandler) into DV
and DV call its APIs
Capture user
interactions (mouse
moves)
Java side captures then
into DV
Use a Canvas covering
SWFLoader to capture the
mouse moves then calls
into DV

22. The evolutions of C2 architecture–integrating DV
22

23. The evolutions of C2 architecture–integrating DV
 The sequence diagram of handling drag drop in design view
23

24. The evolutions of C2 architecture–integrating DV
 The sequence diagram of adding a new object from palette to panel
24

25. The evolutions of C2 architecture–integrating DV
 The sequences:
 UI: Oh, mouse event happens!
 DesignView: Wait, let’s me check what the user wants to do … oh, he/she
wants to move/remove/add/select something.
 UI: Got it, but I can not handle it, I will broadcast an event, who cares who
does!
 Mediator: I know some person who can handle it. Hey, Mr. Command…
 Command: Oh, my god, too work load for me!
 Model: Hello world, I am changed!
 UI: Hi DesignView, Model has been changed, how about you?
 DesignView: OK, I will reflect it.
 Outline: And me, I also need to reflect it.
25

26. The evolutions of C2 architecture–model evolution
 The evolutions of model’s internals are driven by:
 GPC schema evolution: try to make the gpc file more like a mxml file
 Some features
 Remember our baseline #2
26

27. The evolutions of C2 architecture–model evolution
 An obvious model evolution caused by PanelLoader
 Why PanelLoader?
Locale dependent panel layout (contents)
 Class diagrams before introducing PanelLoader
27

28. The evolutions of C2 architecture–model evolution
 An obvious model evolution caused by PanelLoader
 Class diagrams after introducing PanelLoader
28

29. The evolutions of C2 architecture–model evolution
 An obvious model evolution caused by PanelLoader
 Check the baseline #2
 The bundle xml for PanelLoader
<element id="panelLoader"
classDT="com.adobe.configurator2.component.PanelLoaderDesignTime"
classRT="com.adobe.configurator2.component.PanelLoader"
extension="configurator.BaseWidgetExtension">
<attr id="url" editor="URL" validator="stringValidator"
meta="UI_ACCESSOR" name="$$$/Configurator/Attribute/panelLoaderUrl"/>
<attr id="invalidPanelPrompt" inspectable="n" meta="UI_ACCESSOR"/>
</element>
 (Demo)
29

30. The evolutions of C2 architecture–extensions through Plug-
ins
 Introduction to the runtime architecture
30

31. The evolutions of C2 architecture–extensions through Plug-
ins
 Why introducing “extensions through plug-ins”?
 Check the classes for handling events dispatched by HTMLWidget
31

32. The evolutions of C2 architecture–extensions through Plug-
ins
 Why introducing “extensions through plug-ins”?
 How to add the PopupPanelButton widget?
32

33. The evolutions of C2 architecture–extensions through Plug-
ins
 Why introducing “extensions through plug-ins”?
 Bad: the model classes are not closed.
33

34. The evolutions of C2 architecture–extensions through Plug-
ins
 The class diagrams -- Introducing “extensions through plug-ins”
34

35. The evolutions of C2 architecture–extensions through Plug-
ins
 Introducing “extensions through plug-ins”
35

36. The evolutions of C2 architecture–extensions through Plug-
ins
 The bundle xml
<element id="html" classDT="com.adobe.configurator2.component.HTMLDesignTime"
classRT="com.adobe.configurator2.component.HTMLRuntime" extension="configurator.BaseWidgetExtension">
<attr id="htmlText" editor="Text" validator="stringValidator" meta="UI_ACCESSOR" localize="y"
name="$$$/Configurator/Attribute/htmlText"/>
<attr id="location" editor="URL" validator="stringValidator" meta="UI_ACCESSOR" localize="y"
name="$$$/Configurator/Attribute/location"/>
<attr id="homeLocation" editor="URL" validator="stringValidator" meta="UI_ACCESSOR" localize="y"
name="$$$/Configurator/Attribute/homeLocation"/>
<attr id=“htmlevent" inspectable="n" meta="EVENT"/>
</element>
<droppedObjTemplate id="widget_html">
<html htmlevent=“onHtmlEvent”>
<eventListeners>
<function id="onHtmlEvent" handler=“com.adobe.configurator2.handler.HtmlHandler“>
</function>
</eventListeners>
</html>
</droppedObjTemplate>
36

37. The evolutions of C2 architecture–extensions through Plug-
ins
 ToDo:
 Unify all other “simple”widgets (tools, commands, etc) in such plug-in way
(they are core plug-ins), thus making the models not knowing JSGateway.
37

38. C2 architecture–put all together
 The C2 architecture diagram
38

39. C2 architecture–put all together
 The preview sequence diagram
 Preview is special in that it combines “design time” and “run time”.
39

40. Best practices
 No up-front architecture, but loose coupling in mind.
 Keep nose on the code smell, refactor in time.
 Reusing or self-creating?
 Careful evaluation
 Creative reusing
 Partition
 Simple methods compose the complex logic of the object.
 Simple objects compose the complex logic of the application.
 Check your bug fixing: shotgun surgery?
40