Research on Scalable Architecture (V)-an overview of codon

When observingCodons, we have seen that they have some attributes for customization.ProgramThe behavior and status of some elements. Codons has some common attributes (such as ID attributes ). Optional attributes also exist (such as class attributes ). This forms several general attribute categories: Common attributes , Required common attributes , Optional attributes And Required optional attributes . All these attribute categories must be supported.

EveryCodon requires an ID as an identifier on the tree. codon is inserted into the tree, and the extension path is appended with '/' + id. Therefore, ID is a required common (mandatory generic) attribute of all codons. The label attribute of a menu item is a required attribute for the menu item codon. The class attribute may be considered as an optional attribute for the menu item codon, but it is common for a codon to create a class. It is a common attribute.

The menu item codon is a special one among many general concepts of codon. Let's consider an object with more than one instance. We can put them into a set to be extended by others. If such an object is in the form of codon, it will be very valuable. Therefore, we can extend this object without digging into its XML definition.

Note: almost everything can be defined as codon. We can not only define GUI elements and their actions, but also expandAlgorithmOr the behavior of a complex subsystem.

Sort codon

We have such a requirement that menu items must be arranged in some order. This means that the codon of a menu item will be inserted in the middle of menu item X and Y. This is no problem when we only use a single XML definition file (Because XML can define the order and level ). But when we write the definition to different files, the problem arises (in fact, XML definition files of different codon are deployed separately in actual situations ).

Therefore, all codon have common attributes. Insertafter And Insertbefore Such: <Menuitem id = "mymenu" insertafter = "file" label = "mymenu">

This ensures that our menu items can be insertedAfter the File menu.

InsertbeforeAttributeWork Style andThe attributes of insertafter are the same. If more than one codon is specified, use a comma as the name separator. You must specify an ID for the codon you want to insert. ID is the differentiation attribute of a node. Make sure that there are two identical nodes with the same ID on the same layer of a tree, because this will cause the application to throw an exception. Although codon will be a topological classification, remember that there will be more than one legal topological classification. Sometimes when you insert a codon, unexpected results will occur, because it may be inserted somewhere away from where it should have been inserted. "After" does not imply that a correct insertion point is the first possible direct position after the specified point (this applies to before ).

 

Multi-level codon

In the case of menu items, we may have a menu definition with a multi-layer sub-tree in the main menu. In the following example, we use a more concise method to describe this situation:

<Extension path = "/NCVS/workspace/mainmenu">

<Menuitem id = "file" label = "& amp; file"/>

</Extension>

<Extension path = "/NCVS/workspace/mainmenu/file">

<Menuitem id = "separator1" label = "-"/>

<Menuitem id = "exit"

Label = "E & amp; xit"

Class = "NCVS. Gui. commands. exitcommand"/>

</Menuitem>

</Extension> 

Using instead:

<Extension path = "/NCVS/workspace/mainmenu">

<Menuitem id = "file" label = "& amp; file">

<Menuitem id = "separator1" label = "-"/>

<Menuitem id = "exit"

Label = "E & amp; xit"

Class = "NCVS. Gui. commands. exitcommand"/>

</Menuitem>

</Extension>

We can see that the codon of the File menu does not contain sub-menu items. Instead, it serves as the descendant of file codon in the tree structure. This simple method is not mandatory, but we can make the definition more readable.