Komponenty

phx

Zdravim osazenstvo…

Dnes jsem uspesne vybojoval svoji prvni komponentu:) Kdyz o tom tak premyslim, tak by asi nebylo od veci udelat nekde nejaky „sklad“ komponent. Jde prece o znovupouzitelnost ne? Co myslis Davide? Udelas tu nekde nejaky prostor nebo to mame davat na svoje weby a spol?

Moje prvni komponenta je na strankovani vypisu (takove to dole na prepinani mezi strankama v tabulce treba). Jeste tam chci dodelat maximalni pocet cislic vedle sebe (pri 100 strankach by to bylo sileny), ale to az priste. Zatim se jen nastavi pocet zaznamu, pocet zaznamu na stranku a to je vse. Cislo stranky si to predava samo. Na pozadani muz poslat kod, do fora se mi to davat nechce, je to dlouhe.

Ted otazka:
Nejak jsem neprisel jak v ramci komponenty vyuzivat sablony. Jedine co me napadlo, je predat si odkaz na sablony z presenteru, ale rikam si, ze to musi jit nejak jinak, hezcejc…
Zatim to resim tak, ze je tam metoda getRenderArray() a dle ziskaneho pole si to clovek v sablonach spatla jak chce.
I kdyz ted me napada, ze komu nebude vyhovovat vzhled strankovani muze podedit a predefinovat.

veena

Ty kool

Zkus si říct o první přístup do:
http://code.google.com/p/nette-extras/

phx

Nevite nekdo jak na sablony v komponentach? Viz #1

ViliamKopecky

phx napsal(a):

Nevite nekdo jak na sablony v komponentach? Viz #1

Také by mě to velmi zajímalo. Myslim že Dave říkal něco, že pro komponenty budou templaty s příponou .tpl, ale jak používat, nevim.

phx

Davide jak s komponentama?

Nebo muzu poprosit o pristup do http://code.google.com/p/nette-extras/

Zatim ke stazeni ZDE

David Grudl

Zkuste prosím nejprve vymyslet rozumnou a dlouhodobě udržitelnou strukturu pro repozitář nette-extras.

phx

Zakladni deleni asi na vizualni a nevizualni.

pak co komponenta co adresar, ale tak jako tak by nekde chtelo nejaky seznam jmeno – popis. Jinak tam nikdo nic nenajde.

veena

Cože, je třeba něco zorganizovat? Jsem tady :-)

Vizuální – nevizuální je možné dělení, ale nepřináší nám řekl bych nějakou přidanou hodnotu, či užitečný klíč k orientaci.

Nevytvářel bych nějakou složitou strukturu. Můj návrh je udělat tři adresáře:

applications (celé aplikace jako blog, cms)
components (třeba to tvoje stránkování, libovolná komponenta, která může mít i šablony)
snippets (krátké kousky kódu užitečné kdekoliv)

V těchto třech adresářích bych pak už štosoval adresáře jednotlivých „balíčků“ podle abecedy. Ono jich asi zase nebude tolik, pokud bude dělat David selekci jen na ty propracované.

Co myslíte?

phx

Souhlas.

veena

Ještě přemýšlím, jestli by měly mít všechny balíčky v názvu povinný prefix nette-. Možná by to bylo výhodné pro pozdější dohledávání věcí okolo nette.

phx

