Új hozzászólás Aktív témák

• #5311 Sk8erPeter nagyúr martonx #5309

  Új Válasz 2014-01-30 18:36:14 #5311

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #5309 üzenetére

  "az adatbázis nem azért van, hogy fordítást tároljunk benne"
  Bocs, de ez a vélemény szerintem ebben a formában teljesen értelmetlen. Mi az, hogy "nem azért van"? Miért ne lehetne "azért", amennyiben sokkal rugalmasabb fordítási és nyilvántartási módszereket biztosít az adott CMS (vagy keretrendszer, vagy teljesen mindegy, micsoda)? Ha épp arra van szükség, akkor adott esetben miért ne lehetne előnyösebb, mint fájlokat b@szogatni, minden egyes lekéréskor beolvasni, parse-olni, kikeresni a megfelelő elemet?
  Fontos: mindkettő módszerre lehet találni érveket, de te lényegében leszögezted, hogy nem, csak az egyik módszer a helyes. Bocs, de most a válaszod inkább tűnt kötekedőnek és önigazolónak (hogy miért is jobb a WordPress, mint a Drupal, ha már azt választottad), mint előrevivőnek és érdeminek.
  Korábban már leírtam, hogy a Drupalt a legapróbb részletekig le lehet fordítani, entitásszinten, field-szinten, blokkszinten, theme-szinten, modulszinten, mindennek nagyjából lehet tudni az első előfordulását is, vannak ezentúl fordítási csoportok is. Ha adatbázisban van tárolva, azért pár fokkal könnyebb karbantartani, és rugalmasabban kezelhető a dolog.
  Másik: amikor az ÖSSZES fordításban keresgélek - amire van lehetőség Drupalban - akkor szerinted tényleg az lenne a legjobb, ha az adott esetben száz telepített modul (úgy, hogy egyes moduloknak lehetnek almoduljai, akár 10 almodulja is lehet, épp a modularitás jegyében, hogy azok kikapcsolhatóak legyenek), 3 smink, és a core fordítási fájlját is összekaparná, parse-olná, és kinyögné valahogy pár másodperc után a végeredményt, hogy melyik fájlban találom az adott stringrészletet? Azért azt hangsúlyozzuk: NEM egy XML-fájlról van szó, mint amiről te beszéltél. Ez amúgy nem is értem, honnan jött, hogy egy darab XML-ről beszéltél. Bár lehet, hogy a WordPress így oldja meg, bár én sehol nem láttam XML-t említve, feltételezném, WP-nél is pluginfüggő fordítások vannak; és amennyiben uninstallálsz egy plugint, akkor feltételezném, hogy annak a fordításai is mennek a kukába, hogy tök feleslegesen ne legyenek ott.
  Amikor a fordítási felületre rámegyek, és több csoportosítási szempont szerint is láthatom a fordításokat - például hogy valamelyik elem a menühöz tartozik, valamelyik az entitásokhoz, meg a tököm tudja most a többit hirtelen fejből -, akkor mindegyik fájlból össze kéne kaparásznia a csoportosítási szempontoknak megfelelő adatokat? Ekkor is végig kellene rohannia a fájlokon (amiből ezek szerint lehet sokszáz - már ha össze nem pakolja egybe)? Oké, akkor erre most lehet jönni azzal, hogy hát a fájlokra is van mindenféle cache-elési módszer. Végül is azzal is lehet jönni, hogy de hát az adatbázis is fájlok formájában képzelendő el (ahogy sajnos az imént megtetted). De nem biztos, hogy ezek találó szempontok.
  Lehet, hogy mérlegelni kellene, hogy a WordPress és a Drupal más jellegű CMS-ek. A Drupalban mindenféle menütípust, blokktípust, entitástípust, tartalomtípust, taxonómiát, és minden egyebet eleve létre lehet hozni, és mindezt le is lehet fordítani apró részletekig. Tudtommal ebből a szempontból a WordPress jóval kötöttebb. Lehet, hogy nem csak az az egyféle szempont létezik, amit mi a fejünkben egyszer elképzeltünk, lehet, hogy van más eset, mint amivel mi eddig találkoztunk.

  "Ezek már miért ne lehetnének file-ban?"
  És miért ne lehetnének adatbázisban?
  Egy csomó szempontot fel lehet hozni mindkettőre. Továbbra is tök értelmetlen az egyiket egyértelmű győztesként kihozni. De mivel úgy tűnik, Drupal esetén az adatbázisszintű tárolás a jóval praktikusabb, ezért talán el lehetne fogadni, hogy lehet benne valami ráció, és hogy indokolt volt, hogy így találták ki, és nem szükséges az előfeltételezés, hogy biztos kretének dolgoztak a rendszer kitalálásán, akik nem értenek hozzá.
  Amúgy gondolom nem csak hype-olásból hangsúlyozzák, hogy a CMS-ek között a Drupal többnyelvűsítési mechanizmusa nagyon rugalmas.
  Persze biztos azt is csak hülye elfogult f@szok mondják.

  "Egy xml-en végigrohanni semmivel nem tart tovább, mint elindítani húszszor egymás után, hogy select ize from forditas where key = valami. A húsz-al arra céloztam, hogy mondjuk 20 elem fordítását kell lekérdezni az oldal rendereléséhez. Sőt lehet hogy, az xml nyerne."
  Adatbázisszintű cache is létezik. Durva, nem? Akár ha olyan van, ezt is le lehet kérni egyben is. Query cache is van, meg hasonlók.

  "Ne tegyünk úgy, mintha az adatbázis valami csoda lenne. Az is file-ban tárolódik ugyanúgy a lemezen "
  Te most tényleg ekkora idiótának nézel, hogy úgy érezted, ezt ki kell hangsúlyozni? Azért reménykedtem, hogy ennél többre tartasz. Ez rosszabb, mintha simán csak lehülyéztél volna, de köszönöm, hogy elláttál ezzel a teljesen újszerű információval.
  Bár egyébként sem értem, ez az érv hogyan lehet jelen esetben releváns, amikor teljesen máshogy működik egy adatbázis (még ha fájlok formájában is jelenik meg a háttértárolón (ami nem biztos, hogy lemez )), mint a fájlnyitogatás, parse-olás. De mint említettem, van olyan is, hogy a fájlos módszer tűnik praktikusabbnak. Nem változtat semmit azon, hogy adott esetben meg az adatbázisszintű megoldás lehet az előnyösebb. Mint jelen esetben.
  Igaz, én is elkövettem azt a hibát, hogy két, teljesen más felépítésű CMS megoldását vetettem össze.
  De legalább senkit nem néztem hülyének.

Új hozzászólás Aktív témák