<!-- Copyright (C) 2003 Red Hat, Inc. -->
|
<!-- Copyright (C) 2003 Red Hat, Inc. -->
|
<!-- This material may be distributed only subject to the terms -->
|
<!-- This material may be distributed only subject to the terms -->
|
<!-- and conditions set forth in the Open Publication License, v1.0 -->
|
<!-- and conditions set forth in the Open Publication License, v1.0 -->
|
<!-- or later (the latest version is presently available at -->
|
<!-- or later (the latest version is presently available at -->
|
<!-- http://www.opencontent.org/openpub/). -->
|
<!-- http://www.opencontent.org/openpub/). -->
|
<!-- Distribution of the work or derivative of the work in any -->
|
<!-- Distribution of the work or derivative of the work in any -->
|
<!-- standard (paper) book form is prohibited unless prior -->
|
<!-- standard (paper) book form is prohibited unless prior -->
|
<!-- permission is obtained from the copyright holder. -->
|
<!-- permission is obtained from the copyright holder. -->
|
<HTML
|
<HTML
|
><HEAD
|
><HEAD
|
><TITLE
|
><TITLE
|
>CDL Commands</TITLE
|
>CDL Commands</TITLE
|
><meta name="MSSmartTagsPreventParsing" content="TRUE">
|
><meta name="MSSmartTagsPreventParsing" content="TRUE">
|
<META
|
<META
|
NAME="GENERATOR"
|
NAME="GENERATOR"
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
"><LINK
|
"><LINK
|
REL="HOME"
|
REL="HOME"
|
TITLE="The eCos Component Writer's Guide"
|
TITLE="The eCos Component Writer's Guide"
|
HREF="cdl-guide.html"><LINK
|
HREF="cdl-guide.html"><LINK
|
REL="UP"
|
REL="UP"
|
TITLE="The CDL Language"
|
TITLE="The CDL Language"
|
HREF="language.html"><LINK
|
HREF="language.html"><LINK
|
REL="PREVIOUS"
|
REL="PREVIOUS"
|
TITLE="The CDL Language"
|
TITLE="The CDL Language"
|
HREF="language.html"><LINK
|
HREF="language.html"><LINK
|
REL="NEXT"
|
REL="NEXT"
|
TITLE="CDL Properties"
|
TITLE="CDL Properties"
|
HREF="language.properties.html"></HEAD
|
HREF="language.properties.html"></HEAD
|
><BODY
|
><BODY
|
CLASS="SECT1"
|
CLASS="SECT1"
|
BGCOLOR="#FFFFFF"
|
BGCOLOR="#FFFFFF"
|
TEXT="#000000"
|
TEXT="#000000"
|
LINK="#0000FF"
|
LINK="#0000FF"
|
VLINK="#840084"
|
VLINK="#840084"
|
ALINK="#0000FF"
|
ALINK="#0000FF"
|
><DIV
|
><DIV
|
CLASS="NAVHEADER"
|
CLASS="NAVHEADER"
|
><TABLE
|
><TABLE
|
SUMMARY="Header navigation table"
|
SUMMARY="Header navigation table"
|
WIDTH="100%"
|
WIDTH="100%"
|
BORDER="0"
|
BORDER="0"
|
CELLPADDING="0"
|
CELLPADDING="0"
|
CELLSPACING="0"
|
CELLSPACING="0"
|
><TR
|
><TR
|
><TH
|
><TH
|
COLSPAN="3"
|
COLSPAN="3"
|
ALIGN="center"
|
ALIGN="center"
|
>The <SPAN
|
>The <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>eCos</SPAN
|
>eCos</SPAN
|
> Component Writer's Guide</TH
|
> Component Writer's Guide</TH
|
></TR
|
></TR
|
><TR
|
><TR
|
><TD
|
><TD
|
WIDTH="10%"
|
WIDTH="10%"
|
ALIGN="left"
|
ALIGN="left"
|
VALIGN="bottom"
|
VALIGN="bottom"
|
><A
|
><A
|
HREF="language.html"
|
HREF="language.html"
|
ACCESSKEY="P"
|
ACCESSKEY="P"
|
>Prev</A
|
>Prev</A
|
></TD
|
></TD
|
><TD
|
><TD
|
WIDTH="80%"
|
WIDTH="80%"
|
ALIGN="center"
|
ALIGN="center"
|
VALIGN="bottom"
|
VALIGN="bottom"
|
>Chapter 3. The CDL Language</TD
|
>Chapter 3. The CDL Language</TD
|
><TD
|
><TD
|
WIDTH="10%"
|
WIDTH="10%"
|
ALIGN="right"
|
ALIGN="right"
|
VALIGN="bottom"
|
VALIGN="bottom"
|
><A
|
><A
|
HREF="language.properties.html"
|
HREF="language.properties.html"
|
ACCESSKEY="N"
|
ACCESSKEY="N"
|
>Next</A
|
>Next</A
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><HR
|
><HR
|
ALIGN="LEFT"
|
ALIGN="LEFT"
|
WIDTH="100%"></DIV
|
WIDTH="100%"></DIV
|
><DIV
|
><DIV
|
CLASS="SECT1"
|
CLASS="SECT1"
|
><H1
|
><H1
|
CLASS="SECT1"
|
CLASS="SECT1"
|
><A
|
><A
|
NAME="LANGUAGE.COMMANDS">CDL Commands</H1
|
NAME="LANGUAGE.COMMANDS">CDL Commands</H1
|
><P
|
><P
|
>There are four <SPAN
|
>There are four <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
>-related commands which can occur at the top-level
|
>-related commands which can occur at the top-level
|
of a <SPAN
|
of a <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
> script: <TT
|
> script: <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_package</TT
|
>cdl_package</TT
|
>, <TT
|
>, <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_component</TT
|
>cdl_component</TT
|
>, <TT
|
>, <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_option</TT
|
>cdl_option</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_interface</TT
|
>cdl_interface</TT
|
>. These correspond to the basic building blocks of the
|
>. These correspond to the basic building blocks of the
|
language (CDL interfaces are described in <A
|
language (CDL interfaces are described in <A
|
HREF="language.interface.html"
|
HREF="language.interface.html"
|
>the Section called <I
|
>the Section called <I
|
>Interfaces</I
|
>Interfaces</I
|
></A
|
></A
|
>). All of these take the same basic form:</P
|
>). All of these take the same basic form:</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
>cdl_package <name> {
|
>cdl_package <name> {
|
…
|
…
|
}
|
}
|
|
|
cdl_component <name> {
|
cdl_component <name> {
|
…
|
…
|
}
|
}
|
|
|
cdl_option <name> {
|
cdl_option <name> {
|
…
|
…
|
}
|
}
|
|
|
cdl_interface <name> {
|
cdl_interface <name> {
|
…
|
…
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>The command is followed by a name and by a body of properties, the
|
>The command is followed by a name and by a body of properties, the
|
latter enclosed in braces. Packages and components can contain other
|
latter enclosed in braces. Packages and components can contain other
|
entities, so the <TT
|
entities, so the <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_package</TT
|
>cdl_package</TT
|
> and <TT
|
> and <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_component</TT
|
>cdl_component</TT
|
> can also have
|
> can also have
|
nested commands in their bodies. All names must be unique within a
|
nested commands in their bodies. All names must be unique within a
|
given configuration. If say the C library package and a TCP/IP stack
|
given configuration. If say the C library package and a TCP/IP stack
|
both defined an option with the same name then it would not be
|
both defined an option with the same name then it would not be
|
possible to load both of them into a single configuration. There is a
|
possible to load both of them into a single configuration. There is a
|
<A
|
<A
|
HREF="language.naming.html"
|
HREF="language.naming.html"
|
>naming convention</A
|
>naming convention</A
|
> which should
|
> which should
|
make accidental name clashes very unlikely.</P
|
make accidental name clashes very unlikely.</P
|
><P
|
><P
|
>It is possible for two packages to use the same name if there are no
|
>It is possible for two packages to use the same name if there are no
|
reasonable circumstances under which both packages could be loaded at
|
reasonable circumstances under which both packages could be loaded at
|
the same time. One example would be architectural HAL packages: a
|
the same time. One example would be architectural HAL packages: a
|
given <SPAN
|
given <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>eCos</SPAN
|
>eCos</SPAN
|
> configuration can be used on only one processor, so the
|
> configuration can be used on only one processor, so the
|
architectural HAL packages <TT
|
architectural HAL packages <TT
|
CLASS="VARNAME"
|
CLASS="VARNAME"
|
>CYGPKG_HAL_ARM</TT
|
>CYGPKG_HAL_ARM</TT
|
> and
|
> and
|
<TT
|
<TT
|
CLASS="VARNAME"
|
CLASS="VARNAME"
|
>CYGPKG_HAL_I386</TT
|
>CYGPKG_HAL_I386</TT
|
> can re-use option names; in fact
|
> can re-use option names; in fact
|
in some cases they are expected to.</P
|
in some cases they are expected to.</P
|
><P
|
><P
|
>Each package has one top-level <SPAN
|
>Each package has one top-level <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
> script, which is specified in the
|
> script, which is specified in the
|
packages <A
|
packages <A
|
HREF="language.database.html"
|
HREF="language.database.html"
|
><SPAN
|
><SPAN
|
CLASS="DATABASE"
|
CLASS="DATABASE"
|
>ecos.db</SPAN
|
>ecos.db</SPAN
|
> database
|
> database
|
entry</A
|
entry</A
|
>. Typically the name of this top-level script is related to
|
>. Typically the name of this top-level script is related to
|
the package, so the kernel package uses
|
the package, so the kernel package uses
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>kernel.cdl</TT
|
>kernel.cdl</TT
|
>, but this is just a convention. The
|
>, but this is just a convention. The
|
first command in the top-level script should be <TT
|
first command in the top-level script should be <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_package</TT
|
>cdl_package</TT
|
>, and the
|
>, and the
|
name used should be the same as in the <SPAN
|
name used should be the same as in the <SPAN
|
CLASS="DATABASE"
|
CLASS="DATABASE"
|
>ecos.db</SPAN
|
>ecos.db</SPAN
|
>
|
>
|
database. There should be only one <TT
|
database. There should be only one <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_package</TT
|
>cdl_package</TT
|
> command per package.</P
|
> command per package.</P
|
><P
|
><P
|
>The various <SPAN
|
>The various <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
> entities live in a hierarchy. For example the kernel
|
> entities live in a hierarchy. For example the kernel
|
package contains a scheduling component, a synchronization primitives
|
package contains a scheduling component, a synchronization primitives
|
component, and a number of others. The synchronization component
|
component, and a number of others. The synchronization component
|
contains various options such as whether or not mutex priority
|
contains various options such as whether or not mutex priority
|
inheritance is enabled. There is no upper bound on how far components
|
inheritance is enabled. There is no upper bound on how far components
|
can be nested, but it is rarely necessary to go more than three or
|
can be nested, but it is rarely necessary to go more than three or
|
four levels deeper than the package level. Since the naming convention
|
four levels deeper than the package level. Since the naming convention
|
incorporates bits of the hierarchy, this has the added advantage of
|
incorporates bits of the hierarchy, this has the added advantage of
|
keeping the names down to a more manageable size.</P
|
keeping the names down to a more manageable size.</P
|
><P
|
><P
|
>The hierarchy serves two purposes. It allows options to be controlled
|
>The hierarchy serves two purposes. It allows options to be controlled
|
en masse, so disabling a component automatically disables all the
|
en masse, so disabling a component automatically disables all the
|
options below it in the hierarchy. It also permits a much simpler
|
options below it in the hierarchy. It also permits a much simpler
|
representation of the configuration in the graphical configuration
|
representation of the configuration in the graphical configuration
|
tool, facilitating navigation and modification.</P
|
tool, facilitating navigation and modification.</P
|
><P
|
><P
|
>By default a package is placed at the top-level of the hierarchy, but
|
>By default a package is placed at the top-level of the hierarchy, but
|
it is possible to override this using a <SPAN
|
it is possible to override this using a <SPAN
|
CLASS="PROPERTY"
|
CLASS="PROPERTY"
|
>parent</SPAN
|
>parent</SPAN
|
> property. For example
|
> property. For example
|
an architectural HAL package such as <TT
|
an architectural HAL package such as <TT
|
CLASS="VARNAME"
|
CLASS="VARNAME"
|
>CYGPKG_HAL_SH</TT
|
>CYGPKG_HAL_SH</TT
|
>
|
>
|
typically re-parents itself below <TT
|
typically re-parents itself below <TT
|
CLASS="VARNAME"
|
CLASS="VARNAME"
|
>CYGPKG_HAL</TT
|
>CYGPKG_HAL</TT
|
>, and a
|
>, and a
|
platform HAL package would then re-parent itself below the
|
platform HAL package would then re-parent itself below the
|
architectural HAL. This makes it a little bit easier for users to
|
architectural HAL. This makes it a little bit easier for users to
|
navigate around the hierarchy. Components, options and interfaces can
|
navigate around the hierarchy. Components, options and interfaces can
|
also be re-parented, but this is less common.</P
|
also be re-parented, but this is less common.</P
|
><P
|
><P
|
>All components, options and interfaces that are defined directly in
|
>All components, options and interfaces that are defined directly in
|
the top-level script will be placed below the package in the hierarchy.
|
the top-level script will be placed below the package in the hierarchy.
|
Alternatively they can be nested in the body of the <TT
|
Alternatively they can be nested in the body of the <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_package</TT
|
>cdl_package</TT
|
>
|
>
|
command. The following two script fragments are equivalent:</P
|
command. The following two script fragments are equivalent:</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
>cdl_package CYGPKG_LIBC {
|
>cdl_package CYGPKG_LIBC {
|
…
|
…
|
}
|
}
|
|
|
cdl_component CYGPKG_LIBC_STRING {
|
cdl_component CYGPKG_LIBC_STRING {
|
…
|
…
|
}
|
}
|
|
|
cdl_option CYGPKG_LIBC_CTYPE_INLINES {
|
cdl_option CYGPKG_LIBC_CTYPE_INLINES {
|
…
|
…
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>and:</P
|
>and:</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
>cdl_package CYGPKG_LIBC {
|
>cdl_package CYGPKG_LIBC {
|
…
|
…
|
|
|
cdl_component CYGPKG_LIBC_STRING {
|
cdl_component CYGPKG_LIBC_STRING {
|
…
|
…
|
}
|
}
|
|
|
cdl_option CYGPKG_LIBC_CTYPE_INLINES {
|
cdl_option CYGPKG_LIBC_CTYPE_INLINES {
|
…
|
…
|
}
|
}
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>If a script defines options both inside and outside the body of the
|
>If a script defines options both inside and outside the body of the
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_package</TT
|
>cdl_package</TT
|
> then the ones inside will be processed first. Language
|
> then the ones inside will be processed first. Language
|
purists may argue that it would have been better if all contained
|
purists may argue that it would have been better if all contained
|
options and components had to go into the body, but in practice it is
|
options and components had to go into the body, but in practice it is
|
often convenient to be able to skip this level of nesting and the
|
often convenient to be able to skip this level of nesting and the
|
resulting behavior is still well-defined.</P
|
resulting behavior is still well-defined.</P
|
><P
|
><P
|
>Components can also contain options and other <SPAN
|
>Components can also contain options and other <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
> entities, in fact
|
> entities, in fact
|
that is what distinguishes them from options. These can be defined in
|
that is what distinguishes them from options. These can be defined in
|
the body of the <TT
|
the body of the <TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_component</TT
|
>cdl_component</TT
|
> command:</P
|
> command:</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
>cdl_component CYGPKG_LIBC_STDIO {
|
>cdl_component CYGPKG_LIBC_STDIO {
|
|
|
cdl_component CYGPKG_LIBC_STDIO_FLOATING_POINT {
|
cdl_component CYGPKG_LIBC_STDIO_FLOATING_POINT {
|
…
|
…
|
}
|
}
|
|
|
cdl_option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS {
|
cdl_option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS {
|
…
|
…
|
}
|
}
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>Nesting options inside the bodies of components like this is fine for
|
>Nesting options inside the bodies of components like this is fine for
|
simple packages with only a limited number of configuration options,
|
simple packages with only a limited number of configuration options,
|
but it becomes unsatisfactory as the number of options increases.
|
but it becomes unsatisfactory as the number of options increases.
|
Instead it is possible to split the <SPAN
|
Instead it is possible to split the <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
> data into multiple <SPAN
|
> data into multiple <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
>
|
>
|
scripts, on a per-component basis. The <SPAN
|
scripts, on a per-component basis. The <SPAN
|
CLASS="PROPERTY"
|
CLASS="PROPERTY"
|
>script</SPAN
|
>script</SPAN
|
> property should be
|
> property should be
|
used for this. For example, in the case of the C library all
|
used for this. For example, in the case of the C library all
|
stdio-related configuration options could be put into
|
stdio-related configuration options could be put into
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>stdio.cdl</TT
|
>stdio.cdl</TT
|
>, and the top-level CDL script
|
>, and the top-level CDL script
|
<TT
|
<TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>libc.cdl</TT
|
>libc.cdl</TT
|
> would contain the following:</P
|
> would contain the following:</P
|
><TABLE
|
><TABLE
|
BORDER="5"
|
BORDER="5"
|
BGCOLOR="#E0E0F0"
|
BGCOLOR="#E0E0F0"
|
WIDTH="70%"
|
WIDTH="70%"
|
><TR
|
><TR
|
><TD
|
><TD
|
><PRE
|
><PRE
|
CLASS="PROGRAMLISTING"
|
CLASS="PROGRAMLISTING"
|
>cdl_package CYGPKG_LIBC {
|
>cdl_package CYGPKG_LIBC {
|
…
|
…
|
|
|
cdl_component CYGPKG_LIBC_STDIO {
|
cdl_component CYGPKG_LIBC_STDIO {
|
…
|
…
|
script stdio.cdl
|
script stdio.cdl
|
}
|
}
|
}</PRE
|
}</PRE
|
></TD
|
></TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
><P
|
><P
|
>The <TT
|
>The <TT
|
CLASS="VARNAME"
|
CLASS="VARNAME"
|
>CYGPKG_LIBC_STDIO_FLOATING_POINT</TT
|
>CYGPKG_LIBC_STDIO_FLOATING_POINT</TT
|
> component and
|
> component and
|
the <TT
|
the <TT
|
CLASS="VARNAME"
|
CLASS="VARNAME"
|
>CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS</TT
|
>CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS</TT
|
> option
|
> option
|
can then be placed at the top-level of <TT
|
can then be placed at the top-level of <TT
|
CLASS="FILENAME"
|
CLASS="FILENAME"
|
>stdio.cdl</TT
|
>stdio.cdl</TT
|
>.
|
>.
|
It is possible to have some options nested in the body of a
|
It is possible to have some options nested in the body of a
|
<TT
|
<TT
|
CLASS="LITERAL"
|
CLASS="LITERAL"
|
>cdl_component</TT
|
>cdl_component</TT
|
> command and other options in a separate file accessed
|
> command and other options in a separate file accessed
|
by the <SPAN
|
by the <SPAN
|
CLASS="PROPERTY"
|
CLASS="PROPERTY"
|
>script</SPAN
|
>script</SPAN
|
> property. In such a case the nested options would be
|
> property. In such a case the nested options would be
|
processed first, and then the other script would be read in. A script
|
processed first, and then the other script would be read in. A script
|
specified by a <SPAN
|
specified by a <SPAN
|
CLASS="PROPERTY"
|
CLASS="PROPERTY"
|
>script</SPAN
|
>script</SPAN
|
> property should only define new options,
|
> property should only define new options,
|
components or interfaces: it should not contain any additional
|
components or interfaces: it should not contain any additional
|
properties for the current component.</P
|
properties for the current component.</P
|
><P
|
><P
|
>It is possible for a component's <SPAN
|
>It is possible for a component's <SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
> script to have a sub-component
|
> script to have a sub-component
|
which also has a <SPAN
|
which also has a <SPAN
|
CLASS="PROPERTY"
|
CLASS="PROPERTY"
|
>script</SPAN
|
>script</SPAN
|
> property, and so on. In practice excessive
|
> property, and so on. In practice excessive
|
nesting like this is rarely useful. It is also possible to ignore the
|
nesting like this is rarely useful. It is also possible to ignore the
|
<SPAN
|
<SPAN
|
CLASS="APPLICATION"
|
CLASS="APPLICATION"
|
>CDL</SPAN
|
>CDL</SPAN
|
> language support for constructing hierarchies automatically and
|
> language support for constructing hierarchies automatically and
|
use the <SPAN
|
use the <SPAN
|
CLASS="PROPERTY"
|
CLASS="PROPERTY"
|
>parent</SPAN
|
>parent</SPAN
|
> property explicitly for every single option and
|
> property explicitly for every single option and
|
component. Again this is not generally useful.</P
|
component. Again this is not generally useful.</P
|
><DIV
|
><DIV
|
CLASS="NOTE"
|
CLASS="NOTE"
|
><BLOCKQUOTE
|
><BLOCKQUOTE
|
CLASS="NOTE"
|
CLASS="NOTE"
|
><P
|
><P
|
><B
|
><B
|
>Note: </B
|
>Note: </B
|
>At the time of writing interfaces cannot act as containers. This may
|
>At the time of writing interfaces cannot act as containers. This may
|
change in a future version of the component framework. If the change
|
change in a future version of the component framework. If the change
|
is made then interfaces would support the <SPAN
|
is made then interfaces would support the <SPAN
|
CLASS="PROPERTY"
|
CLASS="PROPERTY"
|
>script</SPAN
|
>script</SPAN
|
> property, just like
|
> property, just like
|
components.</P
|
components.</P
|
></BLOCKQUOTE
|
></BLOCKQUOTE
|
></DIV
|
></DIV
|
></DIV
|
></DIV
|
><DIV
|
><DIV
|
CLASS="NAVFOOTER"
|
CLASS="NAVFOOTER"
|
><HR
|
><HR
|
ALIGN="LEFT"
|
ALIGN="LEFT"
|
WIDTH="100%"><TABLE
|
WIDTH="100%"><TABLE
|
SUMMARY="Footer navigation table"
|
SUMMARY="Footer navigation table"
|
WIDTH="100%"
|
WIDTH="100%"
|
BORDER="0"
|
BORDER="0"
|
CELLPADDING="0"
|
CELLPADDING="0"
|
CELLSPACING="0"
|
CELLSPACING="0"
|
><TR
|
><TR
|
><TD
|
><TD
|
WIDTH="33%"
|
WIDTH="33%"
|
ALIGN="left"
|
ALIGN="left"
|
VALIGN="top"
|
VALIGN="top"
|
><A
|
><A
|
HREF="language.html"
|
HREF="language.html"
|
ACCESSKEY="P"
|
ACCESSKEY="P"
|
>Prev</A
|
>Prev</A
|
></TD
|
></TD
|
><TD
|
><TD
|
WIDTH="34%"
|
WIDTH="34%"
|
ALIGN="center"
|
ALIGN="center"
|
VALIGN="top"
|
VALIGN="top"
|
><A
|
><A
|
HREF="cdl-guide.html"
|
HREF="cdl-guide.html"
|
ACCESSKEY="H"
|
ACCESSKEY="H"
|
>Home</A
|
>Home</A
|
></TD
|
></TD
|
><TD
|
><TD
|
WIDTH="33%"
|
WIDTH="33%"
|
ALIGN="right"
|
ALIGN="right"
|
VALIGN="top"
|
VALIGN="top"
|
><A
|
><A
|
HREF="language.properties.html"
|
HREF="language.properties.html"
|
ACCESSKEY="N"
|
ACCESSKEY="N"
|
>Next</A
|
>Next</A
|
></TD
|
></TD
|
></TR
|
></TR
|
><TR
|
><TR
|
><TD
|
><TD
|
WIDTH="33%"
|
WIDTH="33%"
|
ALIGN="left"
|
ALIGN="left"
|
VALIGN="top"
|
VALIGN="top"
|
>The CDL Language</TD
|
>The CDL Language</TD
|
><TD
|
><TD
|
WIDTH="34%"
|
WIDTH="34%"
|
ALIGN="center"
|
ALIGN="center"
|
VALIGN="top"
|
VALIGN="top"
|
><A
|
><A
|
HREF="language.html"
|
HREF="language.html"
|
ACCESSKEY="U"
|
ACCESSKEY="U"
|
>Up</A
|
>Up</A
|
></TD
|
></TD
|
><TD
|
><TD
|
WIDTH="33%"
|
WIDTH="33%"
|
ALIGN="right"
|
ALIGN="right"
|
VALIGN="top"
|
VALIGN="top"
|
>CDL Properties</TD
|
>CDL Properties</TD
|
></TR
|
></TR
|
></TABLE
|
></TABLE
|
></DIV
|
></DIV
|
></BODY
|
></BODY
|
></HTML
|
></HTML
|
|
|