no ale zase s hure hleda napr v TotalCommanderu dle prvnich pismen:(

llook

Co udělat jednoduchou dvouúrovňovou strukturu?

První úroveň by identifikovala autora (příp. skupinu autorů), druhá samotnou jednotku informace. Jako v Javě, akorát místo tamních obrácených URL by autora identifikoval třeba nick z fóra nebo tak něco.

Pak by mohla existovat komponenta phx::PagerComponent spolu s (například) veena::PagerComponent, která by na to šla třeba trochu jinak.

phx

Take reseni, ale nemichal bych do toho jmene prostory trid. Tento zpusob se mi zda asi nej, ale urcite by to chtelo nejaky globalni fultext vyhledavac nebo nejaky flagy.

veena

llook napsal(a):

Co udělat jednoduchou dvouúrovňovou strukturu?

První úroveň by identifikovala autora (příp. skupinu autorů), druhá samotnou jednotku informace. Jako v Javě, akorát místo tamních obrácených URL by autora identifikoval třeba nick z fóra nebo tak něco.

Pak by mohla existovat komponenta phx::PagerComponent spolu s (například) veena::PagerComponent, která by na to šla třeba trochu jinak.

Nechal bych název aplikace na autorovi. Aplikace může mít i víc autorů.

Dvoúrovňovou strukturu v svn myslíš adresáře takhle phx/PagerComponent ?
Když budeš ale hledat v tom adresáři nějakou komponentu, proč prolézat jednotlivé adresáře všech autorů, aby člověk našel, jestli tam není to, co potřebuje.

llook

Přesně tak to myslím, každý kontributor by si nafasoval adresář a práva k zápisu do něj. Kromě toho by ještě byla stránka v dokumentaci, kde by to bylo naopak podle kategorií a se stručným popisem. Ta stránka by vypadala třeba nějak takhle:

Stránkovače:

phx::PagerComponent – Stránkovač SQL dotazu, zobrazuje odkazy na všechny stránky.

někdo_jiný::PagerComponent – Stránkovač SQL dotazu, zobrazuje pouze šipky „novější/starší“.

xy::EnhancedPagerComponent – Stránkovač jakéhokoli IDataSource s rozsáhlými možnostmi nastavení.

Hlasovadla:

asdf::PollComponent – Anketa s kontrolou IP a cookie.

qqq::KarmaComponent – Hlasovátko +/-.

blabla::PollComponent – Anketa s potvrením e-mailem.

Atd…

Snadno může docházet k situacím, kdy dva různí lidé nezávisle na sobě budou pro vlastní potřebu implementovat hodně podobnou funkčnost pod stejným názvem. Když se tu sejdou dvě různé stránkovací komponenty od různých autorů, jak jinak je odlišit?

veena

To by asi šlo. Mohutnost balíčků by se pak mohla rozlišovat podle suffixu.

grudl/WikiApplication

phx/PagerComponent

veena/SomeSnippet

A.

Možná by nebylo od věci i dodržovat php coding standards, aby to mělo nějakou úroveň.

Ta komponenta nahoře je jak pěstí do nosu.

Editoval A. (2. 6. 2008 14:22)

LM

Můžeš hodit odkaz jaký coding standards máš na mysli? Totiž každej si je vykládá jinak třeba https://texy.info/…ing-standard nebo třeba http://framework.zend.com/…tandard.html.

David Grudl

Dodržovat společný coding standards je poměrně tvrdá, ale v rámci jednoho úložiště opostatněná podmínka. Určitým kompromisem by mohl být seznam několika povolených standardů, mezi kterými si může vývojář vybrat.

S „coding standards“ úzce souvisí „naming conventions“. Pokud stavíte komponentu jako rozšíření nějaké třídy z Nette, je vhodné použít stejné pojmenovávací konvence, protože jinak by vznikl hybrid.

phx

Souhlasim. Sice urcite nejake veci se mi libit nebudou, ale jinak to asi nepujde.

A. napsal(a):

Ta komponenta nahoře je jak pěstí do nosu.

Copak se ti na ni nelibi?

A.

phx napsal(a):
Copak se ti na ni nelibi?

Slovem pěstí do nosu jsem to možná přehnal, to se omlouvám, nemyslel jsem to tak silně :-). Na první pohled mě děsně vadily ty oddělovátka, dále pak nemezery u operátorů a za řídícími strukturami jako if apod.

LM napsal(a):
Můžeš hodit odkaz jaký coding standards máš na mysli? Totiž každej si je vykládá jinak třeba https://texy.info/…ing-standard nebo třeba http://framework.zend.com/…tandard.html.

Záměrně jsem neuvedl přesně které, jelikož by to bylo subjektivní :-). Ale když už jsme u toho, nejraději mám ty od pearu. Jsou velmi podobné např. c-stylu a to se mi líbí.

Řekl bych, že je Nette splňuje.

Editoval A. (2. 6. 2008 18:24)

phx

A. napsal(a):

Na první pohled mě děsně vadily ty oddělovátka, dále pak nemezery u operátorů a za řídícími strukturami jako if apod.

Muj osobni nazor je ze:

mezera za if se mi vubec nelibi
oddelovatma mi prijdou dobry prtz pri rolovani hned vidim zacatky metod (zvyk)
nemezery v podminkach a vypoctech se mi osobne take nelibi
a posledni asi TAB vs MEZERY (preferuji TAB, prtz kazdy ma jine zvyky a nastavi si editor jak chce, ale pokud jsou tam mezery, tak si nic neupravi)

Jan Tvrdík

IMO je nejlepší to psát stejně jako je to v Nette. Akorát by to někdo mohl sepsat.

Mimochodem neznáte nějaký program, který by kód podle zadaných pravidel zformátoval?

veena

Jan Tvrdík napsal(a):

IMO je nejlepší to psát stejně jako je to v Nette. Akorát by to někdo mohl sepsat.

Mimochodem neznáte nějaký program, který by kód podle zadaných pravidel zformátoval?

Souhlas. Když spolupracuješ na kódu, který už existuje, přizpůsob se pravidlům, kterými je kód již psán.

David Grudl

Jan Tvrdík napsal(a):

