Elo mam dylemat chce sobie zaczac dokumentowac kod...juz mam wszystko zrobione...jednak mam pewne metody gdzie samo @access,@param,@return mi nie wystarcza chcialbym w zrodlo pliku w ktorym sie znajduje klasa podac maly przyklad uzycia metody.
Czy robi sie to za pomoca: http://manual.phpdoc.org/HTMLSmartyConvert...xample.pkg.html czy http://manual.phpdoc.org/HTMLSmartyConvert...source.pkg.html

Pytam bo nie jestem pewny...

Wydaje mi się jednak, że @source - wnioskuję tak po opisie.

@example to ścieżka do pliku z przykładem. Pewnie zauważyłeś, że nieraz ściągając jakiś projekt masz foldery docs, src / lib, examples itp. - tu powinna być właśnie ścieżka do pliku z katalogu examples.
@source - za dokumentacją - Display source code of a function or method in the long description

Ty powinieneś po prostu skorzystać z długiego opisu tak jak to masz przykładowo tutaj: https://github.com/symfony/symfony/blob/mas...ClassLoader.php

Czyli to powinno byc poprawne:

[PHP] pobierz, plaintext 
	/**
	*Ustawia nam dla danej kolumny odpowiedni typ w html
	*@access public 
	*@param string $key nazwa pola
	*@param string $type
	*przyklad uzycia np kolumna news_author w $this -> db_fields_equivalent jest typu text chcemy ja zmienic na textarea
	*<code>
	*	<?php
	*		$instance -> set_equivalent('news_author', 'textarea');
	*	?>
	*</code>
	*/
	public function set_equivalent($field, $type) 
	{
		if(array_key_exists($field, $this -> db_fields_equivalent))
			$this -> db_fields_equivalent[$field] = $type;
	}
[PHP] pobierz, plaintext 

Pytam bo tak ogolnie to nie bede na srv mial phpdoc ale nigdy nie wiadomo a samemu mi to pomoze w przyszlosci ;]

Nawet nie jestem teraz na 100% pewien ale chyba powinieneś używać 4-ech spacji, zamiast tabulatora, <code /> możesz sobie darować bo samo wcięcie już spełnia tę funkcję. <?php i ?> też są zbędne. Samą dokumentację też można by pisać po angielsku - wygodniej tak jest.

[PHP] pobierz, plaintext 
	/**
	 * Ustawia nam dla danej kolumny odpowiedni typ w html.
	 *
	 * Przykład użycia np kolumna news_author w $this -> db_fields_equivalent jest typu text chcemy ja zmienic na textarea:
	 *
	 *     $zrobCosTam->dsadasda();
	 *     $instance -> set_equivalent('news_author', 'textarea');
	 *     $zrobCosTam->dsadasda();
	 *
	 * Bla bla bla bla - dalszy opis. 
	 *
	 * @param string $key Nazwa pola
	 * @param string $type
	 */
	public function set_equivalent($field, $type) {
		if(array_key_exists($field, $this -> db_fields_equivalent)) {
			$this -> db_fields_equivalent[$field] = $type;
		}
	}
[PHP] pobierz, plaintext 

PS. W PHP stosuje się konwencję camelCase, czyli setEquivalent(), a @access jest zbędne ponieważ sam język to określa przy deklaracji metody.

thx
dokumentacja moze byc i w pl bo to raczej tylko dla mnie
co do @access to masz racje jednak gdybym chcial sobie postawic phpdoc na srv i wyswietlic dokumentcje to mysle ze bez @access sie nie obejdzie...ale byc moze sie myle!

Wiem wiem ze camelCase w C# tez ale troche pokodzilem w python'ie i tak mi zostalo ;p efekty uboczne

@access to pozostałość z phpDoca z czasów PHP4 kiedy to język nie umożliwiał określenia poziomu dostępu dla właściwości / metody. W PHP5 jest to wymagane i zawsze da się to określić na podstawie kodu dlatego też nie ma potrzeby korzystania z @access.

czyli nawet bez @access phpdoc potrafi wygenerowac dokumentacje z poprawnymi dostepami do metol/pol?

Tak, takie rzeczy jak widoczność metody, abstrakcyjność czy finalność klasy itp. można wyciągnąć bezpośrednio z kodu (a dokładniej to korzystając z mechanizmów refleksji) dlatego też w komentarzach phpDoca tego się już nie powinno podawać bo jedynie zaśmieca kod.

o refleksji to ja wiem ale nie wiem jak stoi phpdoc dlatego pytam bo nigdy go nie uzywalem i nie wiem ze od php5 posiada "auto wykrywanie" widocznosci itp..itd...ogolnie thx ;p