|
Roger,
That is almost always true -
unless you are treating most of UI as resource bundle. I was merely suggesting
bypass most of recompilation/linkage.
We are going to
publish a chapter on building class libraries from the upcoming book some
time next week. One of the topics is breaking code in layers for large
applications.
Here is rough picture:
You have screen that has rich UI - Grids,
ComboBoxes, etc. Most of those are reusable on other screens (Tom has 50 of them
in his application - roughly 50 apps in generic FlexBuilder sense ). Assuming
average fully linked applications - at least 1000 classes.
Interfaces are going to help a bit on recompiles
and somewhat on the linkage in "classical" model. However, guestimated
recompile/link time is going to be very significant - even is you are changing
single attibute on one shared UI element. We are using following
assumptions:
1. MXML UI contains more "code" then application
and framework, changes often and is not relevant in the application
logic.
2. Framework and application code are using SWC/SWF
extensively and should support breaking the code into reusable common and
"application" specific libraries.
Instead of "linking" controls we
treat all attributes of the UI components as "extended styles"/resources and
compile them separately. in the runtime, the base componenets use the resource
name in the manner similar to "styleName" to apply those compiled resources to
the UI element @ very low cost. Basically, the code is structured in 3
layers:
1. Application
2. Framework
3. Resources
1. Application has simple tag implementation
<framework:ComboBox resource="resource.somecomboboxfromresourceswf" id="c1"
creationComplete="c1.fill(123)"/>
2. Framework roughly does this: function set
resource(resName:String){var c:* = new loadClassByName(resName) for (a in mixin
) this[a] =c[a];
3. Resource is compiled separately and looks
this (base object has the same props as extended framework
combobox):
?xml version="1.0"
encoding="utf-8"?>
<resources:ComboBoxResource xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:resources="resources.*" dataField="EMP_ID" labelFunction="fullName" destination="com_theriabook_composition_EmployeeDAO" method="getEmployees" dropdownWidth="350" > <resources:itemRenderer> <mx:Component verticalGap="0"> <mx:HBox verticalGap="0" horizontalScrollPolicy="off" verticalScrollPolicy="off" > <mx:PhoneFormatter id="phoneFormatter"/> <mx:Label text="{this.data.EMP_LNAME}" width="40%"/><mx:VRule height="20"/> <mx:Label text="{this.data.EMP_FNAME}" width="40%"/><mx:VRule height="20"/> <mx:Label text="{phoneFormatter.format(this.data.PHONE)}" width="20%"/> </mx:HBox> </mx:Component> </resources:itemRenderer> <mx:Script> <![CDATA[ internal function fullName(data:Object):String { return data.EMP_LNAME + "," + data.EMP_FNAME; } ]]> </mx:Script> </resources:ComboBoxResource>
Here is the base class for the resouces.ComboBox
(used instead of interface/provides support for MXML "code
hinting"):
package resources {
import mx.core.IFactory; import flash.util.*; import mx.core.UIComponent; public class ComboBoxResource { public var labelFunction : Function = null; public var destination:String=null; public var method : String = null; public var autoFill : Boolean = true; public var dataField : String = null; public var dropdownWidth : int = 0; public var _mixIn : String = "labelFunction,destination,method,autoFill,itemRenderer,dataField,dropdownWidth" public var itemRenderer:IFactory =
null;
} } This model worked well in the past for both C/C++
(low-level) and PowerBuilder(4GL) languages. Thanks to your advice on RSL/SWF
it works fine in Flex. I would really appreciate opportunity to discuss how
this approach for large applications can be integrated in IDE as I expect this
issue to come up frequently.
Sincerely,
Anatole Tartakovsky
-- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com YAHOO! GROUPS LINKS
|
