Join Up! 91369 members and counting!

Login To PHPBuilder User Name: Password: Register A New Site Account * NOTE: This is for logging into the main site only! To login to the forums, click here

PHP Manual All Mail Lists Entire Site

Linux Today Enterprise Linux Today Apache Today JustLinux.com Linux Planet PHPBuilder All Linux Devices Hiermenus DatabaseJournal Technology Jobs IT Developer Internet News Small Business Personal Technology International Search internet.com Advertise Corporate Info Newsletters Tech Jobs E-mail Offers Covalent Extends Apache 2.0 to Microsoft ASP.NET ShopWorX - Support for Windows PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1 Network Risk Assessment Full-Featured, Java-Based Apache GUI Partners & Affiliates Using MySQL's Built-In Replication Creating an Online Survey - Part 2 Getting started with php and InterBase Manually Expiring Web Pages PHP and Regular Expressions 101

Index: phpdoc/README diff -u phpdoc/README:1.25 phpdoc/README:1.26 --- phpdoc/README:1.25 Sun Sep 23 09:52:00 2001 +++ phpdoc/README Sun Sep 30 08:49:38 2001 @@ -12,306 +12,15 @@ HOW TO WRITE PHPDOC FILES If your are interested in information about how to - set up the tools needed and how to work with CVS and - DocBook on Linux and Windows, please refer to the - PHP Documentation HOWTO. You can find it in the howto - directory of the phpdoc module. If you don't know how - to produce HTML files from those XML files there, please - download the howto.html.tar.gz from that directory. + set up the tools needed, how to work with CVS and + DocBook on Linux or Windows, or what conventions you + should follow when writing phpdoc files, please refer + to the PHP Documentation HOWTO. You can find it in + the howto directory of the phpdoc module. If you + don't know how to produce HTML files from those XML + files there, please download the howto.html.tar.gz + from that directory. It can also be downloaded from the web easily: http://cvs.php.net/co.php/phpdoc/howto/howto.html.tar.gz - - The information in this file will also be incorporated - in the PHP Documentation HOWTO. -CONVENTIONS - - 1. Insert ID attributes in all major section tags such - as part, chapter, sect1 etc. The HTML stylesheet will - name the HTML files after these IDs. - - 2. Function reference IDs look like this (case should be consistent - with the rest of the function naming standards, i.e. lowercase): - `function.imageloadfont'. Please note that since underscores - cannot be used in IDs, they should be replaced by minus signs (-). - - 3. Function section IDs () look - like this: 'ref.category', for example: 'ref.ftp'. - - 4. The contents of examples with program listings start on column - 0 in the XML code. - - 5. All examples use the form instead of . - It can be useful to use for examples, since - it eliminates the need to change < to <, etc. - - 6. Indenting, bracketing and naming conventions in examples should - adhere to the PEAR coding standards (it's in the manual). - Deprecated aliases and syntax should not be used in examples. - - 7. If an example uses arguments specific to a newer version of - PHP, it is helpful to note this in the example: - - foo("bar", "baz"); // second argument was added in PHP 4.0.3 - - New arguments are denoted in the main text of the - entry using the form - - - - The second parameter was added in PHP 4.0.3. - - . - - 8. The language constants true, false and null should be written as - &true;, &false; and &null;. - - 9. All English XML files should have a comment as the - first line unless they contain an instead of - void, since the former is the correct - DocBook XML tag. - - If a function has an undefined return-value, use 'void'. - - 14. In a prototype, if there are multiple - really distinct - - possibilities, simply make it two! See math.xml:min() - for an example. - - 15. Aliases: In refpurpose, put: Alias of realfunc. - Do _not_ specify a funcsynopsis, and nothing but simply - the text: This function is an alias of realfunc. - - This way, people can click to realfunc straight from the ref.foo page. - - (*) Better suggestions? I don't really like it this way... not simply - 'function', or something alike? --Jeroen - -WHAT TO DOCUMENT - - 1. Only major functions should be documented; functions which are - deprecated variants may be mentioned, but should not be - documented as separate functions. They instead should be - referenced in the parent function as an alias. Functions which - have completely different names, however, should be documented as - separate entries, for ease of reference. The aliases.xml appendix - is the place to store aliases not documented elsewhere. - - Examples: - mysql_db_name and mysql_dbname will be documented as the same - function, with the latter being listed as an alias of the - former. - - show_source and highlight_file will be documented as two - different functions (one as an alias), as the names are - completely different, and one name is not likely to be found - if looking for the name of the other. - - 2. Function names should be created, and documented, in lower-case - format with an underscore separating the name components. If - there are several variants, use the one with the least amount - of components. - - Good: - 'mcrypt_enc_self_test' - 'mysql_list_fields' - - Ok: - 'mcrypt_module_get_algo_supported_key_sizes' - (could be 'mcrypt_mod_get_algo_sup_key_sizes'?) - 'get_html_translation_table' - (could be 'html_get_trans_table'?) - - Bad: - 'hw_GetObjectByQueryCollObj' - 'pg_setclientencoding' - - 3. Functions which are kept only for backwards compatibility should - be listed under their current parent names, and not documented as - separate functions. Backwards compatible functions and - documentation for them should be maintained as long as the code - can be reasonably kept as part of the PHP codebase. Also see - the appendix aliases.xml. - - 4. Short code examples are much more desirable than long ones. - If a function is extremely complex, a suitable place to put - a longer example is in the chapter introduction. This example - can hold code for other functions in the same chapter. - - 5. Brevity is appreciated. Long winded descriptions of each and - every function are not appropriate for the reference sections. - Using the errata comments as guidelines, it's easier to tell when - more documentation is needed, as well as the inverse, when too - much documentation in one section has increased confusion. - -SKELETONS - - Below are some "skeletons" to copy and paste from when adding - documentation. - -FUNCTION REFERENCE FILE IN functions/: - - - - - - - - -END OF SKELETON - -FUNCTION REFERENCE ENTRY: - - - - - - - - - - - RETURNTYPE FUNCTIONNAME - ARGTYPE1 ARGNAME1 - ARGTYPE2 ARGNAME2 - ARGTYPE3 - ARGNAME3 - - - - - A simple paragraph that can not contain anything that requires - fancy layout. - - - A normal paragraph that can contain lots of stuff. For example - - - - - - - - The text in a paragraph may continue after the example as well. - Here is how to make lists: - - - - - List items must contain a container element such as - simpara or para (there are plenty of others too, see the - DocBook reference for the listitem element. - - - - - - List items must contain simple paragraphs or paragraphs. - - - - - - - - If you plan on making sub-lists, you must use para - - first list item - second list item - You can also continue an ordered list you just left off - - - third list item - fourth list item - - - - - - - - The documentation for a function should be wrapped up with - a "See also" list like this: - - - See also stripslashes and - quotemeta. - - - - -END OF SKELETON - -Originally written by: Stig Bakken email protected>> Index: phpdoc/howto/howto.ent diff -u phpdoc/howto/howto.ent:1.5 phpdoc/howto/howto.ent:1.6 --- phpdoc/howto/howto.ent:1.5 Sun Sep 23 11:00:47 2001 +++ phpdoc/howto/howto.ent Sun Sep 30 08:49:38 2001 @@ -13,10 +13,13 @@ + + + Index: phpdoc/howto/howto.xml diff -u phpdoc/howto/howto.xml:1.6 phpdoc/howto/howto.xml:1.7 --- phpdoc/howto/howto.xml:1.6 Sun Sep 23 11:00:47 2001 +++ phpdoc/howto/howto.xml Sun Sep 30 08:49:38 2001 @@ -14,20 +14,20 @@ - Daniel - Beckham + Stig + Sæther Bakken - (&email.danbeck;) + (&email.stig;) - Stig - Sæther Bakken + Daniel + Beckham - (&email.stig;) + (&email.danbeck;) @@ -68,10 +68,18 @@ This document contains information important for the PHP - Documentation Group members. When this document will be ready, - you will find sections here about generating HTML documentation - from XML sources, adding new XML files, or using XSL style - sheets to process the source files. + Documentation Group members. If you are interested in the + documentation of PHP, you are at the wrong place, see + &url.php.docs; for + downloadable documentation. + + + + Currently this HOWTO is "under construction". When this + document will be ready, you will find sections here about + generating HTML documentation from XML sources, adding + new XML files, or using XSL style sheets to process the + source files. @@ -126,7 +134,7 @@ - All copyrights are held by their by their respective owners, + All copyrights are held by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. @@ -210,7 +218,7 @@ - + What tools you need depends on the operating system you use. @@ -392,7 +400,7 @@ - Although the phpdoc environment is based on many Linux + Although the phpdoc environment is based on many Unix tools and techniques, there are ways to accomplish the same tasks on Windows. It is not too hard to set up a Windows working environment with CVS and the DocBook @@ -406,12 +414,21 @@ You need the same tools as on Linux. The very basic thing is a CVS client. You can find one simple command - line client here at the CVSHome.org + line client here at the CVSHome.org Win32 download pool. We do not recommend GUI tools such as WinCVS, because they can easily screw up the repository with files not intended to be there. The best is to use one command line client. + + + About XML editors, you are encouraged not to use WYSIWYG XML + editors, such as XML Spy, because the often friendly auto-indent, + and optimize features can make the XML files so different from + the one you started the work with, that the diff posted to our + mailing list and used by translators will be useless. Emacs + is also available for Windows if you would like to give it a try ;) + If you want to produce something viewable, or just would @@ -571,7 +588,7 @@ If you didn't get any errors, you're ready to rock&roll. Otherwise, you could check out the installation appendix - of DocBook: The Definitive Guide. + of "DocBook: The Definitive Guide". @@ -615,7 +632,27 @@ Global internal text entities for all the XML files. This is where all the external links, - emial addresses, and "macros" are stored. + email addresses, and "macros" are stored. + + + + + your_language/language-defs.ent + + + Contains local entities used by this language. + Some common ones are the main part titles, but + you should also put entities used only in this + language here. + + + + + your_language/language-snippets.ent + + + Longer often used XML snippets translated to this + language. Including warnings, notes, etc. @@ -627,7 +664,7 @@ - + The PHP documentation is maintained using + + + A CVS system contains a central server, where all the files + are stored. A CVS server can host many repositories, + the name of the repository used by the PHP Documentation + people is phpdoc. To access this + server, you need a CVS client program on your system. + + + + When you decide to work on a file, you need to check + it out (~download the file). Then you can make modifications + on the file on your local copy. If you are ready, you + need to commit the changes (~upload the new file). The CVS + client asks for your short comment about why this commit + was neccesary. You can give here a summary about what was + changed. The CVS server stores the history of files with + these commit messages. Everybody can then see what was + modified by you, because all modifications generate a diff + posted to the phpdoc mailing list, and the history is also + viewable with a CVS client or the web interface at + &url.cvs.php;. You can + also delete a file or add one with your CVS client, + if you see it is needed. + This section is not intended to be a CVS tutorial, only a quick walkthough to help you get started checking out out the - phpdoc tree and commiting your changes. The - complete CVS documentation and can be found at phpdoc tree and commiting your changes. + The complete CVS documentation and can be found at &url.cvs;. - CVS tutorials can be found at: + + CVS tutorials can be found at: &url.cvstut1; @@ -655,18 +718,32 @@ + + + You can also type man cvs anytime + you would like to get help about your CVS client. This + brings up a help text called a "manpage". + - - First, before you can actually make documentation changes, you - need write access to the cvs.php.net CVS repository. You can - always checkout a module anonymously, but you can not commit - changes unless you have an account. + need write access to the cvs.php.net + CVS repository. You can always checkout a module anonymously, + but you can not commit changes unless you have an account. + + + + Also note, that if you have a CVS account on our server, + you may have no write access to the phpdoc + module. The Karma system controls who have access to what + repository, so if you have a CVS account but have no Karma + to write to phpdoc, please ask for Karma + at &email.group.php;. + Note, that who has Karma to write to the PHP source tree, + has Karma to phpdoc as well. @@ -678,11 +755,11 @@ Send mail to &email.group.php;. Explain what you would like to do with the CVS account - (contribute to the PHP documentation). Also give a little + (contribute to the PHP documentation). Also give a little information and background about yourself so the developers understand where you are coming from. - + Once someone from the development team responds to your e-mail, @@ -699,6 +776,8 @@ Both of the above steps and other information about CVS accounts at cvs.php.net can be found on the same page as the request form, &url.cvsaccount.php;. + Note that this it not an automated process. If you receive no + reponse after days, do not hesitate to post your request again. @@ -715,7 +794,8 @@ If you don't already have a .cvsrc file in your home directory, create one now and add the following lines to - it: + it. Note that if you use Cygwin, your home directory opens + first, when running the Bash shell. cvs -z3 @@ -743,10 +823,9 @@ - For sh and bash users add the following to your - .bashrc or .profile - file. + For sh and bash + users add the following to your .bashrc + or .profile file. CVSROOT=:pserver:username <email protected>:/repository @@ -756,9 +835,9 @@ - For csh and tcsh users add the following to your - .cshrc or .tcshrc file. + For csh and tcsh + users add the following to your .cshrc + or .tcshrc file. setenv CVSROOT :pserver:username <email protected>:/repository @@ -772,6 +851,12 @@ won't be set until the next time you log in. + + + If you use Windows, use your regular way to add the new + environment variable, according to the Windows version + you are using. + Now that you have the prep work out of they way, you will need to @@ -784,9 +869,8 @@ - Or, if you don't have your CVSROOT - set, make sure you supply the correct cvsroot: + Or, if you don't have your CVSROOT + set, make sure you supply the correct cvsroot: $ cvs -d :pserver:username <email protected>:/repository login @@ -795,11 +879,12 @@ - You will be asked to supply your password. Once you successfully - login to the CVS respository, your encrypted password is stored in - the .cvspass file in your home directory. - You won't need to log back into the same repository again unless - you delete that file. + Change the username above to your own + CVS user name. You will be asked to supply your password. Once + you successfully login to the CVS respository, your encrypted + password is stored in the .cvspass file + in your home directory. You won't need to log back into the + same repository again unless you delete that file. @@ -809,16 +894,16 @@ Now it's time to checkout the phpdoc - module. Incidently, a module is a collection of source - directories and files. Usually it's simply a directory tree in + module. Incidently, a module is a collection of source + directories and files. Usually it's simply a directory tree in the CVS repository. cd to a directory you wish to store the - phpdoc tree under. Wherever you decide to + phpdoc tree under. Wherever you decide to put it, a phpdoc directory will be created - there. Issue the following command: + there. Issue the following command: $ cvs checkout phpdoc @@ -828,19 +913,19 @@ After some status information about the checkout scrolls by, you - should have a full working copy of the phpdoc module. + should have a full working copy of the phpdoc + module. - It's a good idea from time to time to update your copy of the phpdoc tree so that you always have the - latest copy. Currently, changes to the tree are made daily so you + latest copy. Currently, changes to the tree are made daily so you should always update your copy before making changes yourself. @@ -884,7 +969,7 @@ If you've made several changes to your local copy of - phpdoc and would like to see what files + phpdoc and would like to see what files have been modified, you can ask cvs what the current status of the file or files is. @@ -914,11 +999,12 @@ +$ cvs status -l phpdoc/howto/howto.xml =================================================================== -File: phpdoc.sgml Status: Locally Modified +File: howto.xml Status: Locally Modified - Working revision: 1.3 Fri Aug 25 19:14:08 2000 - Repository revision: 1.3 /cvsroot/howto/phpdoc/phpdoc.sgml,v + Working revision: 1.6 + Repository revision: 1.6 /repository/phpdoc/howto/howto.xml,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) @@ -938,9 +1024,9 @@ When commiting a file or files to the repository, it is polite to - supply an brief message of what you have changed. You do not need + supply an brief message of what you have changed. You do not need to document every single line you changed, that is part of CVS' - job. However, it is helpful to see a brief summary of what has + job. However, it is helpful to see a brief summary of what has changed from version to version without having to study the file itself. @@ -953,14 +1039,19 @@ - + + + Sometimes it is more convinient to ommit the + -m parameter, as this way + CVS opens a text editor and you can type in + your comments there. If you would like to add + more comments, you can't express on one line + using -m, choose this way. + - - - - + @@ -969,18 +1060,18 @@ An important part of making contributions to the PHP documentation is being able to validate your changes and to be able to see what they will look like in their various forms, whether that is in - HTML, Adobe PDF or RTF format. + HTML, Adobe PDF, RTF or other format. - The Makefile controls serveral aspects of how - documenation is validated and created. To generate a + The Makefile controls serveral aspects + of how documenation is validated and created. To generate a Makefile from a fresh checkout, - cd to the phpdoc directory - and issue the following commands: + cd to the phpdoc + directory and issue the following commands: $ autoconf @@ -991,16 +1082,20 @@ This will generate a current Makefile for your copy of the phpdoc tree. - + + + Note that if you are using Windows, these commands + only work in the Cygwin Bash shell. + + - - Now that you have a Makefile, you can validate the documenation - changes you have previously made: + Now that you have a Makefile, you can validate the + documenation changes you have previously made: $ cd phpdoc @@ -1042,41 +1137,58 @@ Using this information, you can go back to the file and correct the mistake before committing your changes. - + + + It is important to do a test before commiting, because if you + commit files with errors, this single file will cause the automatic + build process to halt, and the manual files and downloads + wont be updated online. This can make phpdoc people angry. + - There are several stylesheets available for generating viewable - documenation, the most useful will probably be: + documentation, the most useful will probably be: - html, the plain html manual found at html, the plain html manual found at &url.php.manual.plain; - phpweb, the main PHP online manual found at bightml, one big HTML file, only available for download at &url.php.docdownload; + + + + + phpweb, the main PHP online manual found at &url.php.manual; - pdf, a PDF version of the manual found at pdf, a PDF version of the manual found at &url.php.manual.pdf; - rtf, a RTF (Rich Text Format) version of the manual found at + rtf, a RTF (Rich Text Format) version of the manual found at &url.php.manual.rtf; + + + howto, this HOWTO document in a simple HTML form + &url.php.howto; + + @@ -1087,22 +1199,40 @@ $ make html +$ make bightml $ make phpweb $ make pdf $ make rtf + To make an actual copy of this HOWTO: + + +$ make howto + + + The plain text version of the PHP documentation is made + by filtering the bightml output through lynx. Generating viewable documentation is CPU intensive and can take a - little while to complete. e.g. It takes about 7m 30s on a 700MHz - box I'm using to write this documentation on. + little while to complete. E.g. generating the simple HTML + manual takes about 7m 30s on a 700MHz box. + Where the output files are placed depends on the format you + built. HTML manuals generate in the html + subdirectory of phpdoc, similarly the make phpweb + command will place the files into the php + directory. The place for the HOWTO HTML files is + howto/html. + + + If all goes well, you should have your own copy of the documentation, including any changes you've made. @@ -1117,43 +1247,18 @@ - + If you are used to HTML, DocBook will probably seem pretty tag-verbose to you. DocBook also uses logical tags, it has no (or at least very few) layout-specific tags like HTML is full of. The idea with DocBook is to tell as much as you can about the information while writing it, so that software can do more things with it. - + - Although there are few 1:1 mappings between HTML and DocBook - tags, here is a little list that should at least make life easier - for the HTML proficient: -

- - - - - HTML tag - DocBook tag - - - - - DL - VariableList - - - OL - OrderedList - - - UL - ItemizedList - - - - + We use DocBook, because it eases the generation of the several + formats of the documentation, and acts as a central "meta format" + for all the things we would like to express in the documentation. @@ -1174,12 +1279,10 @@ - - - + - + How to work with emacs, manual.ced, commands, etc. @@ -1251,13 +1354,10 @@ --> - - - - + - + How to work with vi, manual.ced, commands, etc. @@ -1283,24 +1383,402 @@ - + + + - + + When you work on phpdoc XML files, + you should stick to these conventions, to ease the team + work in the repository. + + + + + + Insert ID attributes in all major section tags such + as part, chapter, sect1 etc. The HTML stylesheet will + name the HTML files after these IDs. + + + Function reference IDs look like this (case should + be consistent with the rest of the function naming + standards, i.e. lowercase): function.imageloadfont. + Please note that since underscores cannot be used + in IDs, they should be replaced by minus signs (-). + + + Function section IDs + (<reference id="...">) look + like this: 'ref.category', for example: 'ref.ftp'. + + + The contents of examples with program listings + start on column 0 in the XML code. + + + All examples use the <?php ... ?> + form instead of <? ... ?>. It + can be useful to use <![CDATA[ ... ]]> + for examples, since it eliminates the need to change + < to &lt;, etc. + + + Indenting, bracketing and naming conventions in + examples should adhere to the PEAR coding standards + (it's in the manual). Deprecated aliases and syntax + should not be used in examples. + + + If an example uses arguments specific to a newer version of + PHP, it is helpful to note this in the example: + +foo("bar", "baz"); // second argument was added in PHP 4.0.3 + + New arguments are denoted in the main text of the + entry using the form + + + + The second parameter was added in PHP 4.0.3. + + +]]> + + + + The language constants true, false and null + should be written as &true;, + &false; and + &null;. + + + All English XML files should have a <!-- + $Revision --> comment as the first line + unless they contain an <?xml tag, in which + case the revision comment should be on the second + line. Non-English files should not have this comment. + + + Whitespace changes in the English tree should be + prevented as much as possible: it is more important + to keep a good change-history of real changes, because + of the translations. If a whitespace change is + really needed, do it at least + in a separate commit, with a clear comment such as + 'WS fix' or 'Whitespace fix'. + + + Never use tabs, not even in example program + listings. XML should be indented with one + space character for each level of indentation; + example code uses four spaces (see PEAR standards). + + + Always use LF (Line Feed) for the only newline + character in files, this is the Unix standard. + Never use CR LF (Windows) or CR (Mac) even, when + editing Windows specific files (such as + *.bat). It eases the editing works. + + + + In the docs, the types are denoted as: + boolean (bool + in prototypes), integer + (int in prototypes), + float (not + double!), array, + object (not class!), + resource and null + (all lowercase). + - - + + In prototypes, you can also use mixed + (various types), or number (either + integer or float), or scalar (boolean, + integer, float or string). A callback is denoted as + mixed Better + suggestions? I don't really like it this way... not + simply function, or something alike? + --Jeroen, since it can be either + array or string. + - - Documentation formatting and other examples. + + If a function requires no arguments, use + <void/> instead of + <parameter>void</parameter>, + since the former is the correct DocBook XML tag. + + + + If a function has an undefined return-value, use + the word void. + + + + In a prototype, if there are multiple - really + distinct - possibilities, simply make it two! + See math.xml:min() for an example. + + + Aliases: in refpurpose, put: + Alias of <function>realfunc</function>. + Do not specify a funcsynopsis, and + nothing but simply the text: + This function is an alias of + <function>realfunc</function>. + This way, people can click to realfunc + straight from the ref.foo page. + + + + + + + + + + + + + Only major functions should be documented; functions which are + deprecated variants may be mentioned, but should not be + documented as separate functions. They instead should be + referenced in the parent function as an alias. Functions which + have completely different names, however, should be documented as + separate entries, for ease of reference. The aliases.xml appendix + is the place to store aliases not documented elsewhere. + + + + For example mysql_db_name and + mysql_dbname will be documented as the same + function, with the latter being listed as an alias of the + former, while show_source and + highlight_file will be documented as two + different functions (one as an alias), as the names are + completely different, and one name is not likely to be found + if looking for the name of the other. + + + + + Function names should be created, and documented, in lowercase + format with an underscore separating the name components. If + there are several variants, use the one with the least amount + of components. + + + Good: mcrypt_enc_self_test, + mysql_list_fields + + + OK: mcrypt_module_get_algo_supported_key_sizes + (could be mcrypt_mod_get_algo_sup_key_sizes?), + get_html_translation_table + (could be html_get_trans_table?) + + + Bad: hw_GetObjectByQueryCollObj, + pg_setclientencoding + + + + + Functions which are kept only for backwards compatibility should + be listed under their current parent names, and not documented as + separate functions. Backwards compatible functions and + documentation for them should be maintained as long as the code + can be reasonably kept as part of the PHP codebase. Also see + the appendix aliases.xml. + + + + + Short code examples are much more desirable than long ones. + If a function is extremely complex, a suitable place to put + a longer example is in the chapter introduction. This example + can hold code for other functions in the same chapter. + + + + + Brevity is appreciated. Long winded descriptions of each and + every function are not appropriate for the reference sections. + Using the errata comments as guidelines, it's easier to tell when + more documentation is needed, as well as the inverse, when too + much documentation in one section has increased confusion. + + + + + + + + + + + + Below are some "skeletons" to copy and paste from when adding + documentation. + + + + + + + + + + + +]]> + + + + + + + + + + + + + + + + + + RETURNTYPE FUNCTIONNAME + ARGTYPE1 ARGNAME1 + ARGTYPE2 ARGNAME2 + ARGTYPE3 + ARGNAME3 + + + + + A simple paragraph that can not contain anything that requires + fancy layout. + + + A normal paragraph that can contain lots of stuff. For example + + + +// Use CDATA is you would like to add lots of < to the code + +/* Do all indentation with spaces, not tabs, just to be sure. + * Don't try pushing the code to the right by adding spaces in + * front, this is the style sheet's job. + */ + +// a function example +function some_code($foo) +{ + /* use four spaces of indentation */ +} + +// an example of bracket usage and spacing, always use +// brackets, even when they are physically not needed +if (some_code($foo) == "foo") { + echo "foo"; +} elseif (some_code($foo) == "bar") { + echo "bar"; +} else { + echo "No foo, no bar"; +} + +// Include end of CDATA, if you started with CDATA + + + + The text in a paragraph may continue after the example as well. + Here is how to make lists: + + + + + List items must contain a container element such as + simpara or para (there are plenty of others too, see the + DocBook reference for the listitem element. + + - + + + List items must contain simple paragraphs or paragraphs. + + + + + + + + If you plan on making sub-lists, you must use para + + first list item + second list item + + You can also continue an ordered list you just left off + + third list item + fourth list item + + + + + + + The documentation for a function should be wrapped up with + a "See also" list like this: + + + See also stripslashes and + quotemeta. + + + +]]> + + + + + For technical reasons, the CDATA start tag: <![CDATA[ + and the CDATA end tag: ]]> is not included + in the program code above, just the place of them are marked. + + - + @@ -1312,8 +1790,6 @@ - -

 

Columns / Articles | Tips / Quickies | News | News Linking and RSS Feeds | Shared Code Library Mail Archives | Support / Discussion Forums | Get Started! Links | Contribute! | Docs