Jak je to s finálním Nette 1.0?

hodilo by se tlačítko líbí se mi, ale takové které nesměřuje na FB:)

+1

Je pravda že na čísla jsem se nekoukal jde spíše o subjektivní pocit…

Co osobně vidím jako prioritu do 1.0:

• Hotovou dokumentaci. To je bezpodmínečně nutné, vydání 1.0 stable je velká událost, bude okolo toho velké haló, tiskovky v médiích, spousta lidí s učením určitě čeká na tento milník a nehotová dokumentace by určitě všechny zklamala.
• Nějaké řešení zavináčů. Vím, že to u současných snippetů nejde vyřešit z principiálních důvodů, ale nějaké řešení bez magie by to zkrátka chtělo. Třeba by si Nette mohlo při compile-time vyhledat hierarchii bloků, ve kterých jsou snippety a ty vyskočení z podmínek do nakešovaných šablon aplikovat bez asistence programátora. Ale možná přesně tohle automaticky nejde a je důvod, proč tahle věc stále nemá řešení :)
• Reakce (popření či oprava) všech issues na GitHubu.

Čemu bych přiřadil menší prioritu, ale do 1.0 by se to ještě mohlo vejít:

• Osamostatnění validátorů a filtrů od formulářů.
• Vyhození ConventionalRendereru – vykreslovat formuláře pomocí šablon.
• Podpora AJAX historie (tlačítka zpět/vpřed v prohlížeči) a stav aplikace za # v URL.
• Další slíbené javascriptové vychytávky od Dana Steigerwalda.
• Nová syntaxe pro konfigurační soubory.
• Přehodnocení třídy Nette\Environment s ohledem na dependency injection a minimalizování skrytých závislostí.

Co bych vůbec nedělal (nikdy):

• Nette je dobré v tom, že nepřikazuje podobu modelu. Takže si každý může zvolit, jestli bude bastlit volání dibi::query v nějakých statických metodách anebo vezme modelovou část aplikace vážně (protože je to to nejdůležitější) a použije třeba Doctrine 2. Tady bych místo pro nějaké nakázání jednotných modelů neviděl.
• Nevzpomínám si na další plány a návrhy, třeba to sem časem doplním.

A ještě k vývoji – celkem chápu, že David nechce přijmout commity obsahující nějaké zásadnější features, protože se mu třeba nelíbí (konec konců, pokud se někomu tyto features líbí, může si je do vlastní aplikace doplnit, pokud to jde čistě bez zásahu do frameworku). Ale např. na ty issues na GitHubu by se komunita vrhnout mohla, napsat a otestovat fixy, to půjde max. o několik řádků a David to rád přijme.

Zde vidím jako nevýhodu to, že Nette nemá testy v PHPUnitu, ale v nějakém bastlu, ve kterém se nevyznám a psalo by se mi v tom nepohodlně. Bojím se ty testy dokonce i spustit, těžko říct, co na mě vyskočí :o)

ad modely: ve firmě, kde nyní brigádničím, nepoužívají Nette právě kvůli absenci rozhraní s modely. Vytáhli si jen co se jim líbí (laděnka, šablony). Podle mě by bylo dobré mít nějaké řešení, ale třeba i možnost použít svoje vlastní.

Ondřej Mirtes napsal(a):

…

• Hotovou dokumentaci. To je bezpodmínečně nutné, vydání 1.0 stable je velká událost, bude okolo toho velké haló, tiskovky v médiích, spousta lidí s učením určitě čeká na tento milník a nehotová dokumentace by určitě všechny zklamala.

Tohle se dělá blbě ve chvíli kdy je plánováno n featur ke kterým není roadmap a implementace neexistuje. Pokud projdeš drafty stránek (např. Environment), pochopíš o čem mluvím („bude se toho hodně měnit“).

• Nějaké řešení zavináčů.

Rozhodně.

• Reakce (popření či oprava) všech issues na GitHubu.

To už jsem Davidovi nedávno naznačoval na Jabberu, ale bohužel. :S

• Osamostatnění validátorů a filtrů od formulářů.
• Vyhození ConventionalRendereru – vykreslovat formuláře pomocí šablon.
• Podpora AJAX historie (tlačítka zpět/vpřed v prohlížeči) a stav aplikace za # v URL.
• Další slíbené javascriptové vychytávky od Dana Steigerwalda.
• Nová syntaxe pro konfigurační soubory.

Určitě.

• Nette je dobré v tom, že nepřikazuje podobu modelu. Takže si každý může zvolit, jestli bude bastlit volání dibi::query v nějakých statických metodách anebo vezme modelovou část aplikace vážně (protože je to to nejdůležitější) a použije třeba Doctrine 2. Tady bych místo pro nějaké nakázání jednotných modelů neviděl.

