Upload
xiaoyan-chen
View
88
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Introduction to Configurator 2.0 architecture design.
Citation preview
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