[Erdeklodes] Webes alkalmazas TrinityCore - hoz

Indította Shyro, 2015 szeptember 22, 04:17:22 DÉLUTÁN

Előző téma - Következő téma

Shyro

Sziasztok!

Nem vagyok biztos benne, hogy el e meg a forum annyira, hogy egy ilyen jellegu kezdemenyezesnek legyen lathato eredmenye. De egy probat meger. Eleg regen jartam mar en is erre, de a mai nap folyaman raneztem a TrinityCore forumara es egy egesz erdekes projektre bukkantam:
https://github.com/ShinDarth/TC-JSON-API (kesobb reszletezem)

Mar regota gondolkozok azon, hogy mind az adatbazis muveleteknek kellene adni egy plussz reteget, mind a szerverek uzemeltetesere jo lenne egy alkalmazas, ami leegyszerusiti, plussz ellenorzeseket tesz es megkonnyiti a munkat a nagy mennyisegu adaton. Ezalatt konkretan egy feluletre gondolok, amin keresztul egyszeruen lehet rutin es nem rutin muveleteket vegezni.

Mar szuletett sok projekt, amelyek egy egy folyamat megkonnyiteset celoztak meg, valamilyen alkalmazassal - pl. NPC - k letrehozasara, ticketek olvasasa -, viszont ezek kulonbozo technologiakkal, mas mas minosegu munkaval ertek el ezt. En ezeket tartom erdemesnek egybeolvasztani egy webes alkalmazas kereten belul.

Ami nagyon hianyzott ebbol egy jol definialt API, amin keresztul elerhetok az adatbazisban tarolt adatok, autentikacio, egyeb funkcionalitas. A fenti link alapjan ugy tunik mar nincs olyan messze, sot, a szukseges funkcionalitasnak egy resze elerheto. Ez elegge jo alapot ad az olyan elkepzeleseknek, mint amilyenrol fentebb irtam.

A forumra azert irtam, hatha akadnak meg itt olyanok, akik adnanak a dologba, akar otletekkel, akar technologiai javaslatokkal, velemennyel. Magamtol meg azt sem sikerult felmernem, hogy van e igeny egy ilyen alkalmazasra. Azt latom, hogy sok kis apro program mar szuletett es pont emiatt ugy is hiszem, hogy ezek alkothatnanak egy egyseget, egy minoseget es feluletet.

A megvalositas kerdeset is nyitva hagyom, en szemely szerint a webre mint platformra szannam a cuccot, illetve single - page application - kent valositanam meg. Akar meg arra is vevo vagyok, hogy szetbontsuk az egeszet microservice - ekre, amelyek mint komponensek epulnek bele az alkalmazasba, de ez komplexitasfuggo. (Az API reven erre is lehetoseg van)
A fenti megvalositas mellett az ervem az az, hogy megerett mar a web arra a szintre (mar korabban is, viszont most open-source eszkozokre gondolok), amivel egy ilyen kaliberu projektet kivitelezni lehet.

Azt mindenkeppen nyomatekositani szeretnem, hogy webes alkalmazas alatt nem HTML kod faragasara gondolok, vannak mar hasznalhato keretrendszerek, fejlesztoi eszkozok, stb., amelyekkel egy komoly szoftvert lehet alkotni.

A single - page application mellett pedig az szol, hogy nem weboldalt szeretnek faragni, hanem egy alkalmazast. De ezekrol is tartom, hogy kerdesek, amelyeket a topic - ban megvitathatunk.

Varom a hozzaszolasokat,
Shyro

makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Nem sok értelmét látom a dolognak, mert:

1.
- Webes felületnek ott a PHPmyadmin tökéletes a feladatra, úgy ahogy secure is de ezt egy .htaccess-el el lehet intézni biztosra.
2.
- Aki tényleg komolyan neki kezd a DB foltozgatásának az inkább használjon valami DB kezelőt ahol el lehet menteni a scripteket. / Smart_AI editorból pedig nagyon jók vannak már most is.

Shyro

@eztcsekk:

A phpMyAdmin teljesen mas feladatkor megoldasara alkalmas, bar en arra sem szivesen hasznalnam. Nem adatbazis, tablak karbantartasara, vagy lekerdezesek futtatasara szeretnek alkalmazast, ezekre megvannak a megfelelo eszkozok.

Azok az eszkozok amik mar megszulettek (pl. a smart_ai szerkeszto, amit emlitettel) egy egy feladatot oldanak meg. Akkor nekem, mint szerver uzemeltetonek ha szuksegem van mindre, akkor telepitsek/toltsek le/huzzak fel N darab programot, amik akar teljesen eltero technologiara epultek? Nekem ez nem tunik hatekony megoldasnak, foleg, hogy a jelenlegi eszkozok kozel sem fedik le azt a mennyisegu feladatot, amit erdemes lenne (szerintem) kiszervezi egy alkalmazasba. Pedig, mint Trinity Utilities mar jo par eszkoz letezik RBAC Manager - tol kezdve a Ticket Viewer - ig. Ezeket mind masok, maskepp tartjak karban, vannak amelyekre mar ra se neznek, nem kovetik a valtozasokat. Meg ha adott feladatot meg is oldanank, adott szerver uzemeltetonek nem nyujtanak egy kenyelmes, egyseges megoldast.

En siman el tudom kepzelni a kovetkezo forgatokonyvet is: Szeretnem elolvasni a felgyulelmett ticket - eket, lehet hogy tobb szaz van, szeretnek bennuk keresni, osztalyozni oket, szeretnem atruhazni vagy kiosztani masokra a ticket - ek kezeleset, akar a ticket - et kuldo jatekos adatait, vagy a rola keszult logot szeretnem megtekinteni. Mar egy ilyen egyszeru dolognal is a lehetosegek szama rengeteg, hogy mennyi funkcionalitasra lehet szukseg.

Jelenleg ezt vagy nem tudom megoldani, vagy a DB - ben kell turkalnom vagy bejelentkeznem a jatekba, amelyek kozel sem jo megoldasok, sot, nem is megoldasok, csak valami ad hoc reagalas.

Nem tudnam osszeirni az osszes forgatokonyvet, ami egy megfelelo eszkoz eseten kialakulhat, mert nincs ilyen eszkoz, de el tudnek kepzelni egy olyan projektet, ami megprobal ezekre egy egyseges megoldast nyujtani.

makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

Shyro

Itt egy osszefoglalo a TrinityCore - s Rest API - rol, ami az aktualis allapotot tukrozi:
http://community.trinitycore.org/topic/11350-trinitycore-json-restful-api/?do=findComment&comment=75903

Korrekt amiket terveznek, illetve ok is hasonlokeppen kepzelik felhasznalni az API - t.
Irtak nehany single - page application - t AngularJS - ben. Meg nem neztem meg oket, de jol peldak es kiindulopontok arra, amire en is gondolok.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

AximCore

Ha jól értelmezem akkor egy olyan API-t akarsz amin keresztül mindent lehet kezelni ami DB-n keresztül lehetséges vagy esetleg bizonyos dolgokat már az API kezelnél az emu helyet ? Amúgy egy jó ötlet csak nem hiszem, hogy itt Mo-n lesz elég támogatásod, meg lehet jó lenne ennek Shin-nek felvetni az ötletet és együtt vinnétek a dolgokat tovább. 
"Tanítani lehet az ostobát, de gondolkodásra bírni nem."
A Talmud

Windows Firewall
http://devopsreactions.tumblr.com/

Why use Windows, if you have open doors... to Linux

Shyro

@AximCore:

Igen, az API - n Shin dolgozik, annak fejlesztesehez is elkel a segitseg. Azt fejlesztgetni sem egy rossz dolog, viszont amire en gondolok az az API felhasznalasa. Ok elso sorban arra gondoltak, hogy az API altal sok kis alkalmazasnak biztosithatnak egyseges feluletet a DB - ben tarolt adatok lekerdezesere/szerkesztesere/torlesere es kiegeszitesere. Innentol kezdve, ha van egy ilyen reteged az adatbazis felett azt kezdesz vele amit akarsz.

A fenti peldara ("forgatokonyvre") visszaterve, a ticketeket lekerdezheted az API - n keresztul, de attol meg nyilvan nem fogod tudni oket konnyebben feldolgozni. Viszont irhatsz ra egy sajat alkalmazast, ami kepes a ticketeket osztalyozni (critical/minor/major/stb.), vagy egy egy GameMaster - nek kiosztani (ahogy egy issue - t is bitbucket - en), hogy o foglalkozzon vele. Meg sorolhatnam. A lenyeg, hogy ezek a plussz funkcionalitasok nem az emulator felelossegi kore, nem is az API - e, hanem ez egy alkalmazasae, amivel megkonnyitheted a munkad.

Raneztem az eddigi API - t hasznalo alkalmazasokra, es kiindulopontnak jok, de en egy kicsit tovabb mennek. Ugy gondolom, hogy ez nem egy kitaposott osveny, amire viszont megfelelo kinalat eseten lenne igeny.

Teny, hogy nem erkezett sok visszajelzes a temahoz, de en sem sietek. Ebbol meg nem lesz holnapra semmi, sot, jovohetre sem. En is meg csak emesztem a dolgot es figyelemmel kovetem az esemenyeket. Az API sem tart meg abban a fazisban. TC foruman is kerdezoskodok, gondoltam itt is, hatha lesz belole valami erdekes, de az is lehet, hogy nem. Viszont sem baj, mert nincs tetje a dolognak. :)
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

#6
Belenéztetek ti egyáltalán ebbe a kódba?

Részlet:


Route::get('/dbc/areas_and_zones/{id}', function($id) {
  if (isset($_GET['version']) && $_GET['version'] == 6)
    $results = DB::connection('sqlite')->select("SELECT * FROM areas_and_zones_wod WHERE m_ID = ?", [$id]);
  else
    $results = DB::connection('sqlite')->select("SELECT * FROM areas_and_zones_wotlk WHERE m_ID = ?", [$id]);
  return Response::json($results);
})
  ->where('id', '[0-9]+');


1-2000 sort írtak eddig ebből, és támogat 2 verziót, ha bejönne egy 3. verzió akkor jöhet hozzá még 1000 sor...

Lehet ilyet írogatni, de ez így gépiró gyakorlat és amennyi idő erre elment inkább a Core és a DB fejlesztésére kellet volna forditani. Ha meg tényleg ilyen API-t akkar az ember csinálni csinálja rendesen.


- Minden egyes sorban lekérdezi a  (isset($_GET['version']) && $_GET['version'] == 6)-t? Miért? Nem elég egyszer, ha már API? És inkább  a function-be rakom bele.

PL.: function($id,$version)

- Ez fáj nekem legjobban (areas_and_zones_wod / areas_and_zones_wotlk) és ha nekem cataclysm kell?
Akkor írjak bele egy elseif-et az egészbe? Erre van egy értelmes megoldás a DB szerkezeteket egyszer inicializálom egy ARRAY-be.

Pl.:
areas_and_zones_[$version]

- Meg hát úgy az egészet meg lehetne írni 1/3 ennyi sorból, és később felhasználható lehetne akár más projectekhez is. Ez most csak a TC-hez jó ott is 2 verzióhoz és csak addig amíg a TC nem változtat a DB szerkezeten mert utána kinszenvedés jön!


Egy szó mint száz, ha már ilyen szvsz felesleges dolgot csinál valaki, akkor a minőségre adjon legalább és akkor tanul is belőle valamit.

DB szerkesztésre pedig PHPmyadmin-t vagy mondjuk Navicat-ot esetleg SQL_YOG-ot ajánlok. Smart_AI-hoz pedig valamelyik Smart_AI editort.

Update:

- A LUA scriptes TC mod is ezért halt meg mert hiába a LUA ha csak azt tudja kezelni amihez megírták a szorgos kezek az implementációt, ezzel egy csomó fölösleges dolgot tudd csinálni, de a Spell System-et ahol lehetne hasznát venni azt pont nem.


Shyro

@eztcsekk:

Megertem a koddal kapcsolatos aggodalmaidat, en is sok kivetnivalot talaltam benne. Viszont ugy gondolom, hogy ez a kezdemenyezes ertekebol nem vesz el, nem is tesz hozza, nem befolyasolja. Maga a projekt meg olyan fazisban tart, mind kodmennyiseg, mind hasznaltsag teren, hogy konnyen lehet refaktoralni, akar teljesen ujrairni, urjagondolni az API - t. Meg komolyabb atalakitasokkal sem fogsz eltorni semmit, mert szinte senki sem hasznalja meg. Szimplan csak be kell kapcsolodni, refaktoralni es bekuldeni a modistasaid.  Nem erzem azt, hogy a kod jelenlegi allapota megakadalyozna azt, hogy idovel jobb kod szulessen.

En tudok olyan projektrol, ahol az API - t annyian hasznaljak, hogy egy fuggvenyt sem irhatsz at, mert azzal mar eltorsz rengeteg mindent, szinte csak uj endpoint - okat vehetsz fel, az ujrairasa pedig annyi idot es energiat emesztene fel, hogy nem vallalkoznak ra Ezzel szemben itt nem fenyeget ez a veszely, szabad a palya.

Felreertes ne essek, nem isteniteni akarom a projektet, de ha ilyesmit felronank minden uj projektnek, akkor talan TrinityCore se lenne. A dolog ott kezd erdekesse vallni, amikor az emberek beszallnak es elkezdenek commit - olni, mert ugy gondoljak, hogy erdemes a dologgal foglalkozni. Ugy gondolom, hogy most eppen ez elott tartunk. Az, hogy az adott projektbol lesz e valami, inkabb mulik az utobbin, mint a jelenlegi kodminosegen. Azon mindig lehet javitani.

Azt, hogy nem latsz benne fantaziat, azzal semmi gond. Nem keltheti fel mindenkinek az erdeklodeset ugyan az a dolog.

A DB szerkeszteses dolgot pedig meg mindig nem tudom hova tenni, en speciel nem szeretnek azzal foglalkozni. Az meg az en erdeklodesemet nem kelti fel. :)
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Fantázia van a dologban én nem a dolog ellen vagyok hanem a miként ellen.

Ahogy már sokszor mondtam a PHPmyadmin azért 100% használhatobb még mindig mert ott a teljes DB-t eléred, minden táblát minden mezőt, mindent.


Ebben az API-ban azt éred el amit a gyerek megad SELECT *-al, ez így nem jó. Max. 100 sorban meg lehet írni, hogy bármilyen DB bármelyik mezőjét le tudd kérni és mint API és akkor arra használod amire akarod a másik 100-200 sor pedig jogosultságok kezelésére.

Példa URI: ./api.php?db=creature_temp&row=all
./api.php?db=creature_temp&row=entry,name
...

Shyro

@eztcsekk:

A mikenten szerintem lehet valtoztatni, azon mar kevesbe lehetne valtoztatni, ha teljesseggel a dolog ellen lennel.
A phpMyAdmin meg mindig egy adminisztrator felulet MySQL adatbazis kezelo rendszerhez, nem tobb (bar talan kevesebb), mint Oracle DB eseten az SQL Developer. Az API es amirol en beszeltem alkalmazas, az teljesen masrol szol, megha az implementacio felrevezeto is volt. Egy ilyen API epitesenek tobb celja is van, az elso es talan legfontosabb, hogy http(s) - en keresztul vegezhetsz barhonnan eroforraskezelest, megfelelo autentikacio mellett akar erzekeny adatokkal is. Milyen elonyokhoz juttat ez? Akar a felhoben (pl. heroku) tudsz futtatni egy teljesen elszaparalt alkalmazast, ami a neki szukseges eroforrasokat http(s) - en keresztul eri el, es nem foglalkozik azzal, hogy pl. a lekert adatok mikent allnak elo, nem marad az alkalmazas felelossegi kore. Ki tudsz szervezni altala funkcionalitast, ami nagyon sokat segit, akar az olyan esetekben is, amikor bonyolult SQL lekerdezesek megirasa helyett, csak kiadsz egy lekerdezest adott url - re. Arrol nem is beszelve, hogy ez nem egy remote access az adatbazis - kezelo rendszerhez, annal sokkal tobb is lehet. Egy jol levalaszthato reteget kepzel vele a nyers adatbazis felett (ami jelenleg meg nem valosult meg), ami tartalmazhat plussz ellenorzeseket, plussz optimalizalasokat (igenyekhez merten), jol tesztelhetove valik az eroforraseleres, akar biztonsagot is novelheted vele (persze csokkentheted is :)), teljesen komplex logikat emelhetsz ki bele az adatbazisbol, amiket az alkalmazasban sem szivesen implementalnal, sorolhatnam meg tovabb.
Ha egy alkalmazast szeretnel fejleszteni, mint en, egy ilyen reteg uj lehetoseget ad erre es megkonnyiti a munkad. Ezen felul ha valaki meg microservice - ekben is gondolkodik egy alkalmazason belul, az meg jobb, hiszen egyseges interface - t kapsz az adatok kezelesere minden microservice - nel, kiemelhetove valik a kod, szinten sorolhatnam.
Ezek mind olyan dolgok, amire a phpMyAdmin nem jo, mert nem erre talaltak ki, es koze sincs ehhez. En speciel regota varok hasonlo kezdemenyezesre. Szerver uzemelteteshez szukseges eszkozok teren meg nem sokat tud felmutatni az open source kozosseg. Amit ettol a projekttol varok az az, hogy ennek egy uj lenduletet ad.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

Zolee

Az olvasottak alapján, úgy gondolom, hogy ez egy igen jó kezdeményezés lehet. Bár így nem tudnám megmondani, hogy ez valójában mennyit könnyíteni a szerverkészítők dolgán, de nekem tetszik az ötlet. ;D
Nyilvánvalóan a közös munka is sokkal jobban egyszerűsíthető lehetne ezzel, persze akkor már gondolni is kell a külön felhasználói felületre, hogy ez párhuzamosan működjön.

Az adatbázis kezelését ezzel tulajdonképpen úgy lehetne megkönnyíteni, hogy esetleg példákon keresztül illusztrálnánk részleteiben vagy egy kész SQL kódot (is) kapna hozzá a fejlesztő. Gondolok itt olyan egyszerűbb dolgokra is, mint pl. egy Quest, ahol mondjuk feltételként meglenne adva, hogy X creature-t öljön. Így mondjuk lehetne több általános Quest "sablont" létrehozni, amit egy-két kattintással, illetve mezőkitöltéssel meglehetne oldani.
Persze ezeket nyilván nem nehéz megoldani bármely SQL kezelő programban vagy épp a PHPMyAdmin-ban, de ha már egy ilyen alkalmazásban gondolkodunk, az legyen felhasználó- és fejlesztőbarát.

Azt nem tudom, hogy ezt Scriptelés szintjén hogyan tudnátok, vagy megtudnátok-e oldani, ugye itt gondolok arra, hogy egy Boss scriptelése jóval egyszerűbben megoldható lenne, nem igényelne programozói tudást, szimplán kezelési tapasztalat lenne hozzá szükséges. :)

Egyelőre ennyit tudok hozzászólni a dologhoz, várom a fejleményeket.

Shyro

Most, hogy megneztem tuzetesebben a jelenlegi API - s projektet, igazat kell, hogy adjak @eztcsekk - nek. Nem vagyok egy nagy Laravel szakerto, de eros ketsegeim tamadtak azzal kapcsolatban, hogy egyatalan jol hasznaljak e ezt a keretrendszert. Lehetne refaktoralni, de az ujabb commit - ok alapjan erre nincs semmilyen torekves. Ez nalam egyet jelent, egyszeruen csak sajatot kellene irni.

En PHP/Ruby/JavaScript implementacion gondolkodok, esetleg van valakinek javaslata egyeb nyelvre, akar keretrendszerre? Hozzam a legkozelebb a JavaScript all es Koa.js, mint keretrendszer (http://koajs.com/). Hamar eltudnek vele indulni, de ez nem jogos erv. Viszont az emlitet nyelvek szerintem mind bovelkednek eszkozokben, keretrendszerekben es alkalmasak egy API kialakitasara. Meg merem kockaztatni, hogy kozel mindegy, hogy melyiket valassza az ember. Viszont hatha valaki meg tud gyozni, hogy van a feladatra alkalmasabb nyelv, illetve PHP es Ruby eseten keretrendszer javaslat.

@Zolee:

Ennek pontosan ez a lenyege. A vegeredmeny ugy is az lesz, hogy SQL lekerdezesek fognak futni, valtozik az adat az adatbazisban. En ugy gondolom, hogy vannak olyan rutinfeladatok, amiket erdemes elrejteni es egy alkalmazassal megkonnyiteni a folyamatot. Pl. egy legordulo menubol sokkal konnyebb kivalasztani az NPCFLAG mezo erteket egy uj NPC letrehozasanal/modositasanal, ahol beszedes nevek vannak felsorolva (Gossip, Quest Giver, Trainer, ...), mint szamokat beirogatni egy SQL lekerdezesbe, es folyamatosan utananezni, hogy oda pontosan milyen ertek is kellene. A feladat megoldasanak szempontjabol senkit nem erdekel, hogy az adatbazisban milyen ertekkel es milyen absztrakcioval van megoldva egy NPC tarolasa. Az ilyen reszletekkel valo foglalkozas csak lassitja es fajdalmassa teszi a munkat. Ennek az orvoslasaval felgyorsulna a szerver uzemeltetes soran felmerulo problemak megoldasa, tobb ido maradna masra. Ez most pont egy olyan pelda, amire fel lehet hozni a phpMyAdmin - t, viszont a problema amit irtam ott is ugyanugy megmarad. Ezen felul meg rengeteg olyan funkciot eltudok kepzelni, aminek egy uj rekord beszurasahoz koze sincs, egyszeruen csak konnyiti a munkat es a phpMyAdmin szoba se johet a megoldasara.
Tovabba en a fentebb emlitett legordulo lista megjeleniteset az alkalmazas logikaba tennem, viszont az NPC letrehozasat egy API moge rejtenem, amit az alkalmazasom "mint egy fuggvenyt" csak meghivnam. Ez a koncepcio nekem ezert tetszik.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Én azt mondom, hogy ez az SQL API kuka kategória, egy sima PDO-t kell csinálni 3-4db függvénnyel, UPDATE,INSERT,REPLACE...

Minden mást pedig akkor kliens oldalon Javascript-ben. Az fontos lenne, hogy a program tudjon generálni SQL kodot amit bármikor le lehet futatni máskor is.

Shyro

@eztcsekk:

Az az erzesem, hogy meg mindig elbeszelunk egymas mellett. A jobb megertes erdekeben felejtsuk el az adatbazisokat ugy ahogy vannak. Nincs SQL, nincs adatbazis - kezelo rendszer, nincs phpMyAdmin. Ezektol tekintsunk el. Legyen egy sima fajlunk, amiben JSON formatumban tarolunk adatot. Nyilvan atirogathatnank a fajlt kezzel, de legyen a fajl bazi nagy es jojjunk ra, hogy egy programmal tobb eselyunk van karbantartani azt. Ezt a fajlt betudjuk olvasni gond nelkul, de legyen erre egy kezelo osztalyunk, nevezzuk JSONFileHandler - nek. Ez most eleg altalanosan hangzik, de probaljunk meg eltekinteni a reszletektol. A JSONFileHandler - nek legyenek metodusai, amik altal kapunk egy letisztult, tesztelheto, ellenorzesekkel ellatott, meghivhato interface - t a JSON file - unk modositasara.
Mind a JSON fajl es a program, ami azt kezeli legyen egy A gepen, viszont szeretnenk elerni azt B geprol is. Nyilvan a JSON fajl es a program atmasolasa szoba se johet, hiszen mi a helyzet, ha a JSON fajl erzekeny adatokat is tartalmaz, amiket a JSONFileHandler szepen elfed, de a fajlok atmasolasaval az egeszet kidobhatnank a kukaba. Nem is szolgalhatjuk ki se FTP - n, se natur HTTP(S)- n keresztul a JSON fajlunkat, mert akkor ugyanott tartanank.
Ennek a megoldasara johet szoba egy Restful API, amivel az A gepen levo JSON fajlt, a JSONFileHandler funkcionalitasan keresztul ki tudod szolgalni a B gep szamara. Az, hogy a B gepen mit tudsz kezdeni a JSON fajllal, azt az API hatarozza meg. Azert van szukseg egy jol definialt API - ra, hogy a B gepen is futtathass egy alkalmazast, ami az API -n keresztul eri el az eroforrast, aminek az alapja a JSON fajl. Azert probaltam meg igy elmagyarazni, hogy erzekeltessem a retegek kozotti kulonbseget.
Nyilvan felmerul benned, hogy miert akarom elerni a JSON fajlt egy masik gepen? Ugyan azert, amiert nem telepitesz fel egy Gmail programot a gepedre, amin keresztul levelezel, hanem megnyitod a bongeszod es hasznalod a szolgaltatast. Ugyan azert, amiert mukodik a web mint platform.
Kovetkezo kerdes pedig lehet az, hogy mi legyen az az alkalmazas, ami a B gepen fut. Es itt jon a lenyeg, nem egy SQL generator vagy egy adatbazist kezelo felulet. Ezeket mind felejtsuk el. Az lehet barmilyen alkalmazas, ami nagyban epit egy API - ra, amin keresztul a szamara szukseges eroforrasokat eleri. Ezt a legfontosabb fontos kiemelni, hogy az API nem a felhasznalokat szolgalja ki, hanem az alkalmazasokat.
Amit javasoltal megoldas az pontosan amiatt nem jo, hogy nem ezt, hanem teljesen mast old meg.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Valóban elbeszélünk egymás mellet, mert te Általánoságban beszélsz, én pedig ennek rendszernek a megvalósithatóságáról.

Szóval jelenleg egy Stock TC-ben 163 World 89 Char és 13 Auth tábla van. Ez összesen 265db tábla és amiben van  olyan ~2000 unique key.

RESTfull API-ra pedig itt nincs szükség mert az adatbázis ismert, márpedig a RESTfull API egyik alap ötlete, hogy a DB Layer-t rejtsük el || tegyük egyszerüen kezelhetővé.

Mivel az adatbázis szerkezete ismert kliens oldalon is ezért nem látom értelmét szerver oldalon tovább bonyolitani, mint egy jól használható Parser a JS kódból jövő JSON-hoz.

A Kliens oldal így se lesz egyszerű, de elég lesz neki megtanitani a mezőket illetve, ha egymező fix értékeket vehet fel akkor az értékekhez tartozó jelentést.


Powered by EzPortal