ugrás a tartalomhoz

Ért valaki Joomla-hoz?

inf · 2017. Feb. 28. (K), 02.04
Egész konkrétan 3.4.x-ről van szó. Egy egyszerű komponens akarok lefejleszteni neki, de nem igazán jön át a routing-jának a logikája. Mintha 2 féle router lenne, egy alkalmazás szinten, egy meg komponens szinten, de a dokumentáció erről a részéről több, mint hiányos.

Az MVC részének nem tetszett a könyvtár szerkezete, úgyhogy azokat az osztályokat kukáztam, a JComponentRouterInterface, JController, JForm, JLayout részeit viszont szívesen felhasználnám. Leginkább a JForm lenne jó, ha valahogy fel tudnám használni, hogy egységes legyen az űrlapok design-ja, de a többi is jó lenne, ha nem kéne újraírni.
‹ string levágás PHP 7.1 array kezelés ›
 ■
1

Utoljára 3.0-hoz írtam

castaw · 2017. Feb. 28. (K), 10.08
Utoljára 3.0-hoz írtam komponenst, azóta talán nem változott akkorát...

Igen, gyakorlatilag két szintű routing van benne. Az első odatalál a komponenshez, innen jön a második, a komponens mappájában található router.php.

Ebben már csak a nézetet (meg az estleges azonosítót, stb-t, nem tudom mennyire bonyolult a komponensed) kell rendezni.

KomponensBulidRoute: asszociatív tömbből elkészíted a szép url-t
KomponensParseRoute: visszalakítod.
2

Köszi! Közben átgondoltam,

inf · 2017. Feb. 28. (K), 11.00
Köszi!

Közben átgondoltam, azt hiszem egyszerűbb lesz nekem úgy, ha eldobom a routert is az mvc osztályok mellett. Az mvc része nekem nagyon nem szimpi, azért inkább nem használom, az adatbázis részét is csak annyira, mint pl egy pdo-t, hogy prepared statement-et csináljak.

Jól értem, hogy a com_example/example.php valami front controller féle a komponenseknek, tehát nem arra való, hogy mondjuk middleware-t regisztráljak, vagy ilyesmi, hanem innen direktbe kiszolgálhatok kérést? Az tök jó lenne, mert akkor nem kéne ezzel a komponens router-rel szórakoznom, a nice uri meg most nem szempont, csak az, hogy működjön a komponens, és el tudjam felejteni ezt az egészet.

Annyit még tudnál segíteni, hogy vajon a com_example/views/example/tmpl/default.xml valahogy áthelyezhető az com_example/Example/presentation mappába? Tőlem utána már annyi szintig mehet, amennyit csak akar, csak rontja az összképet, hogy ott van root dir-ben plusz egy mappa csak azért, hogy menüpontot hozzá tudjak adni a site oldalon. Gondolom ha erre van lehetőség, akkor a manifest fájlban kellene utánaállítani valahogy, de nem jöttem rá, hogy hogyan...
3

Igen, úgy gondolom arra

castaw · 2017. Feb. 28. (K), 15.38
Igen, úgy gondolom arra használható, bár ennyire még nem akartam/kellett átvariálni a lelkét sosem.
4

Közben megnéztem, az

inf · 2017. Már. 1. (Sze), 18.13
Közben megnéztem, az entry-kben tényleg lehet központi tartalmat hozzáadni, meg a komponensen belüli routing-ot kezelni. Szóval viszonylag egyszerűen, mondjuk query feldolgozással meg lehet oldani a routing-ot. Nice uri-re is van lehetőség site oldalon, ha a komponensnek adunk egy menüpontot valamilyen path-en, aztán ahhoz toldjuk hozzá a path és query részeket. Annyiból ez utóbbi problematikus, hogy nem igazán van honnan elkérni, hogy milyen uri-t adtunk a menüpontnak a site odalon. A menüpont hozzáadásánál kell beírni alias-ba vagy generálja magától a rendszer, a komponensen belülről talán a felsőbb szintű router-től lehet elkérni valami alap uri-t a komponensünkhöz, de idáig még nem jutottam. Összességében végülis menni fog ez több-kevesebb tákolással. Tulképp nekem csak egyetlen menüpontra lesz szükségem, a többit a komponensen belül már meg tudom csinálni mondjuk úgy, hogy berakok bal oldalra egy menüt, esetleg accordion-t vagy ilyesmit használok. A kliens oldalon gyakorlatilag két űrlap fog kelleni összesen 3 input field-el, meg egy ezekkel kapcsolatos lista, azt meg akár még egyetlen oldalba is be tudom tenni.
5

