This is just a description of how the core APIs of
ML::AbstractUI might be implemented in OMG IDL.
This document has been written for the Berlin project.
If you do not know what the Berlin project is
and if you do not have any interest in CORBA interfaces,
you are problably in the wrong place.
The design of ML::AbstractUI is described in the
ML::AbstractUI documentation so you will problably need to read that
documentation too - and there's not that much to read.
Also, trying out The Construct for yourself
should make things a lot easier to understand.
The IDL interfaces
For creating user interface controls, an IDL interface with a single factory method should be enough. It is given the name of the control that is to be created. It should problably be implemented as a look and feel server which looks for the appropriate control to create. A proposed IDL interface is given in LFServer.idl.
The 'createControl' method should return a complete implementation of a user interface control with the returned node as the main node for the control and with appropriate parameter nodes connected to it as in ML::AbstractUI. The proposed IDL interface (pseudocode) for such a graph node is given in DGNode.idl.
Each node has a protocol - which in IDL is implemented by inheriting each protocol from the DGNode interface. Here are a few example protocols in IDL pseudocode: PString.idl, PInt.idl and PStrings.idl. Typecasting a node to it's appropriate protocol type is supported natively in CORBA.
The actual user interface object for the node returned by the 'createControl' method above should possibly not be constructed before the node has been connected appropriately to a parent and the boolean protocol of the parameternode called "Create" is set to the value true. Again, this is how it is currently done in ML::AbstractUI.
It should be noted that I already have plans for reducing the protocols in
ML::AbstractUI to just a record of functions and make the implementation
of user interface controls rely only on notifications. This will allow for runtime
hotswapping of look and feels and also make the protocolnodes much more lightweight -
but I'm not sure how to make such a lightweight "record of functions" in IDL.
A restriction like saying that you can't override the methods of the interface and
not change it's implementation would be fine for this.
Relying only on notifications when implementing an IDL interface would also
allow for hotswapping user interface controls without the application ever knowing -
unless it wants to know of course... And I believe that this is what is most desirable.