IMO je nejlepší to psát stejně jako je to v Nette. Akorát by to někdo mohl sepsat.

Mimochodem neznáte nějaký program, který by kód podle zadaných pravidel zformátoval?

Umí to Polystyle, ale je to divné, ne moc funkční, ne moc stabilní (stav cca před rokem).

A.

phx napsal(a):
Muj osobni nazor je ze:
mezera za if se mi vubec nelibi

Ta je imho snad ve všech standardech.

oddelovatma mi prijdou dobry prtz pri rolovani hned vidim zacatky metod (zvyk)

Je to balast ve zdrojáku navíc, stejně dobře fungují např. foldy.

nemezery v podminkach a vypoctech se mi osobne take nelibi

V tomto bodě mohu souhlasit, že je to věc názoru.

a posledni asi TAB vs MEZERY (preferuji TAB, prtz kazdy ma jine zvyky a nastavi si editor jak chce, ale pokud jsou tam mezery, tak si nic neupravi)

Zde záleží na editoru, pokud je schopný, pracuje s uvodními mezerami stejně jako s taby. Já mezery také neměl rád, ale po několika věcech v pythonu jsem si zvyknul.

Např. vim umí i krasně indent opravit, gg=G a máte po starostech.

Dle mého názoru je ale přístup ke coding standards jen otázkou tvrdohlavosti. Vždy když se domlouváme pro nějaký nový projekt, tak jsem na věci taky názoru: „Tohle ne.“ „Tohle už vůbec ne.“ No, ale ono se Vám to začne po chvilce i líbit.

Používat stejný jako Nette je ale rozumné, jaký si Davide použil?

Editoval A. (2. 6. 2008 22:33)

David Grudl

A. napsal(a):

Používat stejný jako Nette je ale rozumné, jaký si Davide použil?

Používám vlastní :-)

Debata o struktuře úložiště se rozvíjí zajímavě, jen bych poprosil, vyhněte se srovnávání, který coding standard je lepší. To je vděčným flame tématem, jenž se nikdy nedobere žádného závěru.

phx

OK snad jen posledni poznamka. Nahradit 2 mezery za tab sice jde, ale co kdyz jsou mezery ve stringu? Ty zase nahradit nechci:(

Davide vyjadris se nejak ke strukturovani uloziste? Urcis nejak jaky coding standard se tam bude pouzivat?

llook

Ta komponenta je psaná jinak, než jsem zvyklý třeba já (vůbec třeba nechápu, proč je úplně všechno uvnitř <?php ?> odsazené…), ale oceňuju, že jsou tyto divné konvence dodrženy všude. A oddělování metod pomocí // ================= se mi líbí, to asi adoptuju. Cizí lidi se v tom vyznají a to je hned druhá nejdůležitější věc (nejdůležitější je, aby se v tom vyznal sám autor).

S nějakými naming conventions pro veřejná rozhranní bych souhlasil, ale jakým způsobem kód formátovat (mezery vs. taby, BSD vs K&R, if() vs if () apod.), to bych nechal na uvážení autora.

Když jsem svoje vlastní konvence přibližoval Zend/PEAR/Nette, tak jsem použil PEAR:PHP_Beautifier. Ovládá se z příkazové řádky a aby ten kód zformátoval jakž takž, tak potřebuje strašnou spoustu parametrů, které jsem si bohužel nikam nepoznamenal.

tom

phx napsal(a):

Davide jak s komponentama?

Nebo muzu poprosit o pristup do http://code.google.com/p/nette-extras/

Zatim ke stazeni ZDE

Muzu mit jeden zacatecnicky dotaz? Stahnul jsem si zdrojaky s komponentou na strankovani, vse funguje. Zkusil jsem si ale komponentu zapojit do sveho projektiku a narazil jsem na problem ze vlastne nevim jak spravne na to. Kdyz vytvarim komponentu v DefaultPresenter.php

<?php
$this->paging = new PagingControl($this, 'paging');
?>

tak mi to hodi chybovou hlasku

„Fatal error: Class ‚PagingControl‘ not found …“

coz jsem vyresil tim, ze jsem do souboru bootstrap.php vlozil

<?php
require_once dirname(__FILE__) . '/components/PagingControl.php';
?>

Kdyz se ale divam, do ukazkove aplikace kterou jsem si zde stahnul, tak tam nic takove neni (nebo aspon jsem si nevsiml), proto se chci zeptat na obecny zpusob jak pridavat komponenty tak aby byly pouzitelne … Diky za info

phx

Vtip je v tom, ze pouzivam toto:

$robot = new RobotLoader();
$robot->addDirectory(APP_DIR);
$robot->register();

To samo prohleda slozky a potrebne tridy vklada. Bylo to zmineno v prvni Nette prednasce.