When you are in page-edit mode, if you right-click on a
designer's dialog and ask to view the source for the frame... scroll to the
bottom to see all the $create statements... I don't think that spitting the
designer into base and derived will make any difference to the load times... especially when it's all coming from a common webresource.
However... that's all by-the-way I think, as I suspect
it's a no-go anyway.
I did some more work on this, and I actually managed to
get separate 'base' & 'derived' script classes instantiated, but I don’t think it’s a
valid structure and/or solution.
Basically, I fetched descriptors from
base.GetScriptDescriptors() and then modified the descriptor type (so that it
would render a $create referencing my base class) and added a few more
descriptors to it for standard UI components (e.g. my main tabstrip) and common
I then added a 2nd ScriptControlDescriptor for the
derived class, and loaded all of the descriptors unique to that designer (e.g.
all of the unique RadControls I might be using) which rendered the 2nd
$create() referencing the derived designer class.
Both base and derived script classes load as expected,
but then the problems start...
First, there is the issue of initializing the base from
somewhere other than the derived class – which is clearly not logical – and means you
need to cancel the base initializer in the derived class to stop it killing all
the pre-loaded properties.
Second, there is the issue of where and when the
refreshUI() and applyChanges() methods run... base, derived, both ?
The thing ends up in a confused mess and clearly, this is the wrong (probably even invalid)
approach, and bottom line, I don’t think it will work.
So, I’ve returned to my current approach of moving all
common logic and UI handling code into a stand-alone Component script,
instantiate it from the designer, and then call the utility functions as I need them. This allows me to at least reduce the clutter to the minimum possible.
FWIW: I'm simply creating a utility script this way:
// Constructor stuff goes here
// Init stuff goes here
// Dispose stuff goes here
So long as there is a scriptReference loaded for the
utility class, I can just instantiate it as:
var designerUtils = new MyNamespace.MyClass();
or even stuff it into the window object, to make it
available for the page duration.