Looked in to incorporating KapLab’s Kap Inspect.  It’s a runtime debug tool which lets you look at all existing UIComponents, their current properties, styles, and other items.  Unfortunately it’s written with heavy dependence on Flex 3 and you can’t use it in Flex 4 without making some changes to Flex builder and your sdk directories.  The source is available but very large and I don’t want to spend a week trying to get some cool debug tool to work.

So it turns out Kap Inspect is based on another open source project with a much looser license: FlexSpy.  It has a few less features than Kap Inspect, but works in Flex 4 without any changes and still allows access to styles and properties so I added it to our framework as another debug window.  We may need to hide it when moving to production.

Enter Monkey Patching.  It is apparently possible to inject code in to any existing class by recreating the file in your project, placing it at the same package location, and changing anything inside the file you want.  Your class will the override the Flex library class and any class that extends will inherit your class, not the original one.  Doug Mccune came up with a way to override mx.core.FlexSprite (the base class of all flex components) and add a dictionary which keeps references whenever addEventListener is called.  This allows a debug window to view all event listeners on any component.  So I put together FlexSpy and the monkey patched Flex Sprite to get a very useful new debug window.

Working on a run-time config menu for advanced data grids, this menu will need to include:

• A hierarchical display of columns and a way to edit them since some columns will have multiple sub-columns and why stop there
• A way to ‘roll-up’ data based on one or more columns, this will give the appearance of rows having children rows even though the data will be flat

Started working on the first bullet with a tree / datagrid hybrid:

• Have a tree / datagrid list with existing columns in it and editable headerText fields
• Had a list of available columns and was planning on dragging / dropping from it but after lots of messing around it is apparently not easy to drag and drop from a list of flat data to a list of hierachical data
• decided to simply go with DropDownList and add/remove buttons

Did a quick example of Java to Java AMF as well as did some reading on Deep Linking in flex.

• Working on run-time reconfiguring on widgets starting with the RichTextWidget
• If a user has edit rights, they can mouse over a widget and click on the edit button, it looks very similar to editing a wiki article except the buttons show/hide dynamically
• The configuration page for that widget is brought up (with a nice animation) and the user can make changes then hit finish
• The new configuration is loaded by the widget
• I’ve had to put in a few hacks since I don’t have a data model yet, especially in how I had widget data providers around
• Looking around at cool flex stuff and found this debug util which you build in to your application : http://lab.kapit.fr/display/kapinspect/Kap+Inspect

Made a few architecture and functionality choices for the SWFManager:

• Desktops: A Desktop is exactly as it sounds.  It contains everything one would normally associate with the desktop: a set of applications in windows, a taskbar of some type and anything else added later at this level.  An instance of SWFManager can have multiple Desktops but only one visible at a time and, for now, applications can not be shared between desktops though it would not be impossible to implement.  Communication between desktops will be possible.  In fact, some events may be fired that can span desktops while others are limited to only live within a single desktop.
• Apps: An app is very similar to most applications on a windows machine.  They contain everything needed to run independently but, in this case, will be able to communicate between each other.  Every App is placed on a Desktop within an AppTitleWindow which is an extension of DynamicPanel.  An AppTitleWindow has buttons for minimize, maximize, and close and can be moved and resized around the desktop.  The interface for IApp as it stands now:
  • Get and Set configuration, this is a DataObject that contains all the information the application needs to restore its state
  • Get Icon, this returns an icon that will be used in the task bar and possible in menus elsewhere
  • Validate configuration, this returns a boolean indicating whether or not the provided configuration object is valid
  • Default configuration, takes a config object and defaults all its properties
• Widgets: A Widget is a basic user interface component such as a Chart, Datagrid, RichTextArea, or map with navigation controls.  Widgets live within SOME Apps.  A developer may make a very elaborate App with charts, datagrids, text, maps, and all sorts of things without needing to worry about defining them as Widgets or using our IWidget interface.  However, for some of our internal Apps, it makes sense to make reusable Widgets with certain capabilites.  All Widgets will be added to an App inside of an EditableWidgetContainer which contains controls for accessing Widget options.  The current inteface:
  • Get and Set configuration, this is a DataObject that contains all the information the widget needs to restore its state
  • Validate configuration, this returns a boolean indicating whether or not the provided configuration object is valid
  • Default configuration, takes a config object and defaults all its properties
  • Get Configuration Menu, returns a UIComponent containing whatever inputs are necessary to configure the widget, this is how users will configure their widgets at run-time
• A few notes on Apps and Widgets:
  • Their interfaces are very similar and it would be possible for a component to implement BOTH IApp and IWidget so an App can be contained within an App.  The interfaces are purposely being kept separate so the developer can make that choice.  For example, it makes sense that an RSSReader may exists as both a Widget within a report or as a standalone App.  However, it wouldn’t make sense for Visiblity to be contained within another App.
  • Their positioning and sizing information will not be held within their own configurations.  It will instead be held either in the parent container’s config or the parent container’s layout config.

• IApp, AppTitleWindow, and several applications are already written at this point so I’m now working on EditableWidgetContainer and a few sample widgets: AdvancedDataGrid, RichTextArea, and maybe a chart or 2