Ještě nedávno jsem na to neměl názor, ale teď když používám Doctrine 2 to také vidím jako plus. Přecijen to M se při použití různých nástrojů liší.

A ještě k vývoji – celkem chápu, že David nechce přijmout commity obsahující nějaké zásadnější features, protože se mu třeba nelíbí (konec konců, pokud se někomu tyto features líbí, může si je do vlastní aplikace doplnit, pokud to jde čistě bez zásahu do frameworku). Ale např. na ty issues na GitHubu by se komunita vrhnout mohla, napsat a otestovat fixy, to půjde max. o několik řádků a David to rád přijme.

Z mé strany snaha byla – kanonizace flash messages a přenášení persistentních parametrů do error presenteru. Obojí bez odezvy.

Zde vidím jako nevýhodu to, že Nette nemá testy v PHPUnitu, ale v nějakém bastlu, ve kterém se nevyznám a psalo by se mi v tom nepohodlně. Bojím se ty testy dokonce i spustit, těžko říct, co na mě vyskočí :o)

Já se odvážil. Skončil jsem chybou ve spouštěcím scriptu.

Roman: S tím jsem setkal, samozřejmě u vlastního kódu. Už tři měsíce děláme v Doctrine 2 a když se vracím ke starému kódu v dibi, vidím na první pohled ten chaos, neudržitelnost a nesystematičnost. Přijde mi ale jako nesmysl u vývojářů vynucovat nějakou ORM vrstvu, svazovalo by jim to ruce a prskali by. Někomu nemusí vyhovovat Doctrine a má pro své účely lepší nástroj. Univerzální vynucování něčeho nebastlířského asi nevymyslíme :o)

Dibi je skvělý nástroj a posloužil by dobře jako DBAL (tedy nejnižší vrstva modelu) v nějakém ORM, ale používat ho samostatně hned za controlerem nepřináší kvalitní kód.

Můžeme dělat osvětu, psát články a propagovat nebastlířské způsoby, jak programovat, ale to je vše, co s tím uděláme – kdo chce bastlit, cestu si najde vždycky.

Ondřej Mirtes napsal(a):

• Nějaké řešení zavináčů. Vím, že to u současných snippetů nejde vyřešit z principiálních důvodů, ale nějaké řešení bez magie by to zkrátka chtělo. Třeba by si Nette mohlo při compile-time vyhledat hierarchii bloků, ve kterých jsou snippety a ty vyskočení z podmínek do nakešovaných šablon aplikovat bez asistence programátora. Ale možná přesně tohle automaticky nejde a je důvod, proč tahle věc stále nemá řešení :)

Myslím, že hlavní zábranou, proč na tento problém stále řešení nelze nalézt je fakt, že LatteFilter je jenom filter – vezme vstupní text, rozvine v něm makra a vrátí výstupní text. Naroubovat na tenhle přístup složitější logiku opravdu nepůjde.

Základní otázka je, používá někdo šablony jen tak, bez LatteFilteru? Jestli ne, setrvávat u toho, že se jedná jen o „hloupý“ makro procesor, je zlé. Je čas na to, aby se LatteFilter oprostil toho „Filter“. Pokud by se dalo pracovat se šablonou ve formě AST, ne textu, nebylo by složité provést v compile-time analýzu, kde je jaký snippet a podle toho se zařídit.

(BTW kde jsou všechna ta vlákna o zavináčích a snippetech? Nějak je nemůžu najít.)

Cheché! A já jsem vám to o těch ORM říkal rovnou! A vy jste mi za to tehdy nadávali! Říkali jste, jak je Doctrine fail, jaký je to moloch. A teď sám Ondra uznává, že něco do sebe má…

Jinak já naprosto souhlasím s Romanem, že by měla být nějaká „normalizovaná“ cesta jak to dělat. A říkal jsem vám to už dávno! Ale také souhlasím s Ondrou, že nutit lidi k jednomu postupu má i své nevýhody…

Jestli se chcete inspirovat, mrkněte jak je to vyřešené v Rails 3 – defaultně s Rails 3 dostaneš Active Record, což je nečekaně ORM postavené na Active Record patternu, ale jestli chceš, tak můžeš použít řadu jiných podle jiných patternů (DataMapper, MonogoMapper, etc.).

Hlavní je, že způsob jakým se ORM propojuje se zbytkem Frameworku je takříkajíc „normalizován“ – což je podle mého to, co Nette chybí. Podle mě by se toto (způsob jak ORM s Nette propojit) mělo v Nette normalizovat a potom by se mělo vytvořit nějaké ORM nad dibi, nebo napsat nějaký defaultní Mapper nad Doctrine 2, whatever – prostě, aby byla nějaký výchozí volba – a pak je na každé, vývojáři, jak se rozhodne – jestli použije defaultní, nebo nějaký jiný, který někdo nahraje do extras, nebo jestli si napíše svůj vlastní. Navíc i ten způsob jak to propojení s ORM „normalizovat“ není třeba vymýšlet a kouknout se k Railsovým sousedům;-).

Z mého pohledu není nad čím dumat, stačí se rozhlédnout a inspirovat se. Což je mimochodem další věc, kterou vám říkám už dlouho – vidím, že to začínáte konečně chápat;-), mám radost – jen tak dál:-)

A ad lidi, co ORM nechtějí – MVC a ORM je IMHO související věc – největší benefity z toho mám když to používám obojí a když to dobře spolupracuje. Pro lidi, kteří ORM z nějakých důvodů nechtějí (tyto důvody jsou podle mého navíc velmi často způsobeny jejich ne zcela dostačující odbornou způsobilostí více než čímkoliv jiným), by mělo být možné to nějak používat i bez toho – ale rozhodně by to neměla být ta výchozí cesta… Alespoň pokud to Nette chce dotáhnout opravdu daleko, nejen v naší české kotlině;-)…

…a pak stačí vyřešit už jen integraci s různými unit test frameworky, někde existuje tuším nějaké to rake pro PHP, přidat trochu scaffoldingu, na google code jsem, tuším, viděl už i nějakou php obdobu gemů…

…a začne se to blížit frameworkovým kvalitám Rails;-) – ještě dotáhnout tu dokumentaci a rozšířit to v EN světě a možná to PHP nebude ještě tak nadobro ztracené…;-) – držím palce!

Vím jak může být těžké zavázat se k nějakým termínům.

Proto bych začal tím, aby David jasně rozhodl, které featury budou v 1.0 a které nemilosrdně odložit na později. Takhle totiž vývoj pořád visí v nějaké alfa verzi, příbývají feature requesty, bugy, na všem se tak nějak pracuje, ale milestones, bety, RC či snad dokonce stable verze jsou stále v nedohlednu.

Za Nette stojí silná komunita ochotná s vývojem pomáhat, ať už nápady nebo i samotným bušením kódu, ale v poslední době mám pocit, že se David do diskusí přestává zapojovat, až nakonec vyšumí. Navíc neřešené pull requesty a issues.

Davidovy práce si cením a chápu že si nechce do frameworku pouštět kdejaký balast, ale všeobecným embargem tomu taky nepomůže. Aby to nakonec nedošlo tak daleko, že se komunita, kterou se Nette tak chlubí, na nějaké přispívání vykašle, když stejně není žádná odezva :(

David Grudl napsal(a):

Píšeš … ale ve skutečnosti to znamená …

Ano skutečně to znamená to co jsi napsal. Ale ono to ani nic jiného znamenat nemůže (vzhledem k tomu jak je vše kolem Nette nastavené)

Mě třeba zase zaráží vývoj nové dokumentace který skončil tím, že jsem udělal osnovu. (sorry za invektivu)

Ano naprosto tomu rozumím a důvod(y) jsem doufám jasně napsal.

Zdá se, že nejsem robot s 50hodinovým dnem, ale jen člověk.

To jsem psal taky…

Ale dobrá, mám takový návrh: udělám veřejný závazek, že beta verzi Nette 1.0 s implementací oněch zásadních změn vydám do 19. září 2010. Vy udělejte závazek, že do té doby bude na https://doc.nette.org kvalitní dokumentace. Jdete do toho?

Do toho jdu i kdybych to měl napsat sám!!! (samozřejmě když někdo udělá korekci)

PS: šlo by někam napsat Roadmap těch změn?

Rád se zúčastním a nějakého skeletonu se taky ujmu,
slibuju to už taky nějakej ten pátek, tak bych to chtěl konečně dodržet :)

Pokud ty zásadní změny (které samozřejmě potřebují také zdokumentovat) nebudou vydány den předem, jdu do toho.

+1

Pokud můžu doporučit, tak se raději nějaké „standardizaci modelu“ vyhněte obloukem. M v MVC ani MVP rozhodně neznamená Data Access. A ani DAL jako takový nemá cenu nějak lámat za univerzální rozhraní. Každý konkrétní přístup k datům má svá specifika.

Víc k tématu třeba tady: http://ayende.com/…ll-fail.aspx

rarous: Souhlasím, ale minimálně by se hodilo alespoň nabídnout a nastínit nějaká pojetí. Jde o to, že framework v současné době IMHO velmi dobře vede programátora ke správnému pojetí vrstev VP, ale už vůbec nijak nepomáhá programátorovi správně pojmout M vrstvu. A ta je zejména u rozsáhlejších projektů přeci jen klíčová.

