File: basic-syntax.xml

package info (click to toggle)
php-doc 20140201-1
  • links: PTS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 74,084 kB
  • ctags: 4,040
  • sloc: xml: 998,137; php: 20,812; cpp: 500; sh: 177; makefile: 63; awk: 28
file content (289 lines) | stat: -rw-r--r-- 10,505 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision: 332154 $ -->
 <chapter xml:id="language.basic-syntax" xmlns="http://docbook.org/ns/docbook">
  <title>Basic syntax</title>
  <sect1 xml:id="language.basic-syntax.phptags">
   <title>PHP tags</title>
   <para>
    When PHP parses a file, it looks for opening and closing tags,
    which are <literal>&lt;?php</literal> and <literal>?&gt;</literal>
    which tell PHP to start and stop interpreting the code between
    them. Parsing in this manner allows PHP to be embedded in all
    sorts of different documents, as everything outside of a pair
    of opening and closing tags is ignored by the PHP parser.
   </para>
   <para>
     PHP also allows for short open tags <literal>&lt;?</literal> and <literal>?&gt;</literal>
    (which are discouraged because they are only available if enabled with
    <link linkend="ini.short-open-tag">short_open_tag</link> &php.ini; configuration
    file directive, or if PHP was configured with the <option>--enable-short-tags</option>
    option.
   </para>
   <para>
    If a file is pure PHP code, it is preferable to omit the PHP closing tag at the
    end of the file.  This prevents accidental whitespace or new lines being added after the PHP
    closing tag, which may cause unwanted effects because PHP will start output
    buffering when there is no intention from the programmer to send any output
    at that point in the script.
    <informalexample>
     <programlisting role="php">
<![CDATA[
<?php
echo "Hello world";

// ... more code

echo "Last statement";

// the script ends here with no PHP closing tag
]]>
     </programlisting>
    </informalexample>
   </para>
  </sect1>
  <sect1 xml:id="language.basic-syntax.phpmode">
   <title>Escaping from HTML</title>
   <para>
    Everything outside of a pair of opening and closing tags is ignored by the
    PHP parser which allows PHP files to have mixed content.  This allows PHP
    to be embedded in HTML documents, for example to create templates.
    <example>
     <programlisting role="php">
<![CDATA[
<p>This is going to be ignored by PHP and displayed by the browser.</p>
<?php echo 'While this is going to be parsed.'; ?>
<p>This will also be ignored by PHP and displayed by the browser.</p>
]]>
     </programlisting>
    </example>
    This works as expected, because when the PHP interpreter hits the ?&gt; closing
    tags, it simply starts outputting whatever it finds (except for an
    immediately following newline - see
    <link linkend="language.basic-syntax.instruction-separation">instruction separation</link>)
    until it hits another opening tag unless in the middle of a conditional
    statement in which case the interpreter will determine the outcome of the
    conditional before making a decision of what which to skip over.
    See the next example.
   </para>
   <para>
    Using structures with conditions
    <example>
     <title>Advanced escaping using conditions</title>
     <programlisting role="php">
<![CDATA[
<?php if ($expression == true): ?>
  This will show if the expression is true.
<?php else: ?>
  Otherwise this will show.
<?php endif; ?>
]]>
     </programlisting>
    </example>
    In this example PHP will skip the blocks where the condition is not met, even
    though they are outside of the PHP open/close tags, PHP skips them according
    to the condition since the PHP interpreter will jump over blocks contained
    within a condition what is not met.
   </para>
   <para>
    For outputting large blocks of text, dropping out of PHP parsing mode is
    generally more efficient than sending all of the text through
    <function>echo</function> or <function>print</function>.
   </para>
   <para>
    There are four different pairs of opening and closing tags
    which can be used in PHP. Two of those, &lt;?php ?&gt; and
    &lt;script language="php"&gt; &lt;/script&gt;, are always available.
    The other two are short tags and <productname>ASP</productname>
    style tags, and can be turned on and off from the &php.ini;
    configuration file. As such, while some people find short tags
    and <productname>ASP</productname> style tags convenient, they
    are less portable, and generally not recommended.
    <note>
     <para>
      Also note that if you are embedding PHP within XML or XHTML
      you will need to use the &lt;?php ?&gt; tags to remain
      compliant with standards.
     </para>
    </note>
   </para>
   <para>
    <example>
     <title>PHP Opening and Closing Tags</title>
     <programlisting role="php">
<![CDATA[
1.  <?php echo 'if you want to serve XHTML or XML documents, do it like this'; ?>

2.  <script language="php">
        echo 'some editors (like FrontPage) don\'t
              like processing instructions';
    </script>

3.  <? echo 'this is the simplest, an SGML processing instruction'; ?>
    <?= expression ?> This is a shortcut for "<? echo expression ?>"

4.  <% echo 'You may optionally use ASP-style tags'; %>
    <%= $variable; # This is a shortcut for "<% echo . . ." %>
]]>
     </programlisting>
    </example>
   </para>
   <para>
    While the tags seen in examples one and two are both
    always available, example one is the most commonly
    used, and recommended, of the two.
   </para>
   <para>
    Short tags (example three) are only available when they are
    enabled via the <link linkend="ini.short-open-tag">short_open_tag</link>
    &php.ini; configuration file directive, or if PHP was configured
    with the <option>--enable-short-tags</option> option.
   </para>
   <para>
    <productname>ASP</productname> style tags (example four) are only available when
    they are enabled via the <link linkend="ini.asp-tags">asp_tags</link> &php.ini;
    configuration file directive.
   </para>
   <para>
    <note>
     <para>
      Using short tags should be avoided when developing applications
      or libraries that are meant for redistribution, or deployment on
      PHP servers which are not under your control, because short tags
      may not be supported on the target server.  For portable,
      redistributable code, be sure not to use short tags.
     </para>
    </note>
    <note>
     <para>
      In PHP 5.2 and earlier, the parser does not allow the
      <literal>&lt;?php</literal> opening tag to be the only thing in a file.
      This is allowed as of PHP 5.3 provided there are one or more whitespace
      characters after the opening tag.
     </para>
    </note>
    <note>
     <para>
      Starting with PHP 5.4, short echo tag <literal>&lt;?=</literal> is always recognized and
      valid, regardless of the <link linkend="ini.short-open-tag">short_open_tag</link> setting.
     </para>
    </note>
   </para>
  </sect1>
  <sect1 xml:id="language.basic-syntax.instruction-separation">
   <title>Instruction separation</title>
   <para>
    As in C or Perl, PHP requires instructions to be terminated
    with a semicolon at the end of each statement. The closing tag
    of a block of PHP code automatically implies a semicolon; you
    do not need to have a semicolon terminating the last line of a
    PHP block. The closing tag for the block will include the immediately
    trailing newline if one is present.
    <informalexample>
     <programlisting role="php">
<![CDATA[
<?php
    echo 'This is a test';
?>

<?php echo 'This is a test' ?>

<?php echo 'We omitted the last closing tag';
]]>
     </programlisting>
    </informalexample>
    <note>
     <para>
      The closing tag of a PHP block at the end of a file is optional,
      and in some cases omitting it is helpful when using <function>include</function>
      or <function>require</function>, so unwanted whitespace will
      not occur at the end of files, and you will still be able to add
      headers to the response later. It is also handy if you use output
      buffering, and would not like to see added unwanted whitespace
      at the end of the parts generated by the included files.
     </para>
    </note>
   </para>
  </sect1>
  <sect1 xml:id="language.basic-syntax.comments">
   <title>Comments</title>
   <para>
    PHP supports 'C', 'C++' and Unix shell-style (Perl style) comments. For example:

    <informalexample>
     <programlisting role="php">
<![CDATA[
<?php
    echo 'This is a test'; // This is a one-line c++ style comment
    /* This is a multi line comment
       yet another line of comment */
    echo 'This is yet another test';
    echo 'One Final Test'; # This is a one-line shell-style comment
?>
]]>
     </programlisting>
    </informalexample>
   </para>
   <simpara>
    The "one-line" comment styles only comment to the end of
    the line or the current block of PHP code, whichever comes first.
    This means that HTML code after <literal>// ... ?&gt;</literal>
    or <literal># ...  ?&gt;</literal> WILL be printed:
    ?&gt; breaks out of PHP mode and returns to HTML mode, and
    <literal>//</literal> or <literal>#</literal> cannot influence that.
    If the <link linkend="ini.asp-tags">asp_tags</link> configuration directive
    is enabled, it behaves the same with <literal>// %&gt;</literal> and
    <literal># %&gt;</literal>.
    However, the <literal>&lt;/script&gt;</literal> tag doesn't break out of PHP mode in
    a one-line comment.
   </simpara>
   <para>
    <informalexample>
     <programlisting role="php">
<![CDATA[
<h1>This is an <?php # echo 'simple';?> example</h1>
<p>The header above will say 'This is an  example'.</p>
]]>
     </programlisting>
    </informalexample>
   </para>
   <simpara>
    'C' style comments end at the first <literal>*/</literal> encountered.
    Make sure you don't nest 'C' style comments.  It is easy to make this
    mistake if you are trying to comment out a large block of code.
   </simpara>
   <para>
    <informalexample>
     <programlisting role="php">
<![CDATA[
<?php
 /*
    echo 'This is a test'; /* This comment will cause a problem */
 */
?>
]]>
     </programlisting>
    </informalexample>
   </para>
  </sect1>
 </chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->