Hát nem ajánlom senkinek az én

inf · 2017. Már. 5. (V), 20.08
Hát nem ajánlom senkinek az én utamat, teljesen lefedtem a joomla-t egy acl-el, hogy végre a komfort zónámba kerüljek, és tudjak fejleszteni. Jobban jártam volna, ha inkább duzzogva követem a joomla extension api-t, és összegányolom valahogy abban. Rövid a projekt, nem ért meg ennyi erőfeszítést.
6

Egyébként maga a Joomla API

inf · 2017. Már. 6. (H), 04.34
Egyébként maga a Joomla API egy eléggé összetákolt és rosszul dokumentált valami. Tutorial-okból meg a dokumentáció alapján próbálom összekukázni a dolgokat, de a legtöbbször csak a kódból derül ki, hogy valami miért nem működik, és mi a helyes út. Valamikor meg kiderül, hogy bugos, és dobom a feature-t, mint most a kliens oldali űrlap validálásnál elfelejtette kirakni az üzeneteket. Most éppen a jforms-al szívok, hogy validálásra bírjam szerver oldalon, de addig jutottam, hogy betölti az űrlapot, és mindenre azt mondja, hogy valid. Tulképp nagyon szeretek meglévő apikkal dolgozni, mert új apit kitalálni nagyon nehéz és hosszadalmas folyamat, de ez így nekem nagyon nem fekszik. :S Nem hiszem, hogy használni fogom még ezt a CMS-t valaha, ha nem visz rá a kényszer. Mondjuk most is kényszerből csinálom, mert ebben van az oldal, amibe beletákolom a komponensem, de mindegy. Azért ennyi szívásra korántsem számítottam vele.
7

Tanács

zzrek · 2017. Már. 6. (H), 22.52
Neked nem nagyon tudnék tanácsot adni, mert nagyon tapasztalt és igényes vagy, de most az jutott eszembe, hogy ne akarj mindig a tökéletesre törekedni, ne akard mindig a saját elveid szerint irányítani a dolgokat. Ha van egy ilyen kényszerprojekted egy olyan eszközzel, aminek a működésével előre láthatólag nem vagy megelégedve, akkor ne az legyen az elsődleges célod, hogy jobbra formáld, hanem hogy megismerd, és a saját szabályai szerint játssz. Ha mindig átalakítod a dolgokat, akkor csak a saját módszeredet tanulod meg, viszont ha alkalmazkodsz, akkor lehet, hogy ugyan nem lesz tökéletes, de legalább megismered, hogy hogyan dolgoznak mások az adott környezetben, és megtanulsz az ő fejükkel is gondolkodni. Ha ez sikerül mondjuk a Joomla-val kapcsolatban, akkor fogod megismerni a Joomlát (nem akkor, ha a magad képére alakítod, mert akkor nem a Joomlát ismered meg), és akkor mondhatod, hogy értesz a Joomlához. Egyébként erről a Varga Pál jutott eszembe :-)
http://nava.hu/id/473128/
8

Persze teljesen igazad van.

inf · 2017. Már. 7. (K), 01.28
Persze teljesen igazad van. Igazából elfedni a Joomla osztályait egy acl-el tartott 2-3 hétig, maga a projekt meg ma este elkészül, szóval olyan 1-2 napos meló. Ha nem állok neki elfedni a Joomla-t egy külön réteggel, akkor már régen kész lehetnék. Azért álltam csak neki, hogy gyakoroljam élesben a DDD-t, mert ez a projekt szívességként megy rokonnak, szóval bár cseszegetnek a határidő miatt, de tudtam húzni ameddig kell. Előreláthatólag ma este vagy holnap reggel át tudom adni. Gyakorlatilag eddig fél napot dolgoztam vele, ami a projektről szólt, és most tartok olyan 50%-nál... :D Utána majd megnézem, hogy mennyi munka az egészet Symfony-ra átültetni, meg hogy meg tudom e úgy oldani, hogy csak az acl-hez nyúlok. Többé kevésbé menni fog. Elég jól ismerem már a gondolkodásmódot, amivel a Joomla-t építették, nem tanultam sok újat belőle. Azért volt egy-két dolog, ami tetszett, az egyik, hogy az űrlapok mezőit kitették xml-be, mint viewmodel-t, a másik hogy az input-oknak adtak egy wrappert, amivel tudunk adatot konvertálni, a harmadik meg hogy path alapon töltenek be dolgokat, mint a cli-nél szokás, szóval hogy több forrás mappából keresik ki, hogy valahol jelen van e a fájl. Persze vannak elnagyolt részek is benne tervezési hibákkal, amiket most nem részletezek, mert hosszú lenne. Egyébként szerintem képtelenség tökéletes kódot írni. Próbálgattam saját keretrendszereket készíteni ilyen-olyan célra, és mindegyiknél a végén beleütköztem valami olyan logikai gátba, amit nem lehetett megoldani. Szóval az esetek 99%-ában jól működik a kód, de ha valami nagyon extra dolgot kérsz tőle, akkor biztosan törik, vagy a végeredmény workaroundokkal teli ocsmányság lesz. Ennél a Joomla-nál is vannak határok, amire nincs felkészítve, ezek mondjuk inkább feature hiányból fakadnak, mint logikai hibából. Pl nem lehet több rule-t hozzárendelni egy field-hez, de ez megoldható pl egy composite rule definiálásával. Ezen kívül van az, hogy egy űrlap csak egy entitás adatait tudja lekezelni, és nem tudom megcsinálni vele azt, hogy mondjuk egy teljes listát betöltök, és egyszerre több felhasználó adatait módosítom ugyanazzal az űrlappal táblázatos formában. Legalábbis beleástam magam a JForm kódjába, és nem találtam benne ilyen részt. Van ötletem workaround-ra, de egyelőre ez sem prioritás most. Ha érdekelne a projekt sorsa, tudnék mit contributolni hozzá.

A filmet sajna nem játssza le, pedig jó lenne lazításnak. :D
9

Mégiscsak megérte, kezdek

inf · 2017. Már. 9. (Cs), 03.16
Mégiscsak megérte, kezdek ráérezni a DDD ízére. :D

régi kód:

suspension = customerRepo.findSuspensionById(suspensionId);
suspension.setInterval(intervalManagement.reschedule(suspension.getInterval(), from, to));
customerRepo.saveSuspension(suspension);
új kód:

customer = customerRepo.findSuspensionOwner(suspensionId);
suspension = customer.getSuspension(suspensionId);
suspension.reschedule(from, to);
customerRepo.save(customer);
Most már sajna nincs időm refaktorálni, de valami ilyesminek kellene lennie egy app service-ben, meg persze a tranzakció kezelésnek. A save részét egy komolyabb rendszerben meg unit of work csinálja gondolom, de egyelőre még ezt a gondolkodásmódot is szoknom kell.

Ahhoz képest, hogy mennyire egyszerű projekt a date range-ek tervezése erősen megdolgoztatja az agyat, belefutottam egy csomó olyan problémába, amire nem számítottam. :D Ilyenkor érzem, hogy jó kódolni! :D