Flex Widget Layout Framework Specification


Scope
Overview
This component provides a Flex control that manages individual widgets in a grid. The user can drag and drop widgets to reorganize them, as well as close individual widgets, minimize and maximize them, and add widgets to the grid. Each time the layout is updated, the changes are persisted using the Flex Widget Layout Service component. The layout is initially retrieved using that component as well.

The WidgetLayoutControl and WidgetContainer both must be designed using the Flex Code Behind pattern outlined here:

http://www.adobe.com/devnet/flex/quickstart/building_components_using_code_behind/
A prototype showing how the widget layout framework must work is also provided. The functionality for rearranging widgets and minimizing and maximizing must match this prototype. In addition, a sample widget framework can be seen here, with detailed source code:

http://www.adobe.com/devnet/flex/samples/dashboard/dashboard.html

Logic Requirements
Interfaces
All classes and interfaces on the Widget Layout Framework class diagram, in the architecture TCUML provided, are required as part of this component.
WidgetLayoutControl
This control will house the tabs that make up the main part of the widget layout framework, allowing the user to switch between different sets of widgets, with each set in a different tab. This class contains a reference to the WidgetLayoutManager that manages its internals. In the creationCompleteHandler method, it should call “manager.layoutControl=this;” to register the manager properly to control the
widget layout.
WidgetContainer
The WidgetLayoutControl tabs will be filled with WidgetContainer instances. Each WidgetContainer renders a header and footer, with buttons for maximize and close, and will also contain buttons for showing help, and configuration in the future. The WidgetContainer instances each contain an IWidget implementation, from the Flex Widget Base Services component, which represents the internal portion of the widget.
The WidgetContainer will raise WidgetStateChangeEvents when it is dragged, closed, maximized, or restored. The actions should be defined to be unique (“dragStart”, “dragStop”, “minimize”) so they can be processed in WidgetLayoutManager properly. These events will be caught by the WidgetLayoutManager and processed accordingly. In addition, when these events are raised, the methods in IWidget that match the event must also be called. For instance, when the WidgetContainer is closed, the internal
IWidget.close() method must also be called. This class also has a handleWidgetUpdate” method. This method is a callback method for events raised from IWidget instances when their internal state changes. This way the state of the layout will be updated
even if no reorganization is made. This is important, as the widget internals may provide configuration that must be saved when updated. This “handleWidgetUpdate” method should just dispatch the updated event

WidgetLayoutManager
The WidgetLayoutManager performs the actual rearranging and processing of the component. This class contains functionality to reorder widgets, maximize them, restore them to normal size, and close widgets. When a WidgetContainer is moved or a button is pressed, it will raise events that are then processed by the WidgetLayoutManager class. The layout should be managed as shown in the provided prototype. The Adobe sample in the overview has a good example of how the layout can be managed by an external manager class.
WidgetLayoutManager constructor
When the WidgetLayoutManager is initially created, it is given an IWidgetRepository implementation instance, and a layoutService instance. repository should default to “new WidgetRepositoryService()”, and layoutService should default to “new WidgetLayoutService()”. The layout for the current user will be retrieved using the WidgetLayoutService, with the handleLayoutRetrieved method used as the service callback. When the result is retrieved, the layout member variable will be set accordingly.
WidgetLayoutManager initialization
In the setter for the layoutControl property, the “control” member variable will be set to the parameter given, and then “updateLayout” should be called. In “updateLayout”, the widget layout contained in the layout member variable should be applied:
Clear the tabs and contents of the WidgetLayoutControl For each WidgetLayoutTab in the layout
{
Add a new tab to the WidgetLayoutControl that matches the name of the WidgetLayoutTab
For each widget location in the tab
{
Initialize a new WidgetContainer instance
Use the repository member variable to get the IWidget instance based on the location’s widget name
Call IWidget.configure with the value of the WidgetLocation.widgetConfig property.
Set the WidgetContainer.contents property to the value of the IWidget instance created.
Register the WidgetContainer.handleWidgetUpdate method as a listener for the “widgetUpdated” event.
Using the rest of the WidgetLocation properties, add it to the correct location in the layout.
Register the “handle*” methods as handlers for the WidgetContainer events.
}
}
WidgetLayoutManager updates
When the layout is modified through a WidgetContainer being moved, closed, restored, or maximized,
the layout contained in WidgetLayoutManager must be updated appropriately. It is important that the
widgetConfig property of the update WidgetLocation in the layout be updated and saved, using the value
of WidgetContainer.contents.getConfiguration. When the layout member variable is updated to match the
new state of the layout, layoutService.saveWidgetLayout must be called to persist the changes.
Required Algorithms
How the layout happens and how the rearrangement happens when a widget is moved must be
documented in detail.
Example of the Software Usage
This component will be used as a GUI control in the updated TopCoder Cockpit

Future Component Direction
Many widgets will be added that implement the IWidget interface. Also, it may be preferable in the future
to offer new layout algorithms. For instance, instead of the column layout in the prototype, we may want
to provide a layout similar to the Adobe sample linked to in the overview.
Interface Requirements
Software Requirements
Graphical User Interface Requirements
The controls and functionality implemented in this component must match the prototype provided.
External Interfaces
Designs must adhere to the interface diagram definition found in the architecture TCUML file provided.
Changes to the interfaces should be approved in the forum.
Environment Requirements
• Development language: ActionScript3
• Compile target: Flex 3
Package Structure
com.topcoder.flex.widgets.layout.components
com.topcoder.flex.widgets.layout.components.events
com.topcoder.flex.widgets.layout.manager
Software Requirements
Administration Requirements
What elements of the application need to be configurable?
• The URL to the web service
Technical Constraints
Are there particular frameworks or standards that are required?
None
TopCoder Software Component Dependencies:
• Flex Widget Layout Service 1.0
• Flex Widget Base Services 1.0
• Flex Widget Repository Service 1.0
**Please review the TopCoder Software component catalog for existing components that can be used in
the design

http://api.arcwebservices.com/devguide/awx/v4/index_Left.htm#StartTopic=flex/widgets_create.htm#|SkinName=aws

  1. I posted some comments before anyway, because lots of your stuff is really informative.Absolutely amazing man!

    • Ragu
    • February 18th, 2010

    Can any one help me to develop my own widget?

    Looking for help from experts?

    thanks
    ragu

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: