dams Mon Feb 12 07:19:16 2001 EDT
Modified files:
/phpdoc/fr/appendices migration4.xml
Log:
Addind section id's.
Index: phpdoc/fr/appendices/migration4.xml
diff -u phpdoc/fr/appendices/migration4.xml:1.1 phpdoc/fr/appendices/migration4.xml:1.2
--- phpdoc/fr/appendices/migration4.xml:1.1 Tue Jan 23 02:29:47 2001
+++ phpdoc/fr/appendices/migration4.xml Mon Feb 12 07:19:15 2001
@@ -1,280 +1,291 @@
<appendix id="migration4">
<title>Migration de PHP 3.0 à PHP 4.0</title>
- <section>
- <title>What has changed in PHP 4.0</title>
+ <sect1 id="migration4.changes">
+ <title>Ce qui a changŽ en PHP 4.0</title>
<para>
- PHP 4.0 and the integrated Zend engine have greatly inproved PHPs
- performance and capabilities, but great care has been taken to
- break as little existing code as possible. So migrating your code
- from PHP 3.0 to 4.0 should be much easier than migrating from
- PHP/FI 2.0 to PHP 3.0. A lot of existing PHP 3.0 code should be
- ready to run without changes, but you should still know about the
- few differences and take care to test your code before switching
- versions in production environments. The following should give you
- some hints about what to look for.
- </para>
- </section>
- <section>
- <title>Parser behavior</title>
- <para>
- Parsing and execution are now two completely seperated steps, no
- execution of a files code will happen until the complete file and
- everything it requires has completely and successfully been parsed.
- </para>
- <para>
- One of the new requirenments introduced with this split is that
- required and included files now have to be syntactically
- complete. You can no longer spread the different controling parts
- of a control structure across file boundaries. That is you cannot
- start a <literal>for</literal> or <literal>while</literal> loop,
- an <literal>if</literal> statement or a <literal>switch</literal>
- block in one file and have the end of loop,
+ PHP 4.0 et le moteur Zend ont significativement amŽliorŽ les
+ performances et les possibilitŽs de PHP, tout en assurant une
+ compatibilitŽ ascendante maximale. Le maximum de codes existants
+ sous PHP 3.0 fonctionneront sous PHP 4.0. La migration de votre
+ code de PHP 3.0 vers PHP 4.0 sera beaucoup plus facile que
+ celle de PHP/FI 2.0 vers 3.0. Un grand nombre de scripts seront
+ prts sans modifications, mais il est bon que vous connaissiez
+ les quelques diffŽrences, et que vous testiez vos applications
+ avant d'effecteur le changement de cadre de production. Les
+ indications suivantes vous mettront sur la voie.
+ </para>
+ </sect1>
+ <sect1 id="migration4.parser">
+ <title>Comportement de l'analyseur</title>
+ <para>
+ L'analyse et l'Žxecution sont dŽsormais deux Žtapes complŽtement
+ dissociŽes, et l'ŽxŽcution intervient lorsque le code, ainsi que
+ tous ses inclusions et prŽ-requis, ont ŽtŽ
+ complŽtement analysŽ et validŽ.
+ </para>
+ <para>
+ Une des nouvelles conditions introduites est que les fichiers
+ inclus et requis (<function>include</function> et
+ <function>require</function>) doivent tre syntaxiquement
+ complets. Vous ne pouvez plus rŽpartir diffŽrents cas de votre
+ code dans plusieurs fichiers. Vous ne pouvez plus commner une
+ boucle <literal>for</literal> ou <literal>while</literal>,
+ une condition <literal>if</literal> ou un cas <literal>switch</literal>
+ dans un fichier, et finir la boucle ou placer les cas
<literal>else</literal>, <literal>endif</literal>,
- <literal>case</literal> or <literal>break</literal> statements in a
different file.
+ <literal>case</literal> ou <literal>break</literal>
+ dans un autre fichier.
</para>
<para>
- It still perfectly legal to include additional code within loops
- or other control structures, only the controling keywords and
- corresponding curly braces <literal>{...}</literal> have to be
- within the same compile unit (file or <function>eval</function>ed
string).
- </para>
- <para>
- This should not harm to much as spreading code like this should be
- considered as very bad style anyway.
- </para>
- <para>
- Another thing no longer possible, though rarely seen in PHP 3.0
- code is returning values from a required file. Returning a value
- from an included file is still possible.
- </para>
- </section>
- <section>
- <title>Error reporting</title>
- <section>
- <title>Configuration changes</title>
- <para>
- With PHP 3.0 the error reporting level was set as a simple
- numeric value formed by summing up the numbers related to
- different error levels. Usual values where 15 for reporting all
- errors and warnings or 7 for reporting everything but simple
- notice messages reporting bad style and things like that.
- </para>
- <para>
- PHP 4.0 now has a greater set of different error and warning
- levels and comes with a configuration parser that now allows for
- symbolic constants to be used for setting up the intended behavior.
- </para>
- <para>
- Error reporting level should now be configured by explicitly
- taking away the warning levels you do not want to generate error
- messages by x-oring them from the symbolic constant E_ALL. Sounds
- complicated? Well, lets say you want the error reporting system
- to report all but the simple style warnings that are categorized
- by the symbolic constant E_NOTICE. Then you'll put the following
- into your <filename>php.ini</filename>:
- <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>.
- If you wan't to suppress warnings too you add up the appropriate
- constant within the braces using the binary or operator '|':
- <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>.
+ Il est toujours valable d'inclure du code supplŽmentaire depuis
+ une boucle ou dans une conditions, mais les accolades de
+ bloc <literal>{...}</literal>, et les ŽlŽments de la boucle
+ doivent tre dans le mme fichier ou cha”ne ŽvaluŽe avec
+ <function>eval</function>.
+ </para>
+ <para>
+ Cela ne devrait pas perturber trop de monde, car Žtaler son
+ code de cette faon est plut™t un style ˆ Žviter.
+ </para>
+ <para>
+ Une autre nouveautŽ est qu'il est plus possible de faire
+ retourner une valeur avec un fichier requis
+(<function>require</function>)
+ (mais c'est plut™t rare en PHP 3.0). Retourner une valeur
+ avec un fichier inclus (<function>require</function>) est toujours
+ possible.
+ </para>
+ </sect1>
+ <sect1 id="migration4.errors">
+ <title>Rapport d'erreur</title>
+ <sect2 id="migration4.error_reporting">
+ <title>Changement de configuration</title>
+ <para>
+ Avec PHP 3.0, le niveau de rapport d'erreur Žtait obtenu en
+ ajoutant les constantes numŽriques de chaque niveau de
+ rapport. GŽnŽralement, on utilisait 15 pour afficher toutes
+ les erreurs, et 7 pour afficher toutes les erreurs hormis
+ les alertes simples.
+ </para>
+ <para>
+ PHP 4.0 dispose d'un nombre significativement plus grand de niveaux
+ de rapport d'erreur, et l'analyseur comprend dŽsormais les
+ constantes, lors des modifications.
+ </para>
+ <para>
+ Le niveau de rapport d'erreur doit dŽsormais tre explicitement
+ configurŽ en supprimant les niveaux dont vous ne voulez pas
+ du niveau maximal, gr‰ce ˆ la fonction de OU exclusif. Ca a
+ l'air compliquŽ? Supposons que vous souhaitiez afficher toutes les
+ erreurs, hormis les alertes de style, qui sont repŽrŽes par
+ la constante : E_NOTICE. Il suffit d'ajouter la valeur
+ suivante dans le fichier <filename>php.ini</filename>:
+ <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>.
+ Si vous voulez supprimer en plus les alertes, vous pouvez
+ ajouter la constante appropriŽe, en la combinant avec l'opŽrateur
+ OU logique '|':
+ <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>.
</para>
<warning>
<para>
- Using the old values 7 and 15 for setting up error reporting
is a
- very bad idea as this suppresses some of the newly added error
- classes including parese errors. This may leed to very strange
- behavior as scripts might no longer work without error messages
- showing up anywhere.
+ L'utilisation des vieilles valeurs de 7 et 15 est une trs
+ mauvaise idŽe, car elles ne prennent pas en compte les
+ nouvelles classes d'erreurs, y compris certaines erreurs
+ d'analyse. Cela peut conduire ˆ de trs Žtranges rŽsultats,
+ o le script n'affiche plus rien, malgrŽ une erreur d'analyse.
</para>
<para>
- This has lead to a lot of unreproduceable bug reports in the
- past where people reported script engine problems they were not
- capable to track down while the TRUE case was usually some
- missing '}' in a required file that the parser was not able to
- report due to a misconfigured error reporting system.
+ Cela a conduit ˆ un grand nombre de rapport d'erreur dans
+ le passŽ, alors que les programmeurs n'Žtaient tout simplement
+ pas capable de repŽrer l'accolade manquante, car l'analyseur
+ avait la consigne de cacher ces erreurs.
</para>
<para>
- So checking your error reporting setup should be the first
thing
- to do whenever your scripts silently die. The Zend enginge can
- be considererd mature enough nowadays to not cause this kind of
- strange behavior.
+ VŽrifier votre niveau d'erreur doit tre le premier reflexe
+ lorsque vos scripts meurent silencieusement. Le moteur
+ Zend est considŽrŽ actuellement comme suffisament mature pour
+ ne plus causer ce genre de problme aujourd'hui.
</para>
</warning>
- </section>
- <section>
- <title>Additional warning messages</title>
- <para>
- A lot of existing PHP 3.0 code uses language constructs that
- should be considered as very bad style as this code, while doing
- the intended thing now, could easily be broken by changes in
- other places. PHP 4.0 will output a lot of notice messages in
- such situations where PHP 3.0 didn't.
- The easy fix is to just turn off E_NOTICE messages, but it is
- usually a good idea to fix the code instead.
- </para>
- <para>
- The most common case that will now produce notice messages is the
- use of unquoted string constants as array indices. Both PHP 3.0
- and 4.0 will fall back to interprete theese as strings if no
- keyword or constant is known by that name, but whenever a
- constant by that name had been defined anywhere else in the code
- it might break your script. This can even become a security risk
- if some intruder manages to redefine string constants in a way
- that makes your script give him access rights he wasn't intended
- to have. So PHP 4.0 will now warn you whenever you use unquoted
- string constants as for example in
- <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Changing it
- to <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal> will
- make the parser happy and greatly improve the style and security
- of your code.
- </para>
- <para>
- Another thing PHP 4.0 will now tell you about is the use of
- uninitialized variables or array elements.
- </para>
- </section>
- </section>
- <section>
- <title>Initializers</title>
- <para>
- Static variable and class member initializers only accept scalar
- values while in PHP 3.0 they accepted any valid expression.
- This is, once again, due to the split between parsing and
- execution as no code has yet been executed when the parser sees
- the initializer.
- </para>
- <para>
- For classes you should use constructors to initialize member
- variables instead. For static variables anything but a simple
- static value rarely makes sense anyway.
+ </sect2>
+ <sect2 id="migration4.messages">
+ <title>Nouveaux messages d'erreurs</title>
+ <para>
+ Un grand nombre de scripts PHP PHP 3.0 utilisent des structures qui
+ doivent tre considŽrŽes comme un trs mauvais style, mme s'il
+ effectue bien la t‰che qui lui est affectŽe, car ils ne sont pas
+ robustes. PHP 4.0 affichera de nombreux messages d'erreurs dans
+ des situations o PHP 3.0 restera coi.
+ La solution de facilitŽ consiste ˆ supprimer les messages de
+ niveau E_NOTICE, mais c'est une meilleure idŽe de corriger le
+ code ˆ la place.
+ </para>
+ <para>
+ Le cas le plus courant qui gŽnŽrera des messages d'alertes
+ est l'utilisation de constantes sans guillemets comme
+ index de tableaux. PHP 3.0, comme PHP 4.0, finiront par les
+ interprŽter literalement comme des cha”nes, si aucune constante
+ n'est dŽfinie ˆ la place. Mais si jamais une telle constante
+ est dŽfinie dans une autre partie du code, cela risque de
+ produire des rŽsultats Žtonnants. Cela peut devenir un trou
+ de sŽcuritŽ si un pirate arrive ˆ redŽfinir les constantes
+ de telle manire que le script lui donne accs ˆ un niveau
+ de droits supŽrieur. PHP 4.0 vous signalera tout oubli de
+ guillemets comme par exemple dans :
+ <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier
+ ce code e, <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal>
+ rendra l'analyseur heureux, et amŽliorera grandement votre
+ style et la sŽcuritŽ du code.
+ </para>
+ <para>
+ PHP 4.0 vous signalera les variables ou les
+ ŽlŽments de tableaux non initialisŽs.
+ </para>
+ </sect2>
+ </sect1>
+ <sect1 id="migration4.initializers">
+ <title>Initialiseur</title>
+ <para>
+ Les variables statiques et les membres de classes n'acceptent
+ plus que des initialiseurs scalaires, tandis que PHP 3.0 acceptait
+ aussi les expressions. Cela est dž, encore une fois, ˆ la
+ sŽparation de l'analyse et de l'exŽcution : aucun code
+ ne peut tre exŽcutŽ tant que l'analye n'est pas terminŽe.
+ </para>
+ <para>
+ Pour les classes, il vaut mieux initialiser les membres dans
+ le constructeur. Pour les variables static, une valeur fixe
+ et simple est la seule chose qui viennent ˆ l'esprit.
</para>
- </section>
- <section>
+ </sect1>
+ <sect1 id="migration4.empty">
<title><literal>empty("0")</literal></title>
<para>
- The perhaps most cotroversal change in behavior has happend to the
- behavior of the <function>empty</function>. A String containing
- only the character '0' (zero) is now considered empty while it
- wasn't in PHP 3.0.
+ L'Žvolution la plus polŽmique est celle de <function>empty</function>.
+ Une cha”ne contenant seulement le caractre
+ <literal>'0'</literal> (zŽro) est maintenant considŽrŽe comme
+ vide, alors qu'elle ne l'Žtait pas en PHP 3.0.
</para>
<para>
- This new behavior makes sense in web applications, with all input
- fields returning strings even if numeric input is requested, and
- with PHP's capabilities of automatic type conversion.
- But on the other had it might break your code in a rather subtele
- was, leading to misbehavior that is hard to track down if you
- do not know about what to look for.
- </para>
- </section>
- <section>
- <title>Missing functions</title>
- <para>
- While PHP 4.0 comes with a lot of new features, functions and
- extensions, you may still find some functions from version 3.0
- missing. A small number of core functions has vanished because
- they do not work with the new scheme of splitting parsing and
- execution as introduced into 4.0 with the Zend engine.
- Other functions and even complete extensions have become obsolete
- as newer functions and extensions serve the same task better
- and/or in a more general way. Some functions just simply haven't
- been ported yet and finally some functions or extensions may be
- missing due to license conflicts.
- </para>
- <section>
- <title>Functions missing due to conceptual changes</title>
- <para>
- As PHP 4.0 now seperates parsing from execution it is no longer
- possible to change the behavior of the parser (now embedded in
- the Zend engine) at runtime as parsing al already happend by
- then. So the function <function>short_tags</function> has ceased
- to exist. You can still change the parsers behavior by setting
- appropriate values in the <filename>php.ini</filename> file.
- </para>
- <para>
- Another feature from PHP 3.0 that didn't make it into 4.0 is the
- experimental debugging interface as described in ??? in this
- manual.
- A seperate TRUE debuger is promissed to be released as a Zend
- product but hasn't become visible yet.
- </para>
- </section>
- <section>
- <title>Deprecate functions and extensions</title>
- <para>
- The Adabas and Solid database extensions are no more. Long live
- the unified ODBC extension instead.
- </para>
- </section>
- <section>
- <title>Changed status for <function>unset</function></title>
- <para>
- <function>unset</function>, although still available, is
- implemented a literal different in PHP 4.0 so that it no longer
- counts as a 'real' function.
- </para>
- <para>
- This has no direct consequences as
- the behavior of <function>unset</function> didn't change, but
- testing for "unset" usign <function>function_exists</function>
- will return <literal>false</literal> as it would with othern
- lowlevel functions like <function>echo</function>.
- </para>
- <para>
- Another more practical change is that it is no longer possible to
- call <function>unset</function> indirectly, that is
- <literal>$func="unset"; $func($somevar)</literal> won't work anymore.
- </para>
- </section>
- </section>
- <section>
- <title>PHP 3.0 extension</title>
- <para>
- Extensions written for PHP 3.0 will not work with PHP 4.0
- anymore, neither as binaries nor at the source level. It is not to
- difficult to port your extensions to PHP 4.0 if you have access to
- the origibal sources. A detailed description of the actual
- porting process is not part of this text (yet).
- </para>
- </section>
- <section>
- <title>Variable substitution in strings</title>
- <para>
- PHP 4.0 adds a new mechanism to variable substitution in
- strings. You can now finally access object member variables and
- elements from multidimensional arrays within strings.
- </para>
- <para>
- To do so you have to enclose your variables with curly braces
- with the dollar sign immediately following the opening brace:
- <literal>{$...}</literal>
- </para>
- <para>
- To embed the value of an object member variable into a string you
- simply write <literal>"text {$obj->member} text"</literal> while
- in PHP 3.0 you had to use something like <literal>"text
- ".$obj->member." text"</literal>.
- </para>
- <para>
- This should lead to more readable code, while it may break existing
- scripts written for PHP 3.0. But ou can easily check for this kind of
- problem by checking for the character combination
- <literal>{$</literal> in your code and by replacing it with
- <literal>\{$</literal> with your favourite search-and-replace tool.
+ Ce nouveau comportement prend tout son send dans les applications
+ web, puisque tous les rŽsultats de champs de type input est une
+ cha”ne, mme si un nombre est demandŽ, et gr‰ce aux capacitŽs
+ de conversion automatique de PHP. D'un autre cotŽ, cela peut
+ casser votre code d'une manire trs subtile, menant droit au
+ comportement erratique, difficilement repŽrable si vous ne
+ savez pas ce qui vous attend.
+ </para>
+ </sect1>
+ <sect1 id="migration4.missing">
+ <title>Fonctions manquantes</title>
+ <para>
+ Bien que PHP 4.0 dispose de nombreuses nouvelles fonctionnalitŽs
+ fonctions et extensions, vous vous rencontrer des fonctions PHP
+ 3.0 qui manquent. Un petit nombre de fonctions de base n'ont pu
+ tre portŽes en PHP 4.0, maintenant que l'analyse et l'ŽxŽcution
+ ont ŽtŽ sŽparŽes. D'autres fonctions, et mmes des extensions
+ entires sont maintenant obsoltes, remplacŽes par de nouvelles
+ fonctions plus puissantes ou plus efficaces. Certaines fonctions
+ n'ont tout simplement pas ŽtŽ portŽes pour le moment ou pour
+ des raisons de licences.
+ </para>
+ <sect2 id="migration4.impossible">
+ <title>Fonctions manquantes pour des raisons de structure</title>
+ <para>
+ Comme PHP 4.0 sŽpare l'analyse et l'ŽxŽcution, il n'est plus
+ possible de modifier le comportement de l'analyseur (intŽgrŽ
+ dans le moteur Zend) durant l'ŽxŽcution, puisque toute
+ l'analyse a eu lieu, et est terminŽe. La fonction
+ <function>short_tags</function> a cessŽ d'Žxister. Vous pouvez
+ toujours modifier le comportement de l'analyseur avec
+ le fichier <filename>php.ini</filename>.
+ </para>
+ <para>
+ Une autre fonctionnalitŽ qui a disparu est le dŽbuggeur
+ de PHP 3.0, comme dŽcrit dans un autre appendice. Un nouveau
+ dŽbuggeur est promis par Zend, mais il n'a pas encore montrŽ
+ le bout de son nez.
+ </para>
+ </sect2>
+ <sect2 id="migration4.deprecated">
+ <title>Fonctions et extensions obsoltes</title>
+ <para>
+ Les extensions Adabas et Solid n'existent plus. Elle sont intŽgrŽes
+ dans les fonctions ODBC UnifiŽ.
+ </para>
+ </sect2>
+ <sect2 id="migration4.unset">
+ <title>Nouveau statut pour <function>unset</function></title>
+ <para>
+ <function>unset</function>, bient que toujours disponible, a ŽtŽ
+ implŽmentŽ lŽgrement diffŽremment en PHP 4.0, et elle n'est
+ plus vraiment une 'fonction'.
+ </para>
+ <para>
+ Cela n'a pas de consŽquence directe sur le comportement de
+ <function>unset</function>, mais utiliser cette fonction
+ pour faire un test avec <function>function_exists</function>
+ retournera <literal>FALSE</literal> comme il se doit avec
+ les fonction bas niveau comme <function>echo</function>.
+ </para>
+ <para>
+ Une autre application pratique disparue est qu'il n'est plus possible
+ d'appeler <function>unset</function> indirectement, c'est ˆ dire que
+ <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus.
+ </para>
+ </sect2>
+ </sect1>
+ <sect1 id="migration4.extension">
+ <title>Extensions PHP 3.0</title>
+ <para>
+ Les extensions Žcrites pour PHP 3.0 ne fonctionnent plus avec PHP 4.0,
+ ni les exŽcutables, ni les codes sources. Il n'est pas difficile de
+ porter les extensions de PHP 3.0 ˆ 4.0 si vous avez accs aux
+ sources originales. Une description dŽtaillŽe du processus
+ de portage ne fait pas partie de cet appendice (pour le moment).
+ </para>
+ </sect1>
+ <sect1 id="migration4.substitution">
+ <title>Substitution de variables dans les cha”nes</title>
+ <para>
+ PHP 4.0 dispose d'un nouveau mŽcanisme de substitution des
+ variables dans les cha”nes. Vous pouvez dŽsormais accŽder aux
+ membres d'objets et aux tableaux multidimensionnels dans une
+ cha”ne.
+ </para>
+ <para>
+ Pour cela, il suffit de placer la variables entre accolades, le signe
+ $ suivant immŽdiatement la premire accolade :
+ <literal>{$variable['a']}</literal>
+ </para>
+ <para>
+ Pour utiliser la valeur d'un membre d'objet dans une cha”ne,
+ il suffit d'Žcrire : <literal>"text {$obj->member} text"</literal>;
+ alors qu'en PHP 3.0, il fallait faire comme ceci :
+ <literal>"texte".$objet->membre." texte"</literal>.
+ </para>
+ <para>
+ Cette technique rend le code beaucoup plus lisible, mais risque de
+ poser des problmes dans certains scripts PHP 3.0. Vous pouvez
+ facilement traquer ce problme en recherche les sŽquences
+ <literal>{$</literal> dans votre code, et en les remplacant par
+ <literal>\{$</literal> avec votre outil de remplacement habituel.
</para>
- </section>
- <section>
+ </sect1>
+ <sect1 id="migration4.cookies">
<title>Cookies</title>
<para>
- PHP 3.0 hat the bad habbit of setting cookies in the reverse order
- of the <function>setcookie</function> calls in your code. PHP 4.0
- breaks with this habbit and creates the cookie header lines in
- exactly the same order as you set the cookies in the code.
+ PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre
+ inverse de celui du code (l'orde des appels ˆ
+ <function>setcookie</function>). PHP 4.0 rŽtablit l'ordre naturel
+ en les envoyant dans le mme ordre que vous mmes.
</para>
<para>
- This might break some existing code, but the old behaviour was so
- strange to understand that it deserved a change to prevent further
- problems in the future.
+ Cela peut aussi prendre ˆ contre-pied certains programmes, mais
+ ce comportement Žtait tellement Žtrange qu'il mŽritait un tel
+ traitement un jour ou l'autre, pour Žviter d'autres
+ problmes ultŽrieurs.
</para>
- </section>
+ </sect1>
</appendix>
<!-- Keep this comment at the end of the file
Local variables:
