kód portolása symfonyra

[connorhu]

175 után a következő lehet. mivel a #176 PR integrálni fogja a symfony-t így felmenő rendszerben portolni lehet a kódot.

teendők:

• [ ] authentikáció. mivel a régi kód egyszerűbb, javasolt a symfony auth mechanizmusát felhasználni. meg kell vizsgálni, hogy a container mennyire hozzáférhető, rá lehet-e bízni az authentikációt/authorizációt teljesen a symfonyra
• [x] házirend oldal portolás
• [x] gdpr oldal portolás
• [x] about oldal portolás
• [ ] user edit portolás
• [ ] user list portolás
• [x] saját adatok megtekintése
• [ ] saját adatok szerkesztése
• [ ] saját kedvencek listája és törlése
• [x] login oldal portolás
• [ ] új jelszó mechanizmus portolás
• [x] regisztráció portolás
  • [ ] adatbázis alapú levélküldés
  • [ ] dev/test esetén mailcatcher
• [ ] új templom portolás
• [ ] templom lista portolás
• [ ] templom view oldal portolás
• [ ] templom észrevétel portolás
• [ ] térkép portolás
• [ ] főoldal portolás
  • [ ] random doboz
  • [ ] kedvenc templom doboz
  • [ ] random templomok a kedvencek helyén
• [ ] magyar webcímek definiálása, átirányítás a régiről az újra.
• [ ] kereső portolása

momentán ennyi jut eszembe, majd még bővítem

[borazslo]

Ha jól értem, akkor pl. a miserend.hu/stat oldalt, ami statisztikákat hoz, úgy kell portolni symponhyra, hogy

A legacy_routing -ba $simpleLegacyRoutes tömbbe beteszek egy 'stats' => ['/stat', Html\Stat::class], -t.

De hosszabb távon / szebben, úgy lenne az igazi, ha lenne egyController/StatController.php a mostani UserController mintájára: abban lehet definiálini a route-t és a return kell legyen a kész html kód. ( És akkor talán nem is kell a legacy_routing-ban ezzel törődni.)

Kb. jó felé keresgélek?

És akkor rögtön a következő: a legacy_routing definiálja a church_remarks-t csakhogy abból három van, három féle "action": list, addForm, add . Akkor hogyan lehet ennek a háromnak megcsinálni a route-ot?

• Talán az egyik, hogy kicsit bővíteni a $complexLegacyRoutes -t és akkor a new Route(defaults: []) -ba belekerülhetne az "action" értéke mind a haáromnál. Nem túl elegáns, de működne, nem?
• Szebben pedig talán az lenne, ha Controller/RemarksController.php és ott három function a list/addForm/add -nak megfelelően.

Kb. jó felé olvasgatok?

[connorhu]

Hosszabb távon minden régi kód kukázva lesz és nem lesz legacy routing sem. Azt csak azért hoztam létre, hogy ne egyszerre kelljen megugrani a minden átírását. Ahogy haladok a régi kód átnézésével és javítgatásával illetve minimális modernizálsával, úgy fogod látni, hogy mit tekintek legacy-nak és mi az új szisztéma. A minek a nevében vagy az útvonalában legacy van az el lesz dobva.

[connorhu]

Még valami. A symfony ahogy látod külön definiál route-ot és nincs összekapcsolva se fájlnévvel se metódusnévvel a route. Ez azt jelenti, hogy lehet szebb magyarabb elnevezéseket adni. Ezzel azért kell óvatosan bánni, mert a search crawler botoknak (google és társai) is meg kell mondani hol keressék az újakat és frissítsék az indexeiket. Tehát majd definiálni kell egy listát (vagy egy LegacyUrlRedirectionControllert) arról, hogy mi mire fordult át. (templom címében pl szerepelhet az url safe neve is: https://miserend.hu/templom/5028/szent_domotor_templom ) Hova tovább az url-ek lehetnek nyelvfüggőek is. Lásd: https://symfony.com/doc/current/routing.html#localized-routes-i18n

[borazslo]

Akkor tehát a cél hogy a legacy cuccokkal működésre bírjuk mindazt ami eddig működött. És akkor mergelhető lesz és utána szépen sorjában kiiktatunk minden legacy-t, hogy legyen modern boldogság. Remek.

Ez a https://miserend.hu/templom/5028/szent_domotor_templom dolog teccetős. És kb. minden fajta url-t meg lehet változtatni, de kritikus fontosságú, a /templom/12343 és még a /?templom=234234 formátum megőrzése. Az OSM adatbázis és bárhol ahol az elmúlt tíz évben linkeltek minket ott ezek vannak. És ezt egészíthetjük ki az új 'csicsás' csodákkal. ja meg az API endpointokra is vigyázni kell, mert itt-ott használják.

Izgi

[connorhu]

API endpointokra is van már tervem: /api/v2/... prefix és kicsit apisabb kommunikáció. Illetve API kulcs és JWT token alapú azonosítás, ahol szükséges. A régi címek megőrzése és 301-es átirányítás amíg hivatkoznak rájuk az alap, persze.

[connorhu]

Egyelőre szerintem az url-eket szedd össze és azzal ne foglalkozz, hogy tartalom nem jelenik meg, első körben az lenne a lényeg, hogy oldal nem található üzenet ne legyen. Nálam várakozik már egy nagyobb fejlesztés a legacy-n ami logikusabb mederbe tereli a régi kódot is.

Tettem fel egy mintát arról, hogy a symfony hogyan képzeli el a controllert. Igyekszem a hiányos részeket todo megjegyzéssel ellátni. Nézd meg és tedd fel a kérdéseidet :)

[connorhu]

https://github.com/borazslo/miserend.hu/issues/174#issuecomment-1915659537 "De ezzel most ne törődjünk, működjön ami jelenleg van és akkor haladhatunk előre."

Most két dolog történik párhuzamosan:

• a régiből próbálok varázsolni egy minimálisan logikus rendszert
• egyszerűbbnek tűnő felületeket, funkciókat átrakok symfony alá

Az első pontban most nagyjából három-négy főbb változtatás történik. 1) routing bevezetése. Ezt már láttad, a legacy route fájlba kell felvenni az összes útvonalat ami kívülről hívható, különben az oldal nem található. Annyit megcsináltam itt pluszban, hogy ne a konstruktor-ban legyen minden logika. Különüljenek el a különféle al funkciók (most talán "action" néven futnak). 2) container bevezetése. Ez tulajdonképpen egy okos tömb, ami tárol szolgáltatásokat. Szolgáltatás az, aminek a funkcióira valaki más támaszkodik. Adatbázis szinten ez kicsit problémás, mert ott ahogy láttam singleton logika van és bárhol, mindentől függetlenül hozzá tud nyúlni az adatbázishoz bárki. A config és a user globális változók viszonylag könnyen behatárolhatók és átültethetők arra az osztályra amit megcsináltam hozzá. 3) view és az üzleti logika közötti határ elválasztása. Ez azt takarja, hogy amit a twig megkap, az egy ponton, tömbből képződjön és ne egy object=>array castolás legyen, ami követhetetlenné teszi, hogy ki és miért kerül át a view-ba. 4) üzleti logika request osztályon keresztül kapja meg az adatokat és response választ adjon. Itt az a probléma, hogy a jelenlegi request osztály csinál form validációt is és az igazából egy külön feladat lenne. 5) bootstrap5-re portolás 6) frontend javascript kódok megszabadítása jQuerytől és valami értelmezhető egységbe tömörítése

Ezek bármelyike alaposan felbolygatja a rendszert, így együtt azért rendesen használhatatlanná teszi néha a kódot. Amíg ezeken molyolok többé kevésbé megismerem a rendszert. Mivel ez nem megy egyik napról a másikra, ezért közben van idő bizonyos funkciókat úgy átültetni, hogy a régi logikát felfrissítsük. Ezért kérdeztem, hogy mit szeretnél, mert az átírás közben nagyobb munka a rossz üzleti logikát portolni rosszul aztán később átírni, mint élből úgy portolni, hogy a rossz logika ne kerüljön át.

[connorhu]

(7. Mindeközben egyébként E_ALL error_reporting mellett próbálom használni az oldalt, hogy kiderüljenek a kódolási lazaságok.)

[borazslo]

Ezek bármelyike alaposan felbolygatja a rendszert, így együtt azért rendesen használhatatlanná teszi néha a kódot. Amíg ezeken molyolok többé kevésbé megismerem a rendszert. Mivel ez nem megy egyik napról a másikra, ezért közben van idő bizonyos funkciókat úgy átültetni, hogy a régi logikát felfrissítsük. Ezért kérdeztem, hogy mit szeretnél, mert az átírás közben nagyobb munka a rossz üzleti logikát portolni rosszul aztán később átírni, mint élből úgy portolni, hogy a rossz logika ne kerüljön át.

Ezt teljesen értem. És örülök is neki. Hogy ha már átírás, akkor most érdemes dolgokat megcsinálni, mert úgyis csak ... Annyi pici félelem van bennem, hogy ne legyen az, hogy a sok újraépítés addig hízzon, hogy soha nem indul újra a dolog. :D De bízom benned.

No ha van lehetőség rossz logikákat kiiktatni, akkor bedobom a két legnagyobb bombát, aztán meglátjuk hogy mit lehet / érdemes vele tenni, de szerintem középtávon nagyon egyszerűsítik a kódot és a működést, és stabilabb is lenne minden. Meg használhatóbb.

A) A miserendek adatstruktúrájának borítása.

A mostani azért egyszerre túl komplex és ügyetlen. Aminek örülnék az kb. az, hogy egy-egy templomnak a teljes miserendje egy nagy string (és nem sok-sok sor különféle táblákban), ahol diff segítségével lehet nézni a különbségeket a verziók között. Azaz a) be lehet küldeni módosításai javaslatokat, amik egyetlen kattintással élesíthetőek. b) Megőrizzük a múltat: amikor mentjük akkor az előző régit archiváljuk, az újat élesítjük. Így egy kis diff-el bármikor könnyű átlátni, hogy mi van. Ezen már naaagyon régen gondolkodom. A #144 -ben próbálom érlelni a lehetőségeket a sok év tapasztalata alapján. Itt tartok most: https://github.com/borazslo/miserend.hu/issues/144#issuecomment-1915759145 Persze lehet xml helyett más, de elég jónak tűnik a formátum az egység és mégis sokféleség őrzésére. (És létezik xmldiff.)

Aztán minden változásnál ill. cronban naponta legyártjuk a szabály szerint a következő három hétre a konkrét miséket dátummal időponttal. Ez azért is jó, mert ha a miserendhez egy templom ical-t is megad, akkor a következő három hét legyártásánál azt vesszük figyelembe és nem az xml szabályt, ami "csak" leírja az általános dolgot. Így még jobbak lehetünk.

A keresőnek tök könnyű dolga lesz mert a konkrét_misék táblát pörgeti csak a templomok táblával join-ban. És soookkal stabilabb és egyszerűbb a motor.

Ha van rá esély / érdekes lehet, akkor szívesen pontosítom a specifikációt / adatstruktúrát amit látok.

B) OpenStreetMap OSM integráció

Az álom az lenne, hogy minden templomi saját adat az OSM-el legyen két irányú szinkronban. A miserend, a felelősök, a javaslatok, stb. csak amik "sajátok" a saját adatbázisban. Ez elkezdődött azzal hogy pl. az akadálymentességi adatok szinkronizálva vannak. A koordináták is.

De a lokációval van most gáz van, mert lehet hogy időnként a régi sajátot használjuk (templom.varos, templom.megye és ilyenek) máskor pedig az OSM boundary-t. Sok a rendetlenség.

Az ideálisban az lenne, hogy van egy templom.id = osm.type-osm.id összekapcsolás. Aztán cronban ill. editkor lehúzzuk az OSM-ről az összes adatát és módosításkor azokat visszatöltjük. A jó kereshetőség miatt kell a templom.name, templom.alt_name, stb. oszlopok, de ezek csak gyorsítás miatt. (Tehát lehet külön tábla, hogy egyértelmű legyen hogy ez egyféle cache).

Annyi nehezítés van benne, hogy a kiírandó név például úgy jön létre, hogy ha van az osm-ben name:hu, akkor az legyen a név, ha nincs akkor a name. Magyarországi templom esetén a szerkesztő felületen a name jelenik meg módosíthatóra és a name:hu csak akkor ha ki van töltve. Országhatáron túl mindig megjelenik a name és a name:hu mező is, valamint ha van kitöltve akkor talán lenyithatóan a többi name:XX mező is. Ugyanígy az alt_name és alt_name:hu -val (ez az ismernévvel egyenlő.)

Az egyes templomok területi beosztása ((vár)megye, ország, egyházmegye, espereskerület) ennél is bonyolulatabb, de nem végtelenül. Ott a templomnál feltültetésben úgy kell, hogy HA van saját diocese tagja, akkor az jelenik meg. Ha nincs, akkor a közbenfoglaló (boundary) területekből kerese ki az egyházmegyét (boundary_religious, roman_catholic, level=6 talán) és annak a name:hu értékét, vagy ha az nincs akkor a name értékét mutatja meg. Szerkesztői felületen a boundary alapján megtaláltat mutatja amennyiben van (az nem változtatható). És szerkeszthető a saját diocese mezője azzal a felkiáltással, hogy "Ha nem találtunk terület alapon egyházmegyét, vagy valamiért a megtalált egyházmegyétől eltér ez a konkrét tepmlom (enklávé) akkor szövegesen megadhatja az egyházmegyét helyi elnvezéssel." És kell erre a mezőre törlés opció, mert idővel ki szeretne iktatódni az összes, de az még sok OSM térképeszeti határhúzos feladat. (Magyarországon belül már minden rendben.)

Hogy látod?

+1 Ha az segít akkor a legacy dolgokba tudok kommentárokat fűzni, hogy mi volt az intended használat és akkor könnyebb értelmezni a katyvaszt.

[connorhu]

Ezt teljesen értem. És örülök is neki. Hogy ha már átírás, akkor most érdemes dolgokat megcsinálni, mert úgyis csak ... Annyi pici félelem van bennem, hogy ne legyen az, hogy a sok újraépítés addig hízzon, hogy soha nem indul újra a dolog. :D De bízom benned.

Hogy látod?

Napi 1 órám van ezzel molyolni, szerdán 4, hétvégén még egy kicsi. Ez idő alatt ha nem is holnapra, de azért apránként el lehet jutni az összes teendővel. A célom most az, hogy minden legacy részhez hozzányúljak és lássam, hogy ott mi történik, a felvázolt egységes mederbe tereljem a kódokat. Ha a kezem alá tudsz dolgozni akkor nem akadok meg olyan kérdésekkel, hogy két tábla között mi a reláció és a portolás pillanatában tudom, hogy itt mi a teendő.

Te wikioldalak írásával tudnád segíteni az egész folyamatot. Kezdve mondjuk az adatbázissal.

tábla: mit tárol, relációja a táblákkal, issue-t létrehozni/linkelni ha van vele teendő (ez kicsit összekapcsolódik a funkcionális tervvel is) mező: mit tárol, típus, méret, lehetséges értékkészlet

Ha ez kész, akkor rá lehet kanyarodni a funkciók dokumentálására (egyfajta funkcionális tervet készíteni), hogy le legyen írva, hogy most melyik rész mit csinál, kik láthatják. Itt lehet felsorolni az adott részt érintő issue-kat. Párhuzamosan a hiányzó "ezzel mit szeretnénk kezdeni" kérdésekre létre kell hozni önálló issue-t és ott kidolgozni az igényeket és hozzá kitalálni ezt hogyan valósítsa meg.

[borazslo]

Elkezdtem. Egy táblát meg is írtam. Így gondoltad, jó az irány? https://github.com/borazslo/miserend.hu/wiki/Adatstrukt%C3%BAra

[connorhu]

Igen, a formátum jó, de a meglévő táblákkal kellene kezdeni. Ha már ezzel a táblával kezdted, akkor a táblához kapcsolódó issue-kat is összeszedegethetnéd (ami meg abban segítene nekem, hogy nem kéne visszamenőleg átolvasni az 56 nyitott issue-t).

[connorhu]

Info: megtaláltam a módját annak, hogy a symfony és a régi kód teljes békében élhessen egymás mellett.

• A symfony kap el minden hívást és csak azokat továbbítja ahol a LegacyBridge a controller. Így kb a régi oldalt becsomagoltam a symfonyba. Ezzel a megoldással viszont minden symfony service-hez hozzá tud férni a régi site amihez hagyom.
• Minden régi kódot besöpörtem a Legacy mappába.
• Az authentikációt és authorizációt már a symfony végzi (a role-okat még át kell migrálni). Így most a usereket minden kódban át kell dolgozni kicsit. Ez a giga user-wrapper osztály egyébként is nagyra nőtt, célszerű fogyókúrára küldeni.
• Elkezdtem pár dolgot szépen kifésülni és felvenni az entitásokat és abban definiálni a mezőket.
• Megcsináltam az első api kliens-t (közösségek).
• Ahogy haladok a régi kódok átnézésével, lesz újra használható az összes funkció. Nagyrészt csak apróságokat kell javítgatni rajtuk, szóval nem vészes.
• Van már ötletem arra is, hogy hogyan fogom egyszerre a régi és az új api hívásokat kiszolgálni.

[borazslo]

Akkor WIKI-ben ott van már a user és a remarks tábla is. Abban van szó a role-okról is.

[borazslo]

No, a misek tábla is megvan. Gondoltam azt is érdemes hamar, mert jó sok furcsaság van benne.