User moduly ala Wordpress

Ginny

Ahoj, jak je to momentálně s User moduly/pluginy do nějakého malého cms? Řešil už to někdo? Četl jsem starší topic, kde se Nette guru bavili o tom, že by se něco takového mělo dát dohromady pořádně, ať všichni neobjevují kolo (což je tu docela běžné), takže v jaké fázi to je?

pepakriz

Ukázka modulu do Venne: https://github.com/…/PagesModule.
Kdyby obsahuje balíčky: https://github.com/…dyby/Package

Obojí už používá nejnovější DI, ovšem nevím, jestli to splňuje požadavek malého CMS :D

Ginny

Moc diky Pepo za odkazy, uz studuju i Venne CMS :-) Ano, asi se to navzajem vylucuje :-D ja jenom, ze vetsinou chce kazdy zakaznik neco jineho, tak jsem chtel mit tenky zaklad, do ktereho vzdy nasazim moduly, co jsou zrovna potreba. Jeste jednou moc diky :-)

pepakriz

O to se též snažím, bohužel i ten tenký základ představuje kus nemalého kódu :D

frosty22

Též se teď zajímám o podobnou problematiku, sice tedy nepotřebuji příliš univerzální řešení, ale dost mě zajímá jak WP, Magento, apod. řeší právě ony modularizace, ideálně bez zásahu do aplikačního kódu, čili čistě separátně. Díval jsem se na hosiplanovo Kdyby a Packages a vypadá to zajímavě, leč tedy jsem to zkouknul jen letem světem, tak by mě zajímal smysl a použitelnost jeho řešení? Asi náhodou nebylo by možné prozradit, abych nemusel zkoumat source?

Filip Procházka

Použitelnost je výborná ;)

Balíček si hodím kamkoliv do projektu a nastavím autoloading. Pokud používáš Composer, tak dokonce ani nebudeš muset zjišťovat jak nastavit autoloading.

Každý balíček je pak taková malá aplikace se svým vlasním životním cyklem. Ve správný moment se volají jednotlivé metody a můžeš se tedy „napíchnout“ ve správný moment, kam potřebuješ. A samozřejmě to kamarádí s rozšířeními compileru.

Lopo

ja som v Lohini mal zacaty Plugins system … bolo to vsak stavane na starsom (pre-final) nette, ale princip by mal byt pouzitelny stale

teraz som si portol packages z kdyby, avsak plugin system budem tiez pouzivat nadalej – packages budu na systemovejsie veci a plugins na jednoduchsie

moj plugins system mal vyhodu, ze nebolo treba nic upravovat v config-och, bootstrape a pod., proste sa plugin nahral na prislusne miesto/a, cez administracne rozhranie sa potom zaregistroval, nainstaloval, nastavil a povolil k pouzivaniu

niektore drobnosti som nemal dotiahnute … niektore mi viacmenej vyriesi prave pouzitie packages … niektore este dotiahnem …

co sa tyka magento systemu, tam sa mi pacilo akym vlastne sposobom sa do beziaceho systemu dostavali dalsie pluginy – download z remote uloziska cez hash kody – nad niecym podobnym som tiez uvazoval, ale nakoniec mi to prislo pouzitelne az pre systemy velksti/rozsirenia ake ma prave magento takze som sa na dalsie pitvanie a pripadne portovanie vykaslal

newPOPE

Pozeram, ze sa tu stale dokola riesi „modularnost“ a tak podobne. Pravdupovediac nikdy som poriadne neskumal vsetky veci Kdyby, Venne, Nella, Lohini… Je toho na mna vela :-).

Tak mam len jednu otazku, ako riesite napr. rozsirenie formulara? Ci uz pomocou modulov, balickov, plugins…

Example:

X obsahuje formular na registraciu.
Napisem (plugin, package,…) ktory neupravuje jeho spravanie LEN prida jeden input a doplni si callback sam na seba napr.

Mam pocit, ze toto bez nejakeho EventDispatchera nejde tak za to sa pytam aby som si mohol pozriet aj ine riesenia.

pepakriz

newPOPE napsal(a):
Mam pocit, ze toto bez nejakeho EventDispatchera nejde tak za to sa pytam aby som si mohol pozriet aj ine riesenia.

