cvs: peardoc /hu/chapters faq.xml
| From: | Norbert Mocsnik | Date: | Sat, 15 May 2004 01:44:42 +0000 |
| Subject: | cvs: peardoc /hu/chapters faq.xml | ||
| Groups: | php.pear.doc | ||
| Request: | Send a blank email to pear-doc+get-3984@lists.php.net to get a copy of this message | ||
norbert_m Fri May 14 21:44:42 2004 EDT
Added files:
/peardoc/hu/chapters faq.xml
Log:
initial commit
http://cvs.php.net/co.php/peardoc/hu/chapters/faq.xml?r=1.1&p=1 Index: peardoc/hu/chapters/faq.xml +++ peardoc/hu/chapters/faq.xml <?xml version="1.0" encoding="iso-8859-2" ?> <!-- EN-Revision: 1.13 Maintainer: norbert_m Status: ready --> <!-- [norbert_m] translators part won't be translated - they should speak english --> <!-- [mj] The FAQ needs some heavy revision - don't translate it right now --> <chapter id="faq"> <title>GYIK - Gyakran Intézett Kérdések (FAQ)</title> <titleabbrev>GYIK</titleabbrev> <sect1 id="faq.whatis"> <title> Mi a PEAR? </title> <para> Ebben a témában <link linkend="introduction">itt</link> található részletes leírás. </para> </sect1> <sect1 id="faq.contributor"> <title> Hogyan vehetünk részt a PEAR fejlesztésében és/vagy hogyan juthatunk hozzá CVS hozzáféréshez? </title> <titleabbrev> Résztvevõvé válás </titleabbrev> <para> Ebben a témában <link linkend="developers.intro">itt</link> található részletes leírás. </para> </sect1> <sect1 id="faq.c-module"> <title> Készítettem egy PHP modult C nyelven. Milyen szabályokkal kerülhet a PEAR-be? </title> <titleabbrev> C-Modulok </titleabbrev> <simpara> A választ Stig Bakken és Martin Jansen írta. </simpara> <para> Ha egy egyszerû bõvítményt szeretnénk készíteni, ami nem követi a <link linkend="standards">PEAR kódolási szabályokat</link>, helyezzük a pear/PECL/bõvítménynév könyvtárba (ide lesznek átmozgatva a bõvítmények a php-src/ext/extname könyvtárból). Ha a PEAR függvény/osztályelnevezéseit követõ bõvítményt írunk, helyezzük a pear/Foo_Bar könyvtárba (Foo_Bar helyett természetesen használjuk a bõvítmény nevét). </para> </sect1> <!-- <sect1 id="faq.install-pecl"> <title> How do I install a PECL module written in C? </title> <titleabbrev> Installing PECL modules </titleabbrev> <simpara> Answer written by Christian Stocker. </simpara> <simpara> The support for C-extensions in PEAR/PECL is not very sophisticated at the moment. Here's a short description of how to get C-modules running on your system until the PEAR::Installer does that for you. </simpara> <simpara> Download the package from PEAR, then untar it somewhere. Go into the newly built directory and do the following steps: </simpara> <para> <itemizedlist> <listitem> <simpara> phpize </simpara> </listitem> <listitem> <simpara> ./configure </simpara> </listitem> <listitem> <simpara> make </simpara> </listitem> <listitem> <simpara> cp modules/module.so /usr/local/lib/php </simpara> </listitem> </itemizedlist> </para> <simpara> The path, where the module.so is expected, can be different on your system (check <filename>php.ini</filename> and <function>phpinfo</function>). To actually use the module, you have to add it to the extension directive in <filename>php.ini</filename> or to load it with dl("module.so") within your PHP files. </simpara> <simpara> You can compile this extension directly into your PHP binary, too. For this you have to extract the package into <filename>php-src/ext</filename> (in your source directory). After that do also phpize in this new module-directory. But before you can configure your main php-exectuable, you have to do a <filename>./buildconf</filename> on the toplevel of the php-sources. Now you can configure/compile your PHP executable with the new extension, as you would with all other extensions. </simpara> </sect1> --> <sect1 id="faq.separated"> <title> Miért van külön pear/ és php-src/pear/ könyvtár? </title> <titleabbrev> Miért van pear/ és php-src/pear is? </titleabbrev> <simpara> A PEAR elsõ elemei a php-src/pear könyvtárban voltak tárolva, így szállításra kerültek minden egyes PHP disztribúcióval. </simpara> <simpara> A PEAR jelenlegi változatainál ez már nem mûködik, mivel a PEAR túl nagy ahhoz, hogy minden PHP disztribúcióba bekerüljön. Ezért az a döntés született, hogy minden elemet egy pear/ nevû felsõszintû könyvtárban helyezünk el. A többi elem, ami a php-src/pear könyvtárban van, hamarosan átkerül majd ebbe a könyvtárba. Csak a <link linkend="about-pfc">PFC kód</link> és a PEAR csomagmenedzser kódja kerül majd szállításra minden új disztribúcióval automatikusan. </simpara> </sect1> <sect1 id="faq.directory-structure"> <title> Miért tér el egymástól a pear/ és a php-src/pear könyvtárstruktúrája? </title> <titleabbrev> Miért más a pear/ és a php-src/pear? </titleabbrev> <simpara> A választ Stig Bakken írta. </simpara> <para> A php-src/pear/ könyvtár struktúrája megegyezik a telepítést követõ struktúrával (alapértelmezésben <filename>/usr/local/lib/php</filename>), és a benne lévõ fájlok egy egyszerû hierarchiába vannak rendezve. Ugyanakkor a <filename>pear/</filename> könyvtárstruktúrája aszerint épül fel, hogy melyik fájl melyik csomaghoz tartozik. Egyáltalán nem biztos, hogy ezek a fájlok telepítéskor is ilyen struktúrában kerülnek egy adott rendszerre, ezt a csomag leírófájlja határozza meg. </para> </sect1> <sect1 id="faq.flat-structure"> <title> Miért egy egyszerû könyvtárstruktúra egy mély szerkezetû helyett? </title> <titleabbrev> Egyszerû könyvtárstruktúra </titleabbrev> <simpara> A választ Stig Bakken írta. </simpara> <simpara> A CVS-ben a PEAR kódja csomagonként van tárolva, ahelyett, hogy ugyanolyan hierarchiában lenne, amilyenben telepítésre kerül majd. Például, ha az XML_RPC osztályt használni kívánjuk, az "XML/RPC.php" fájlt kell include-olni. Könnyen azt gondolhatjuk, hogy a CVS-ben is ugyanebben a struktúrában helyezkedik el, ám ez nem így van. Az XML_RPC egy független csomag a saját könyvtárával a CVS-ben, ebben az esetben az RPC.php a pear/XML_RPC/RPC.php elérési útvonalon található meg. A csomag leírófájlja (package.xml) határozza meg, hogy a fájlok végül hova kerülnek installálásra. </simpara> <simpara> A CVS-ben azért ilyen struktúrában vannak tárolva a fájlok, mert ez leegyszerûsíti a csomagok adminisztrációját. </simpara> </sect1> <sect1 id="faq.unstable-code"> <title> Bekerülhet a PEAR-be kísérleti / nem stabil kód? </title> <titleabbrev> Instabil kód </titleabbrev> <para> Igen. De gyõzõdjünk meg róla, hogy megjelöljük az experimental vagy unstable státuszt a projekt dokumentációjában. Ennek a legjobb helye a <filename>package.xml</filename> fájl <status> tag-je. A tag lehetséges értékei: <variablelist> <varlistentry> <term>alpha</term> <listitem> <simpara> a fejlesztés korai szakaszaiban, mikor még minden változhat (API, viselkedés) figyelmeztetés nélkül, még sok bug várható </simpara> </listitem> </varlistentry> <varlistentry> <term>beta</term> <listitem> <simpara> Az API alapesetben már nem változik, használható szoftver, de elõfordulhatnak hibák. </simpara> </listitem> </varlistentry> <varlistentry> <term>devel</term> <listitem> <simpara> A többi fejlesztõ számára megjelentetett változat, akik korábban hozzá szeretnének jutni a kódhoz, hogy teszteljék, és visszajelzéseket nyújtsanak, a kód minõsége pre-alpha-tól stable-ig változhat. </simpara> </listitem> </varlistentry> <varlistentry> <term>stable</term> <listitem> <simpara> A szoftver tesztelésre került, az API már le van fixálva, a dokumentáció elkészült, ez az ajánlott verzió a felhasználóknak és éles környezeteknek. </simpara> </listitem> </varlistentry> <varlistentry> <term>snapshot</term> <listitem> <simpara> Egy CVS snapshot egy adott dátumról. </simpara> </listitem> </varlistentry> </variablelist> </para> </sect1> <sect1 id="faq.add-examples"> <title> Szükséges példákat és/vagy tesztfájlokat adnom a csomagomhoz, és hol tároljam õket? </title> <titleabbrev> Példák hozzáadása </titleabbrev> <para> A példák nagyon hasznosak, különösen ha az adott osztálynak komplex API-ja van. De a példák csak részei a dokumentációnak, ne készítsünk példákat dokumentáció helyett. A dokumentációt és a példákat tároljuk a csomag könyvtárán belül egy 'docs' alkönyvtárban. </para> <para> Tesztszkriptek is ajánlottak, ha az osztály fordítást, speciális bõvítményeket/programokat, vagy helyesen installált további fájlokat (pl. sablonok, grafikák) igényel. Tároljuk õket egy 'tests' nevû alkönyvtárban. </para> </sect1> <sect1 id="faq.competitive-packages"> <title> Lehet a PEAR-ben több ugyanolyan funkcionalitással bíró csomag? </title> <titleabbrev> Versenyképes kód </titleabbrev> <simpara> Nincs probléma a hasonló funkcionalitást megvalósító csomagokkal, de nem szeretnénk 10 sablon osztályt, 7 különbözõ levelezéssel kapcsolatos osztályt és 3 különbözõ adatbázisréteget, amelyek ugyanazt végzik, csak más függvénynevekkel. </simpara> <para> Elõször végezzünk egy valóságtesztet: Miért szeretnénk a csomagot viszontlátni a PEAR-ben? Az igazán rossz válaszok: <quote>Hogy viszontlássam a nevem a PEAR-ben</quote> vagy <quote>Nem értettem meg az API-ját egy létezõ osztálynak</quote>. </para> <para> Egy új osztályra jó indok ha hiányzik egy függvény, viselkedés, vagy nem megfelelõ a sebesség egy létezõ implementációban. Ebben az esetben meg kell vizsgálni az adott osztályt, hogy lehetséges-e kibõvíteni igényeinknek megfelelõen. Ha nem, akkor van igazán jó indokunk rá, hogy egy új osztályt javasoljunk. A <quote>ha nem</quote> azt jelenti, hogy nem lehetséges hozzáadni a meglévõ osztályhoz a szükséges funkcionalitást az osztály alapjainak megváltoztatása nélkül. </para> <simpara> Ha új osztályt írunk, próbáljuk meg az API kompatibilitást annyira megõrizni a létezõ osztályokéval, amennyire csak lehet! Ha nem lehetséges az osztály kompatibilitásának a megõrzése, készítsünk egy wrapper osztályt a kompatibilitás megõrzése érdekében. Nem gond, ha ez az osztály sok processzoridõt vagy memóriát igényel, a wrapper osztályok célja a kompatibilitás megõrzése és az új verzióra történõ átállás megkönnyítése. </simpara> <para> Egymással versenyképes osztályokat elõzetesen be kell harangozni a <ulink url="mailto:&email.pear.dev;">PEAR fejlesztõi levelezõlistán</ulink>! </para> </sect1> <sect1 id="faq.question"> <title> Kérdésem van a PEAR-rel kapcsolatban. Hol kérdezhetek? </title> <titleabbrev> Kérdések feltevése </titleabbrev> <para> <itemizedlist> <listitem> <para> Általános kérdéseket a PEAR komponensek használatával kapcsolatban a PEAR általános levelezõlistára küldjünk: <ulink url="mailto:&email.pear.general;">&email.pear.general;</ulink>. </para> </listitem> <listitem> <para> Minden technikai megbeszélés a PEAR fejlesztésével kapcsolatban a PEAR fejlesztõi levelezõlistán zajlik: <ulink url="mailto:&email.pear.dev;">&email.pear.dev;</ulink>. </para> </listitem> <listitem> <para> A weboldallal kapcsolatos kérdéseket a PEAR webmester címére küldhetjük: <ulink url="mailto:&email.pear.webmaster;"> &email.pear.webmaster;</ulink>. </para> </listitem> </itemizedlist> </para> <para> A levelezõlistákra történõ feliratkozással kapcsolatos információkat <ulink url="&url.pear.support;">itt</ulink> találjuk. </para> <para> Minden fent említett levelezõlista nyelve az angol, és mindig legyünk udvariasak :-). </para> </sect1> <sect1 id="faq.require"> <title> Egy általam használt csomag include-ol egy csomagot, amire az én csomagomnak is szüksége van. Include-oljam ismét? </title> <para> Igen. Include-oljunk minden csomagot, amire szükségünk van a <function>require_once</function> vagy az <function>include_once</function> utasításokkal, még akkor is, ha egy általunk használt csomag már include-olja. </para> </sect1> <sect1 id="faq.windows"> <title> Mûködik a PEAR Windows alatt? </title> <titleabbrev> PEAR & Windows </titleabbrev> <para> A PEAR életre keltéséhez Windows alatt egyszerûen adjuk hozzá a PEAR telepítési könyvtárát (pl. <filename>c:\php\pear</filename>) az include_path direktívához a <filename>php.ini</filename> fájlban. </para> <simpara> Megjegyzés: Van néhány osztály (például Schedule/At.php), ami nem mûködik Windows alatt, mivel *nix specifikus parancsokat tartalmaznak. </simpara> </sect1> <sect1 id="faq.licenses"> <title> Milyen licenszek engedélyezettek a PEAR/PECL-ben? </title> <titleabbrev> Engedélyezett licenszek </titleabbrev> <simpara> A választ Jan Lehnardt, Tomas V.V. Cox és Rasmus Lerdorf írta. </simpara> <para> Jelenleg a PEAR a következõ licenszeket engedélyezi: </para> <itemizedlist> <listitem> <simpara> PHP Licensz </simpara> </listitem> <listitem> <simpara> Apache Licensz </simpara> </listitem> <listitem> <simpara> LGPL </simpara> </listitem> <listitem> <simpara> BSD stílusú licensz </simpara> </listitem> </itemizedlist> <para> További licenszek is elképzelhetõk, egyedi elbírálás alapján. Ilyen esetben lépjünk kapcsolatba a <ulink url="mailto:&email.pear.dev;">PEAR fejlesztõi levelezõlistával</ulink>! </para> <para> A PHP-be linkelt PECL bõvítmények esetében a licensznek kompatibilisnek kell lennie a PHP licensszel. Ez azt jelenti, hogy nem lehet egy PECL bõvítmény licensze GPL, mert megsértenénk a GPL-t. Ne felejtsük el, hogy amennyiben egy olyan bõvítményt írunk, amibe egy GPL-es könyvtár van belinkelve, szintén megsértjük a GPL-t. Ha egy ilyen könyvtárat szeretnénk linkelni, kérjük a könyvtár szerzõjének hozzájárulását. </para> <para> A PEAR/PECL csomag licenszének beállításához helyezzük el azt minden forrásnyelvi fájl fejlécében, és írjuk bele a csomagleíró fájl (<filename>package.xml</filename>) <license> tag-jébe! </para> </sect1> <sect1 id="faq.tabs-vs-spaces"> <title> Miért alapulnak a PEAR kódolási szabályok szóközök használatán TAB-ok helyett? </title> <titleabbrev> Tabok vs. Szóközök </titleabbrev> <simpara> A választ Stig Bakken írta. </simpara> <para> A szóközök használata és a tabok használatának mellõzése az egyetlen módja annak, hogy bizonyosan legyünk benne, hogy egy-egy kódrészlet minden szövegszerkesztõben ugyanúgy jelenik meg. Sok szövegszerkesztõ a tabokat 4 szóközként jeleníti meg, és sok másik szerkesztõ vagy terminál program 8 szóközként. Például: <literallayout><![CDATA[printf("%s", $arg);]]></literallayout> Itt 7 szóköz áll a "$arg" elõtt. Ha ezt a kódot egy, a tabot 4 szóközzel helyettesítõ szövegszerkesztõvel írtuk volna meg, egy tabként és három darab szóközként tárolná el. Ha most egy másik fejlesztõ megnyitja ugyanezt a fájlt egy 8-szóközt behelyettesítõ szövegszerkesztõben, akkor az így festene: <literallayout><![CDATA[printf("%s", $arg);]]></literallayout> </para> <para> Hasonlóképpen ez a kód 8-szóközt behelyettesítõ szoftver esetén: <literallayout><![CDATA[ if ($foo && $bar) { }]]></literallayout> Egy 4-szóközt alkalmazó szoftverben megtekinteve így nézne ki: <literallayout><![CDATA[ if ($foo && $bar) { }]]></literallayout> </para> <simpara> A PEAR-hez hasonló közösségekben, ahol a fejlesztõk rengeteg különbözõ rendszert és szövegszerkesztõt használnak, a tabok használata egyszerûen nem mûködik. Egy idõ után a fejlesztési idõ nagy része arra menne el, hogy a fejlesztõk a szóközöket tabokra cserélgetik és fordítva. Ha mindenki csak szóközt használ, minden rendszeren ugyanolyan az eredmény. </simpara> <para> Jamie Zawinski is <ulink url="&url.tabs.vs.spaces;">írt</ulink> a témában. </para> <para> Ezenkívül létezik egy <ulink url="&url.astyle;">Astyle</ulink> nevû eszköz is, amely segít a más stílusban megírt kódot a kívánt formátumra konvertálni. </para> </sect1> <sect1 id="faq.translators-revision-tracking"> <title> Is there a tool to help PEAR manual translators to track files changes? </title> <titleabbrev> Revision Tracking </titleabbrev> <para> Working on the translations is not just translating an English file and commiting the results. Much of the work is needed to update the already translated ones, to get in sync with the content of the English files. To follow the modifications in the English tree, you should <ulink url="mailto:&email.pear.doc-subscribe;">subscribe to the PEAR documentation mailing list</ulink> to get CVS commit messages, or read the archives. If you never update your files, the translations can get useless. </para> <simpara> Updating a foreign language file can get difficult, as you may not know when and who translated that file, so you may not know where you should look for the updates needed. We have one system for tracking the revisions and modification dates of the files in <literal>peardoc</literal>. </simpara> <sect2 id="faq.translators.revcheck-comments"> <title>The Revision Comments</title> <para> Instead of storing all responsibilities in a central file, the revision comment system stores them in the files they provide information about. Information about translator, revision numbers, and status information is stored in the revision comment. Let's see what would be in the header of the example file <filename>bookinfo.xml</filename> file in this case: <programlisting> <!-- EN-Revision: 1.16 Maintainer: jane Status: ready --> </programlisting> </para> <para> We can see the revision number for the last english file used to update the translation (EN-Revision: 1.16), the translator cvs account name. But we can also add some other status information in the case it is needed (eg. "partial" for incomplete translations). This revision comment system is basically about storing the information in the XML files, and not in a central place. This is extremely convenient now, as there are more than 1300 files in the English tree. </para> <para> Currently, all three fields (English revision, Maintainer, Status) are needed. Maintainer is intended to be a CVS user name, or some nickname without a space, status can be anything without a space. Note, that this header is not updated by CVS (in contrast with <literal>$Revision</literal>, which is updated automatically). This is only updated when you edit the contents of the comment yourself. </para> <para> You may see this as a good thing, but using these comments, you lose the quick look on the whole list of your files. No, you do not lose this, but get much more! If you would like to build a full list of you files, you can go to the /peardoc/ directory and run: <programlisting> /scripts/revcheck_pear.php xx > revcheck.html </programlisting> Here <literal>xx</literal> is the imaginary language code. After running this script you'll get a <filename>revcheck.html</filename> in the same directory. You can find revision comparisions and links to diffs for all the files in this language. You can also add a further restriction parameter, the maintainer name, so the script will only list the files corresponding to the given maintainer. </para> <para> There are some optional extensions introduced for this script, to be available in this generated HTML page. This is why the <filename>translation.xml</filename> files are introduced. Here comes a simple <filename>translation.xml</filename> file for the imaginary xx language : <programlisting> <![CDATA[ <?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE translation SYSTEM "../dtds/translation.dtd"> <translation> <intro> This is some introductory text for the xx language translators about who is the manager of the translation, and where to find more information. This paragraph is printed on the top of the generated revcheck.html page. </intro> <translators> <person name="Joe Doe" email="joe@hotmail.com" nick="joedoe" cvs="yes" editor="yes"/> <person name="Jane Smith" email="jsmith@yahoo.com" nick="jane" cvs="yes"/> <person name="Joe Forever" email="joe@forever.net" nick="joefo" cvs="no"/> </translators> <work-in-progress> <file name="appendices/aliases.xml" person="joedoe" type="working"/> <file name="functions/dbx.xml" person="joefo" type="working"/> </work-in-progress> </translation> ]]> </programlisting> In this file, you can add users without a CVS account, and can assign ready documents or work-in-progress files to them. The biggest advantage of using this addon is that all this information is used to generate dynamic tables of translators and files in the <filename>revcheck.html</filename> file. All translators are linked to from the individual files they are assigned to, and there is a nice table showing the state of files for all the translators. Assigning ready files may be needed if a time consuming update is in progress on that file. </para> <para> There are two optional parameters you can add to a <file>, if you would like to record it: the <literal>date</literal> and <literal>revision</literal>. Date is assumed to be the date when the work was started, revision is the checked out revision of the English file used to start the work (denoted as CO-Revision in the generated table). There is currently no fixed format for the <literal>date</literal> parameter. </para> <para> Another addon to this system is just to give credit to all people who worked on one file, and not just the current maintainer. To achieve this goal, we added the credit comments. One credit comment in eg. <filename>history.xml</filename> may look like this (in case Joe Doe translated the file initially, but Jane followed him to be the maintainer): <programlisting> <!-- CREDITS: joedoe --> </programlisting> The credits comment can contain a comma-separated list. These comments only affect the display of the translators table in <filename>revcheck.html</filename>. </para> </sect2> </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 sgml-parent-document:nil sgml-default-dtd-file:"../../manual.ced" sgml-exposed-tags:nil sgml-local-catalogs:nil sgml-local-ecat-files:nil sgml-namecase-general:t sgml-general-insert-case:lower End: vim600: syn=xml fen fdm=syntax fdl=2 si vim: et tw=78 syn=sgml vi: ts=1 sw=1 -->
http://cvs.php.net/co.php/peardoc/hu/chapters/faq.xml?r=1.1&p=1 Index: peardoc/hu/chapters/faq.xml +++ peardoc/hu/chapters/faq.xml <?xml version="1.0" encoding="iso-8859-2" ?> <!-- EN-Revision: 1.13 Maintainer: norbert_m Status: ready --> <!-- [norbert_m] translators part won't be translated - they should speak english --> <!-- [mj] The FAQ needs some heavy revision - don't translate it right now --> <chapter id="faq"> <title>GYIK - Gyakran Intézett Kérdések (FAQ)</title> <titleabbrev>GYIK</titleabbrev> <sect1 id="faq.whatis"> <title> Mi a PEAR? </title> <para> Ebben a témában <link linkend="introduction">itt</link> található részletes leírás. </para> </sect1> <sect1 id="faq.contributor"> <title> Hogyan vehetünk részt a PEAR fejlesztésében és/vagy hogyan juthatunk hozzá CVS hozzáféréshez? </title> <titleabbrev> Résztvevõvé válás </titleabbrev> <para> Ebben a témában <link linkend="developers.intro">itt</link> található részletes leírás. </para> </sect1> <sect1 id="faq.c-module"> <title> Készítettem egy PHP modult C nyelven. Milyen szabályokkal kerülhet a PEAR-be? </title> <titleabbrev> C-Modulok </titleabbrev> <simpara> A választ Stig Bakken és Martin Jansen írta. </simpara> <para> Ha egy egyszerû bõvítményt szeretnénk készíteni, ami nem követi a <link linkend="standards">PEAR kódolási szabályokat</link>, helyezzük a pear/PECL/bõvítménynév könyvtárba (ide lesznek átmozgatva a bõvítmények a php-src/ext/extname könyvtárból). Ha a PEAR függvény/osztályelnevezéseit követõ bõvítményt írunk, helyezzük a pear/Foo_Bar könyvtárba (Foo_Bar helyett természetesen használjuk a bõvítmény nevét). </para> </sect1> <!-- <sect1 id="faq.install-pecl"> <title> How do I install a PECL module written in C? </title> <titleabbrev> Installing PECL modules </titleabbrev> <simpara> Answer written by Christian Stocker. </simpara> <simpara> The support for C-extensions in PEAR/PECL is not very sophisticated at the moment. Here's a short description of how to get C-modules running on your system until the PEAR::Installer does that for you. </simpara> <simpara> Download the package from PEAR, then untar it somewhere. Go into the newly built directory and do the following steps: </simpara> <para> <itemizedlist> <listitem> <simpara> phpize </simpara> </listitem> <listitem> <simpara> ./configure </simpara> </listitem> <listitem> <simpara> make </simpara> </listitem> <listitem> <simpara> cp modules/module.so /usr/local/lib/php </simpara> </listitem> </itemizedlist> </para> <simpara> The path, where the module.so is expected, can be different on your system (check <filename>php.ini</filename> and <function>phpinfo</function>). To actually use the module, you have to add it to the extension directive in <filename>php.ini</filename> or to load it with dl("module.so") within your PHP files. </simpara> <simpara> You can compile this extension directly into your PHP binary, too. For this you have to extract the package into <filename>php-src/ext</filename> (in your source directory). After that do also phpize in this new module-directory. But before you can configure your main php-exectuable, you have to do a <filename>./buildconf</filename> on the toplevel of the php-sources. Now you can configure/compile your PHP executable with the new extension, as you would with all other extensions. </simpara> </sect1> --> <sect1 id="faq.separated"> <title> Miért van külön pear/ és php-src/pear/ könyvtár? </title> <titleabbrev> Miért van pear/ és php-src/pear is? </titleabbrev> <simpara> A PEAR elsõ elemei a php-src/pear könyvtárban voltak tárolva, így szállításra kerültek minden egyes PHP disztribúcióval. </simpara> <simpara> A PEAR jelenlegi változatainál ez már nem mûködik, mivel a PEAR túl nagy ahhoz, hogy minden PHP disztribúcióba bekerüljön. Ezért az a döntés született, hogy minden elemet egy pear/ nevû felsõszintû könyvtárban helyezünk el. A többi elem, ami a php-src/pear könyvtárban van, hamarosan átkerül majd ebbe a könyvtárba. Csak a <link linkend="about-pfc">PFC kód</link> és a PEAR csomagmenedzser kódja kerül majd szállításra minden új disztribúcióval automatikusan. </simpara> </sect1> <sect1 id="faq.directory-structure"> <title> Miért tér el egymástól a pear/ és a php-src/pear könyvtárstruktúrája? </title> <titleabbrev> Miért más a pear/ és a php-src/pear? </titleabbrev> <simpara> A választ Stig Bakken írta. </simpara> <para> A php-src/pear/ könyvtár struktúrája megegyezik a telepítést követõ struktúrával (alapértelmezésben <filename>/usr/local/lib/php</filename>), és a benne lévõ fájlok egy egyszerû hierarchiába vannak rendezve. Ugyanakkor a <filename>pear/</filename> könyvtárstruktúrája aszerint épül fel, hogy melyik fájl melyik csomaghoz tartozik. Egyáltalán nem biztos, hogy ezek a fájlok telepítéskor is ilyen struktúrában kerülnek egy adott rendszerre, ezt a csomag leírófájlja határozza meg. </para> </sect1> <sect1 id="faq.flat-structure"> <title> Miért egy egyszerû könyvtárstruktúra egy mély szerkezetû helyett? </title> <titleabbrev> Egyszerû könyvtárstruktúra </titleabbrev> <simpara> A választ Stig Bakken írta. </simpara> <simpara> A CVS-ben a PEAR kódja csomagonként van tárolva, ahelyett, hogy ugyanolyan hierarchiában lenne, amilyenben telepítésre kerül majd. Például, ha az XML_RPC osztályt használni kívánjuk, az "XML/RPC.php" fájlt kell include-olni. Könnyen azt gondolhatjuk, hogy a CVS-ben is ugyanebben a struktúrában helyezkedik el, ám ez nem így van. Az XML_RPC egy független csomag a saját könyvtárával a CVS-ben, ebben az esetben az RPC.php a pear/XML_RPC/RPC.php elérési útvonalon található meg. A csomag leírófájlja (package.xml) határozza meg, hogy a fájlok végül hova kerülnek installálásra. </simpara> <simpara> A CVS-ben azért ilyen struktúrában vannak tárolva a fájlok, mert ez leegyszerûsíti a csomagok adminisztrációját. </simpara> </sect1> <sect1 id="faq.unstable-code"> <title> Bekerülhet a PEAR-be kísérleti / nem stabil kód? </title> <titleabbrev> Instabil kód </titleabbrev> <para> Igen. De gyõzõdjünk meg róla, hogy megjelöljük az experimental vagy unstable státuszt a projekt dokumentációjában. Ennek a legjobb helye a <filename>package.xml</filename> fájl <status> tag-je. A tag lehetséges értékei: <variablelist> <varlistentry> <term>alpha</term> <listitem> <simpara> a fejlesztés korai szakaszaiban, mikor még minden változhat (API, viselkedés) figyelmeztetés nélkül, még sok bug várható </simpara> </listitem> </varlistentry> <varlistentry> <term>beta</term> <listitem> <simpara> Az API alapesetben már nem változik, használható szoftver, de elõfordulhatnak hibák. </simpara> </listitem> </varlistentry> <varlistentry> <term>devel</term> <listitem> <simpara> A többi fejlesztõ számára megjelentetett változat, akik korábban hozzá szeretnének jutni a kódhoz, hogy teszteljék, és visszajelzéseket nyújtsanak, a kód minõsége pre-alpha-tól stable-ig változhat. </simpara> </listitem> </varlistentry> <varlistentry> <term>stable</term> <listitem> <simpara> A szoftver tesztelésre került, az API már le van fixálva, a dokumentáció elkészült, ez az ajánlott verzió a felhasználóknak és éles környezeteknek. </simpara> </listitem> </varlistentry> <varlistentry> <term>snapshot</term> <listitem> <simpara> Egy CVS snapshot egy adott dátumról. </simpara> </listitem> </varlistentry> </variablelist> </para> </sect1> <sect1 id="faq.add-examples"> <title> Szükséges példákat és/vagy tesztfájlokat adnom a csomagomhoz, és hol tároljam õket? </title> <titleabbrev> Példák hozzáadása </titleabbrev> <para> A példák nagyon hasznosak, különösen ha az adott osztálynak komplex API-ja van. De a példák csak részei a dokumentációnak, ne készítsünk példákat dokumentáció helyett. A dokumentációt és a példákat tároljuk a csomag könyvtárán belül egy 'docs' alkönyvtárban. </para> <para> Tesztszkriptek is ajánlottak, ha az osztály fordítást, speciális bõvítményeket/programokat, vagy helyesen installált további fájlokat (pl. sablonok, grafikák) igényel. Tároljuk õket egy 'tests' nevû alkönyvtárban. </para> </sect1> <sect1 id="faq.competitive-packages"> <title> Lehet a PEAR-ben több ugyanolyan funkcionalitással bíró csomag? </title> <titleabbrev> Versenyképes kód </titleabbrev> <simpara> Nincs probléma a hasonló funkcionalitást megvalósító csomagokkal, de nem szeretnénk 10 sablon osztályt, 7 különbözõ levelezéssel kapcsolatos osztályt és 3 különbözõ adatbázisréteget, amelyek ugyanazt végzik, csak más függvénynevekkel. </simpara> <para> Elõször végezzünk egy valóságtesztet: Miért szeretnénk a csomagot viszontlátni a PEAR-ben? Az igazán rossz válaszok: <quote>Hogy viszontlássam a nevem a PEAR-ben</quote> vagy <quote>Nem értettem meg az API-ját egy létezõ osztálynak</quote>. </para> <para> Egy új osztályra jó indok ha hiányzik egy függvény, viselkedés, vagy nem megfelelõ a sebesség egy létezõ implementációban. Ebben az esetben meg kell vizsgálni az adott osztályt, hogy lehetséges-e kibõvíteni igényeinknek megfelelõen. Ha nem, akkor van igazán jó indokunk rá, hogy egy új osztályt javasoljunk. A <quote>ha nem</quote> azt jelenti, hogy nem lehetséges hozzáadni a meglévõ osztályhoz a szükséges funkcionalitást az osztály alapjainak megváltoztatása nélkül. </para> <simpara> Ha új osztályt írunk, próbáljuk meg az API kompatibilitást annyira megõrizni a létezõ osztályokéval, amennyire csak lehet! Ha nem lehetséges az osztály kompatibilitásának a megõrzése, készítsünk egy wrapper osztályt a kompatibilitás megõrzése érdekében. Nem gond, ha ez az osztály sok processzoridõt vagy memóriát igényel, a wrapper osztályok célja a kompatibilitás megõrzése és az új verzióra történõ átállás megkönnyítése. </simpara> <para> Egymással versenyképes osztályokat elõzetesen be kell harangozni a <ulink url="mailto:&email.pear.dev;">PEAR fejlesztõi levelezõlistán</ulink>! </para> </sect1> <sect1 id="faq.question"> <title> Kérdésem van a PEAR-rel kapcsolatban. Hol kérdezhetek? </title> <titleabbrev> Kérdések feltevése </titleabbrev> <para> <itemizedlist> <listitem> <para> Általános kérdéseket a PEAR komponensek használatával kapcsolatban a PEAR általános levelezõlistára küldjünk: <ulink url="mailto:&email.pear.general;">&email.pear.general;</ulink>. </para> </listitem> <listitem> <para> Minden technikai megbeszélés a PEAR fejlesztésével kapcsolatban a PEAR fejlesztõi levelezõlistán zajlik: <ulink url="mailto:&email.pear.dev;">&email.pear.dev;</ulink>. </para> </listitem> <listitem> <para> A weboldallal kapcsolatos kérdéseket a PEAR webmester címére küldhetjük: <ulink url="mailto:&email.pear.webmaster;"> &email.pear.webmaster;</ulink>. </para> </listitem> </itemizedlist> </para> <para> A levelezõlistákra történõ feliratkozással kapcsolatos információkat <ulink url="&url.pear.support;">itt</ulink> találjuk. </para> <para> Minden fent említett levelezõlista nyelve az angol, és mindig legyünk udvariasak :-). </para> </sect1> <sect1 id="faq.require"> <title> Egy általam használt csomag include-ol egy csomagot, amire az én csomagomnak is szüksége van. Include-oljam ismét? </title> <para> Igen. Include-oljunk minden csomagot, amire szükségünk van a <function>require_once</function> vagy az <function>include_once</function> utasításokkal, még akkor is, ha egy általunk használt csomag már include-olja. </para> </sect1> <sect1 id="faq.windows"> <title> Mûködik a PEAR Windows alatt? </title> <titleabbrev> PEAR & Windows </titleabbrev> <para> A PEAR életre keltéséhez Windows alatt egyszerûen adjuk hozzá a PEAR telepítési könyvtárát (pl. <filename>c:\php\pear</filename>) az include_path direktívához a <filename>php.ini</filename> fájlban. </para> <simpara> Megjegyzés: Van néhány osztály (például Schedule/At.php), ami nem mûködik Windows alatt, mivel *nix specifikus parancsokat tartalmaznak. </simpara> </sect1> <sect1 id="faq.licenses"> <title> Milyen licenszek engedélyezettek a PEAR/PECL-ben? </title> <titleabbrev> Engedélyezett licenszek </titleabbrev> <simpara> A választ Jan Lehnardt, Tomas V.V. Cox és Rasmus Lerdorf írta. </simpara> <para> Jelenleg a PEAR a következõ licenszeket engedélyezi: </para> <itemizedlist> <listitem> <simpara> PHP Licensz </simpara> </listitem> <listitem> <simpara> Apache Licensz </simpara> </listitem> <listitem> <simpara> LGPL </simpara> </listitem> <listitem> <simpara> BSD stílusú licensz </simpara> </listitem> </itemizedlist> <para> További licenszek is elképzelhetõk, egyedi elbírálás alapján. Ilyen esetben lépjünk kapcsolatba a <ulink url="mailto:&email.pear.dev;">PEAR fejlesztõi levelezõlistával</ulink>! </para> <para> A PHP-be linkelt PECL bõvítmények esetében a licensznek kompatibilisnek kell lennie a PHP licensszel. Ez azt jelenti, hogy nem lehet egy PECL bõvítmény licensze GPL, mert megsértenénk a GPL-t. Ne felejtsük el, hogy amennyiben egy olyan bõvítményt írunk, amibe egy GPL-es könyvtár van belinkelve, szintén megsértjük a GPL-t. Ha egy ilyen könyvtárat szeretnénk linkelni, kérjük a könyvtár szerzõjének hozzájárulását. </para> <para> A PEAR/PECL csomag licenszének beállításához helyezzük el azt minden forrásnyelvi fájl fejlécében, és írjuk bele a csomagleíró fájl (<filename>package.xml</filename>) <license> tag-jébe! </para> </sect1> <sect1 id="faq.tabs-vs-spaces"> <title> Miért alapulnak a PEAR kódolási szabályok szóközök használatán TAB-ok helyett? </title> <titleabbrev> Tabok vs. Szóközök </titleabbrev> <simpara> A választ Stig Bakken írta. </simpara> <para> A szóközök használata és a tabok használatának mellõzése az egyetlen módja annak, hogy bizonyosan legyünk benne, hogy egy-egy kódrészlet minden szövegszerkesztõben ugyanúgy jelenik meg. Sok szövegszerkesztõ a tabokat 4 szóközként jeleníti meg, és sok másik szerkesztõ vagy terminál program 8 szóközként. Például: <literallayout><![CDATA[printf("%s", $arg);]]></literallayout> Itt 7 szóköz áll a "$arg" elõtt. Ha ezt a kódot egy, a tabot 4 szóközzel helyettesítõ szövegszerkesztõvel írtuk volna meg, egy tabként és három darab szóközként tárolná el. Ha most egy másik fejlesztõ megnyitja ugyanezt a fájlt egy 8-szóközt behelyettesítõ szövegszerkesztõben, akkor az így festene: <literallayout><![CDATA[printf("%s", $arg);]]></literallayout> </para> <para> Hasonlóképpen ez a kód 8-szóközt behelyettesítõ szoftver esetén: <literallayout><![CDATA[ if ($foo && $bar) { }]]></literallayout> Egy 4-szóközt alkalmazó szoftverben megtekinteve így nézne ki: <literallayout><![CDATA[ if ($foo && $bar) { }]]></literallayout> </para> <simpara> A PEAR-hez hasonló közösségekben, ahol a fejlesztõk rengeteg különbözõ rendszert és szövegszerkesztõt használnak, a tabok használata egyszerûen nem mûködik. Egy idõ után a fejlesztési idõ nagy része arra menne el, hogy a fejlesztõk a szóközöket tabokra cserélgetik és fordítva. Ha mindenki csak szóközt használ, minden rendszeren ugyanolyan az eredmény. </simpara> <para> Jamie Zawinski is <ulink url="&url.tabs.vs.spaces;">írt</ulink> a témában. </para> <para> Ezenkívül létezik egy <ulink url="&url.astyle;">Astyle</ulink> nevû eszköz is, amely segít a más stílusban megírt kódot a kívánt formátumra konvertálni. </para> </sect1> <sect1 id="faq.translators-revision-tracking"> <title> Is there a tool to help PEAR manual translators to track files changes? </title> <titleabbrev> Revision Tracking </titleabbrev> <para> Working on the translations is not just translating an English file and commiting the results. Much of the work is needed to update the already translated ones, to get in sync with the content of the English files. To follow the modifications in the English tree, you should <ulink url="mailto:&email.pear.doc-subscribe;">subscribe to the PEAR documentation mailing list</ulink> to get CVS commit messages, or read the archives. If you never update your files, the translations can get useless. </para> <simpara> Updating a foreign language file can get difficult, as you may not know when and who translated that file, so you may not know where you should look for the updates needed. We have one system for tracking the revisions and modification dates of the files in <literal>peardoc</literal>. </simpara> <sect2 id="faq.translators.revcheck-comments"> <title>The Revision Comments</title> <para> Instead of storing all responsibilities in a central file, the revision comment system stores them in the files they provide information about. Information about translator, revision numbers, and status information is stored in the revision comment. Let's see what would be in the header of the example file <filename>bookinfo.xml</filename> file in this case: <programlisting> <!-- EN-Revision: 1.16 Maintainer: jane Status: ready --> </programlisting> </para> <para> We can see the revision number for the last english file used to update the translation (EN-Revision: 1.16), the translator cvs account name. But we can also add some other status information in the case it is needed (eg. "partial" for incomplete translations). This revision comment system is basically about storing the information in the XML files, and not in a central place. This is extremely convenient now, as there are more than 1300 files in the English tree. </para> <para> Currently, all three fields (English revision, Maintainer, Status) are needed. Maintainer is intended to be a CVS user name, or some nickname without a space, status can be anything without a space. Note, that this header is not updated by CVS (in contrast with <literal>$Revision</literal>, which is updated automatically). This is only updated when you edit the contents of the comment yourself. </para> <para> You may see this as a good thing, but using these comments, you lose the quick look on the whole list of your files. No, you do not lose this, but get much more! If you would like to build a full list of you files, you can go to the /peardoc/ directory and run: <programlisting> /scripts/revcheck_pear.php xx > revcheck.html </programlisting> Here <literal>xx</literal> is the imaginary language code. After running this script you'll get a <filename>revcheck.html</filename> in the same directory. You can find revision comparisions and links to diffs for all the files in this language. You can also add a further restriction parameter, the maintainer name, so the script will only list the files corresponding to the given maintainer. </para> <para> There are some optional extensions introduced for this script, to be available in this generated HTML page. This is why the <filename>translation.xml</filename> files are introduced. Here comes a simple <filename>translation.xml</filename> file for the imaginary xx language : <programlisting> <![CDATA[ <?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE translation SYSTEM "../dtds/translation.dtd"> <translation> <intro> This is some introductory text for the xx language translators about who is the manager of the translation, and where to find more information. This paragraph is printed on the top of the generated revcheck.html page. </intro> <translators> <person name="Joe Doe" email="joe@hotmail.com" nick="joedoe" cvs="yes" editor="yes"/> <person name="Jane Smith" email="jsmith@yahoo.com" nick="jane" cvs="yes"/> <person name="Joe Forever" email="joe@forever.net" nick="joefo" cvs="no"/> </translators> <work-in-progress> <file name="appendices/aliases.xml" person="joedoe" type="working"/> <file name="functions/dbx.xml" person="joefo" type="working"/> </work-in-progress> </translation> ]]> </programlisting> In this file, you can add users without a CVS account, and can assign ready documents or work-in-progress files to them. The biggest advantage of using this addon is that all this information is used to generate dynamic tables of translators and files in the <filename>revcheck.html</filename> file. All translators are linked to from the individual files they are assigned to, and there is a nice table showing the state of files for all the translators. Assigning ready files may be needed if a time consuming update is in progress on that file. </para> <para> There are two optional parameters you can add to a <file>, if you would like to record it: the <literal>date</literal> and <literal>revision</literal>. Date is assumed to be the date when the work was started, revision is the checked out revision of the English file used to start the work (denoted as CO-Revision in the generated table). There is currently no fixed format for the <literal>date</literal> parameter. </para> <para> Another addon to this system is just to give credit to all people who worked on one file, and not just the current maintainer. To achieve this goal, we added the credit comments. One credit comment in eg. <filename>history.xml</filename> may look like this (in case Joe Doe translated the file initially, but Jane followed him to be the maintainer): <programlisting> <!-- CREDITS: joedoe --> </programlisting> The credits comment can contain a comma-separated list. These comments only affect the display of the translators table in <filename>revcheck.html</filename>. </para> </sect2> </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 sgml-parent-document:nil sgml-default-dtd-file:"../../manual.ced" sgml-exposed-tags:nil sgml-local-catalogs:nil sgml-local-ecat-files:nil sgml-namecase-general:t sgml-general-insert-case:lower End: vim600: syn=xml fen fdm=syntax fdl=2 si vim: et tw=78 syn=sgml vi: ts=1 sw=1 -->