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

• #10425 fordfairlane veterán martonx #10423

  Új Válasz 2013-12-06 00:22:53 #10425

  Ú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

  

  fordfairlane

  veterán

  válasz martonx #10423 üzenetére

  Aki nem használ kész komponenseket, az nem profi. Aki nekiáll saját O-R mappert, templatekezelőt, http-method route komponenst, meg hasonlókat gyártani, az legtöbbször nem a tudás, hanem a tudás hiánya miatt teszi.

  [ Szerkesztve ]

  x gon' give it to ya

• #10433 Sk8erPeter nagyúr martonx #10423

  Új Válasz 2013-12-07 23:51:07 #10433

  Ú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 #10423 üzenetére

  A konkrét problémára fókuszálva továbbra sem értem ezt az érvedet. Most ugye mondjuk egy magyar bankhoz tartozó fizetésre szolgáló modulról beszélünk, és annak integrálásáról egy meglévő webshopba. Vegyük a konkrét példát, hogy mondjuk nekem a Drupal Commerce-be kell integrálnom azt a funkciót, hogy az OTP fizetős felületére megtörténjen az átirányítás, ott megtörténjen a fizetés - függetlenül az én oldalamtól -, majd az OTP visszaküldjön az én oldalam felé a tranzakcióról szóló adatokat (sikeres vagy sikertelen, hiba okai, stb.). Igazából ennyi a modulom feladata. Feltételezem (mivel konkrét tapasztalatom nincs vele), hogy az OTP ad egy használható alapinfókat tartalmazó dokumentációt az API-jukról, ad valami API-kulcsot, meg lehetőséget a fizetés tesztelésére (tesztszerveren keresztül, mint amilyen sandbox-módja van a PayPalnak is). Hogyhogy "erősen kódolnom" kell? Meg kell oldanom ezt a konkrét problémát. És? Attól még ott lesz nekem készen az egész CMS admin-felülete, feltöltési lehetőségei, a kész webshopmotor (Drupal Commerce), az átszabható fastruktúrájú menürendszer, a kategorizálási rendszer, az entitás-alapú tartalom-létrehozás (minden entitás mezőzhető, így nagyon könnyen bővíthetőek az űrlapok, eléggé általános megoldás), ott van a modularitás (felhasználhatsz adott célokra kész modulokat), és főleg például a többnyelvűség, aztán még az összes többi, CMS által nyújtott kényelmi lehetőség.
  Egyébként sokan egyszerűen információhiány miatt fújolnak a CMS-ekre. Vagy pedig teljesítmény-overhead miatt, utóbbi legalább értelmes érv. Vagy amiatt, mert teljesen szedett-vedett a hozzá írható komponenshez tartozó API - igen, a Joomláról beszélek. Legalábbis régen ez így volt. Amúgy a Drupal kódja sem mondható cseppet sem szépnek, sőt, de az legalább sok tekintetben konzisztens (jó, kapásból tudok erre is bőven kivételeket mondani De legalább tapasztalatból), és nagyon jó dokumentáció van hozzá, meg valóban folyamatos fejlesztés alatt van.

  Továbbra is egyetlen dologról beszélünk: hozzá kell raknom egy lazán csatolt (a webshop működése szempontjából nyilván fontos szerepet betöltő) MODULT egy meglévő rendszerhez, nem pedig egy rendszert kell az elejétől lekódolni, "erősen kódolni".
  Tehát még mindig érthetetlen a korábbi, "erre a feladatra nem használható már a CMS"-jellegű érv, mert hülyeség, hogy ne lenne használható (mármint annak, aki vágja az adott CMS felépítését, ismeri az API-ját).
  Remélem sejthető, hogy most arra akarom felhívni a figyelmet, hogy a megoldandó feladat szempontjából tökéletesen mindegy, hogy egy framework API-ját felhasználva kell hozzácsatolnod egy OTP-s fizetősmodult a rendszeredhez, vagy pedig egy CMS API-ját felhasználva. Ha a CMS-t veszem, annak az előnyei attól még nem szűnnek meg vagy alakulnak át, hogy most konkrétan a fizetéshez kódolnom kell. Egy CMS-t nem úgy kell elképzelni, hogy abban csak kattintgatni lehet, testreszabni nem.

  Egyébként hogy jön ide a "rakás 3rd party cucc", vagy mit tekintünk annak? Ilyen alapon egy ASP.NET-es library-t nem?
  Mit jelent a "saját megoldás"? Ha valami bevált frameworköt használ az ember, tulajdonképpen az sem teljesen saját megoldás.

  Sk8erPeter

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