Například ukázka CD collection v distribuci představuje snad úplně nejtriviálnější možné pojetí modelu – bez jakéhokoliv ošetření chyb, bez validace… Bylo by perfektní, kdyby součástí distribuce byl příklad právě nasazení řekněme Doctrine 2, a ideálně i v aplikaci s významným počtem entit (ne třeba se dvěma…) :).

Nette\Environment je možná středem Nette Vesmíru, ale osobně mi připadá, že by jím měla být spíše M vrstva.

Editoval Tharos (30. 8. 2010 0:02)

Honza Marek napsal(a):

Jestli jsem to včera dobře pochopil, tak standardizací modelu David myslí to, že přepíše příklady z dibi pro Doctrine 2.

Pochopil jsi správně :-)

rarous napsal(a):

Pokud můžu doporučit, tak se raději nějaké „standardizaci modelu“ vyhněte obloukem. M v MVC ani MVP rozhodně neznamená Data Access. A ani DAL jako takový nemá cenu nějak lámat za univerzální rozhraní. Každý konkrétní přístup k datům má svá specifika.

Víc k tématu třeba tady: http://ayende.com/…ll-fail.aspx

+1

rarous napsal(a):

Proč by měl ukázky psát/přepisovat David? To si komunita neváží jeho času, který by mohl věnovat vývoji? ;)

+1

IMO to do webovýho frameworku nepatří. Ale proč třeba neuděláte nette-contrib project, kde můžete podobné myšlenky rozvíjet, kam může commitovat kdokoli? Takový contrib project je běžnou praxí u většiny OSS projektů co znám a zdá se že to funkuje. Spousta věcí tam inkubovaných si časem našla cestu do core projectu.

MOzno by nebolo zle to mat naozaj pod addons/ORM kde by napr vzniklo par fast tutorialov ako kazdy nejak rochodit vid Panda's example pre Doctrine2

Napr

• Doctrine2
• ORmiom
• …

popr kazdy kto by si vytvoril nejaky novy a bol by schvaleny tak by sa tam mohol nachadzat, ked si k nemu napise tutorial.

A potom by si len prisiel a vybral si konkretne riesenie pre projekt.

Editoval newPOPE (1. 9. 2010 13:42)

v6ak napsal(a):

https://addons.nette.org/ ?

Já jsem měl na mysli spíš jednotný repositář nad určitou částí kvalitních a užitečných Addonů.

Editoval VeN (1. 9. 2010 14:10)

K tomuhle dobře slouží tlačítko „fork“ na githubu. Akorát by bylo dobrý, kdyby se tady na fóru občas někdo zmínil, že implementoval zajímavou fíčuru a je k otestování v tom a tom repozitáři (ideálně jako branch). Prolejzat ručně všechny forky, jestli tam neni něco zajímavýho mě nebaví.

Editoval mkoubik (1. 9. 2010 15:17)

VeN napsal(a):

Já jsem měl na mysli spíš jednotný repositář nad určitou částí kvalitních a užitečných Addonů.

Přesně k tomuhle účelu existuje https://addons.nette.org do budoucna je plánována lepší správa (stávající WIKI řešení je nevyhovující – víme to). Je plánování i nějaké to hvězdičkování ale momentálné se síly soustředí na Nette 1.0 a DOC10. (David tohle doopravdy sliboval a nemá to prioritu)

Ad GItHub fork aktuální stav je takový že forky vznikají u věcí které mají přijít přímo do frameworku a většinou k nim existuje issue na githubu nebo vlákno takdy na fóru. Řekl bych že nette/komunita zatím nedospěla do fáze kdy budou vznikat nasaditelné forky s „přidanou“ hodnotou/funkcionalitou.

Ahoj.

Vypadá to, že došlo na to čeho jsem se obával. Je 11. září, dokumentace má být hotova 19. (příp. v den představení Nette – 23./24. září) a většina z očekávaných novinek zůstává utajována veřejnosti a co hůř, i lidem, kteří je mají dokumentovat. Myslím si, že ti co dokumentovat chtějí počítali s postupným vydáváním oněch změn… Přijde mi to jako rána pod pás, co se naší dohody týče. :(

Ptám se tedy: Jak máme zdokumentovat to, co jsme nikdy neviděli a vpodstatě o tom ani nic nevíme? Příkladem budiž anotace @ajax, @allowed a @role, změny formulářů (definice, validace, renderování), NEON, nová makra v šablonách, routy, AJAX (snippety, změny URL) a další.

A kdo po tobě chtěl dokumentovat novinky? To je přece nesmysl. Psal jsem, kterým tématům se vyhnout, protože se budou měnit, vše ostatní je možné dokumentovat. A novinky rád zdokumentuju sám.

Je nějaký odhad uvedení finální verze Nette 2.0 ? Nechce se mi rozjíždět projekty na alfa verzích bez finální dokumentace. Předem díky za odpověď
Zdenek