LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

<programlistingco/> is only used with areaspec 

the external general entities (files) which were getting pulled in already
contained a <programlisting/> element; this XML element was not necessary, but
the lack of an <areaspec/> inside the <programlistingco/> was giving xmllint
fits.
This commit is contained in:
Martin A. Brown 2016-03-02 21:20:26 -08:00
parent 029b9fef03
commit 45f1b72757
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
LDP/howto/docbook/HighQuality-Apps-HOWTO/HighQuality-Apps-HOWTO.xml
View File

@ -156,7 +156,7 @@
<para>Let's make some exercise with separation using as example a system called <acronym>MySoftware</acronym>, in which the <link linkend="software.body">business logic</link> is in <xref linkend="example.body"/> and the configuration is in <xref linkend="example.soul"/>.</para>
<example id="example.body"><title>A Shell program referring an external configuration file</title>
<programlistingco>
<!-- <programlistingco> -->
&externalconf;
<calloutlist>
<callout arearefs="ex.body.const.c1">
@ -172,17 +172,17 @@
<para>After reading the configuration file, all content directories -- user's + product's -- goes together in the <envar>$CONTENT_PATH</envar>, that will be used from now on.</para>
</callout>
</calloutlist>
</programlistingco>
<!-- </programlistingco> -->
</example>
<example id="example.soul"><title>File containing only the configurations for <acronym>MySoftware</acronym></title>
<programlistingco>
<!-- <programlistingco> -->
&conffile;
<calloutlist>
<callout arearefs="ex.soul.c1 ex.soul.c2 ex.soul.c3">
<para>These are user defined parameters.</para>
</callout>
</calloutlist>
</programlistingco>
<!-- </programlistingco> -->
</example>
</section>
<section id="bodysouls"><title>One Body, Many Souls</title>
@ -531,7 +531,7 @@
<section id="boot.script"><title>Turning Your Software Into a Subsystem</title>
<para>Your Software's files will spread across the filesystems, but you'll want to provide a simple and consistent interface to let the user at least start and stop it. Subsystems architecture promotes this ease-of-use, also providing a way (non obrigatoria) to be automatically started on system initialization. You just have to create your <filename class="directory">/etc/init.d</filename> script following a standard to make it functional.</para>
<example><title>Skeleton of a Subsystem control program in <filename class="directory">/etc/init.d</filename></title>
<programlistingco>
<!-- <programlistingco> -->
&initscript;
<calloutlist>
<callout arearefs="ex.init.chkconfig">
@ -554,7 +554,7 @@
<para>Here you put your Software's specific command.</para>
</callout>
</calloutlist>
</programlistingco>
<!-- </programlistingco> -->
</example>
<para>The <command>mysystem</command> subsystem methods you implemented will be called by users with the <command>service</command> command like this example:</para>
<example><title><command>service</command> command usage</title>