Xiaoyan Chen

Introduction to Adobe Configurator 2.0 architecture

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

Demo Configurator 2.0 (C2)

3

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

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

The overall picture

6

The baseline of C2 architecture

The“baseline”means:

The guidelines at the very core of the architecture

Unchanged things as the architecture evolves

7

The baseline of C2 architecture

# 1: This is an MVC architecture

# 2: Data driven and transparency over different kinds of “objects”

8

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

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

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

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

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

More on the MVC

5 “layers”

Principles:

UI: thin, stupid

Mediator: simple, parameter adjustment

Command: heavy

Proxy: Simple

VO (model): heavy

14

More on the MVC - UT

15

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

More on the MVC – Undo/Redo

The sequence diagram of pushing a Undoable command into the stack

17

More on the MVC – Undo/Redo

The sequence diagram of undoing a command

18

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

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

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

The evolutions of C2 architecture–integrating DV

22

The evolutions of C2 architecture–integrating DV

The sequence diagram of handling drag drop in design view

23

The evolutions of C2 architecture–integrating DV

The sequence diagram of adding a new object from palette to panel

24

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

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

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

The evolutions of C2 architecture–model evolution

An obvious model evolution caused by PanelLoader

Class diagrams after introducing PanelLoader

28

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

The evolutions of C2 architecture–extensions through Plug-ins

Introduction to the runtime architecture

30

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

The evolutions of C2 architecture–extensions through Plug-ins

Why introducing “extensions through plug-ins”?

How to add the PopupPanelButton widget?

32

The evolutions of C2 architecture–extensions through Plug-ins

Why introducing “extensions through plug-ins”?

Bad: the model classes are not closed.

33

The evolutions of C2 architecture–extensions through Plug-ins

The class diagrams -- Introducing “extensions through plug-ins”

34

The evolutions of C2 architecture–extensions through Plug-ins

Introducing “extensions through plug-ins”

35

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

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

C2 architecture–put all together

The C2 architecture diagram

38

C2 architecture–put all together

The preview sequence diagram

Preview is special in that it combines “design time” and “run time”.

39

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