Ve Venne mám základní registrační modul, který vyžaduje jen email a heslo (viz http://demo.venne.cz/registrace). Pokud mám stavět nějaký web, udělám si modul, který obsahuje šablony, widgety, componenty,… a také bude obsahovat poděděný formulář na registraci s doplněnými inputy. Samozřejmě, že by šlo udělat nějaké propojení pomocí událostí, to je pak na každém, jak mu to bude vyhovovat. Právě rozšiřování formulářů pomocí událostí mám udělané u vytváření obsahu, kdy třeba modul pro komentáře doplní do formuláře stránky input pro povolení komentářů, podobně pak modul navigace přidává inputy pro vložení odkazu,…

frosty22

Ono kdyz nad tim tak premyslim, tak v podstate univerzalni reseni na tohle nemuze ani existovat, preci jen modul muze mit potrebu implementace na ruznych mistech. Osobne tedy premyslim nad moznosti, kde by byla tedy dana pevna adresarova struktura pro moduly, napriklad:

Modules
- Foo
--- templates
----- default.latte
----- next.latte
--- models
----- foo.php
----- bar.php
--- controllers
----- control.php
--- config.neon
- Bar
--- templates
.......

A tedy naprosto separatne od app, v podstate jako komponenty ale s tim, ze by meli vlastni nastaveni pres neon pripadne xmlka. Znamenalo by to vsak vytvaret DI kontajner na zaklade techto modulu a konfigurator by se zmergoval ze vsech techto konfiguracnich souboru. Zaroven tedy prave museli byt vytvoreny nejake eventy v aplikacni vrstve, kterou by ty moduly mohli ovlivnovat. A tedy moznosti modulu by byly ovlivneny prave rozsahem eventu v aplikaci. Zaroven bych asi napriklad databazovou vrstvu resil necim jako entity v doctrine, aby tedy slo definovat model, jeho property a pri instalaci modulu by se podle definice v tomto modelu vytvorilo uloziste, u databaze tedy tabulky.

Zajimalo by me vsak zdali by mi v tomto pomohl hosiplanovi packages. Omlouvam se zatim jsem se jeste na api tech packages nemel cas hloubeji podivat.

Editoval frosty22 (31. 3. 2012 21:47)

frosty22

Koukám ona implementace modularizace ve Venne je taková jako jsem si představoval :)

Filip111

A jak řešíte update databáze v modulech?
Začínám také pomalu řešit, jak aplikaci rozdělit na balíčky nebo alespoň moduly (zatím to mám postavené na admin a front, ale postupem času se to ukazuje jako špatná cesta).

Nicméně zpět k databázi – sql scripty pro vytvoření a změny db mám společné pro všechny části aplikace. Jednotný script pak provede update libovolného mého webu do aktuálního stavu. Cenou za to je, že i malá prezentace o 15-ti stránkách má v databázi tabulky všech modulů…asi 150 tabulek a to už je dost trapný.

Nedovedu si to ale představit rozdělit na balíčky – případně to nějak spojovat nebo updatovat každý balíček zvlášť.

Jak tohle řešíte?
Díky.

Lopo

@Filip111: tak ja som to mal v pluginoch riesene pomocou doctrine migrations – dokazal som pomocou toho robit normalne update pluginu aj jeho odinstalovanie

frosty22

Databáze je jen úložiště dat, čili i každý modul může mít své úložiště zvlášť – čili lze tabulky v databázi též modulovat například v podobně entit. Například tabulka s komentáři lze odpreparovat od celkového systému, a pouze v případě, že se přidá tento modul, se vytvoří.

Takto lze logické funkce oddělit s tím, že každý modul tedy má své závislosti. Ony komentáře nepůjdou například nainstalovat pokud nebude existovat modul pro články. Tímto tedy by se měla udržet i integrita databázové struktury.

frosty22

@Lopo: S Doctrine mám zkušenosti pouze s verzí 1.3 a tedy musím říci, že k tomuto nástroji jsem necítil moc sympatie – sice ORM hezké, ale práce s ním byla relativně krkolomná, leč tedy Doctrine 2 již je jistě jiné kafe. Jen si říkám zůstat u Nette/Database, na které je již člověk dost zvyklý, ale simulovat přes něj „entity“ a mini"ORM", které by dokázalo alespon potřebné minimum je takové znovu vymýšlení kola ;(

Filip Procházka

@frosty22 Doctrine 2 je něco úplně jiného a kompletně přepsaného. Ale to je vskutku na jiné téma. Pokud tě zajímá, stav se na #nette jabber, nebo si založ téma :)

Filip111

Rozdělit databázi po modulech určitě půjde – blbě jsem se vyjádřil.

Ale jak to potom spravujete, když třeba po pár měsících děláte update webu a přidáváte změny. Moduly jsou již po té době někde jinde, v tabulkách každého modulu spousta změn (nové sloupce, tabulky) a jak teď uděláte update? Každý modul zvlášť? Nebo automatizovaně zjistíte jaké moduly jsou nainstalované a uděláte update jen jich?

V Doctrine asi pomůžou migrations, ale jak to řeší ty co Doctrine nepoužívají?
(Odpověďi přejít na Doctrine :) nepočítám. Přejít jsem chtěl, ale nedokázal jsem přepsat do entit vícejazyčné objekty nebo zprovoznit Gedmo).

Filip Procházka

Čistě mezi námi děvčaty, Gedmo je sračka.

Napiš si vlastní migrace, nějaké blboučké, to přeci není problém, ne? :) A pokud je pak publikuješ na githubu tak ještě lepší!

awsickness

ja jsem udelal package system ciste na zaklade config / extension kvuli firemnim zvyklostem. takze ted staci pridat jeden radek do configu a uz se to cele samo pripravi. a muzu to rovnou pouzivat v applikaci.
ono je rozdil kdyz delate neco pro jeden projekt a kdyz delate neco dost jako obecne pouzivani a zpetne rozsireni.
me osobne vyhovuje mit package na nem naveseny jednu extension ktera registruje vse potrebne a tim je vse hotove.