ugrás a tartalomhoz

Alkalmazás mag generálása Django használatával

Török Gábor · 2006. Júl. 25. (K), 16.31
A Rails-szerű keretrendszereket főképp az adatmodellekből származtatott, automatikusan generált SQL kód, adathozzáférési réteg ill. adminisztrációs felület miatt kedvelik a programozók. Ezek kivitelezése a legtöbb webalkalmazás fejlesztésének elkerülhetetlen lépései, a feladatok monotonításának súlyát ASP és PHP alatt fejlesztők érzik igazán. Jeff Croft naplójában közölte érdekes elképzelését, miként tudja az automatizmus nyújtotta kényelmet egy más nyelven fejlesztő is kiaknázni. Jeff a szívemhez közelálló Djangóval példálódzik, ahol különösképp nagy hangsúlyt kapott a framework tervezése során az egyes modulok önállósága.

Az elgondolás értelmében az adatbázis séma és hozzákapcsolódó CRUD felület kidolgozásához bátran használjuk a Djangót, fejlesszünk akár ASP-vel vagy PHP-vel. Az amúgyis könnyen tanulható Django és gazdanyelveként használatos Python alapszintű ismeretének birtokában pillanatok alatt felépíthetjük egy alkalmazás szerkesztőségi felületét, amelyet utána a számunkra kedves programozási nyelvben gyúrhatunk tovább, egyedi felületet építve hozzá. Mi mindössze deklaráljuk Pythonban az adatmodelleket, a szükséges adattáblákat és karbantartásukat segítő adminisztrációs interfészt pedig már a Django adja alánk. Erről Django admin for your PHP app? címmel tart rövid demonstrációt blogjában Jeff.
 
1

naiv elképzelés

Hodicska Gergely · 2006. Júl. 25. (K), 22.08
Egy kicsit átgondolatlannak érzem ezt az elképzelést. Pár dolog, ami kapásból beugrott, amikor elolvastam.
  • Az egy dolog, hogy a python legenerálja mondjuk az adatbázist kezelő réteget, de ettől még nekünk nem lesz ilyenünk PHP-ban, tehát ezt magunknak kell megírnunk, vagy használhatunk egy PHP-s ORM cuccot.
  • A legegyszerűbb admin felületek esetén is általában nem egyszerű adatrögzítésről van szó, az adminfelületben megjelenik az üzleti logika, ami jelen esetben az jelentené, hogy az szétszórva jelenik meg a két program nyelv között, ami nem tűnik egy túl szerencsés megoldásnak.
  • I18n szempontból is problémásnak érzem a dolgot. Szeretnénk például az alkalmazásunkat felkészíteni arra, hogy több nyelv dátumformátumát kezelni tudja, akkor ezt megint két helyen külön le kell programoznunk, ahelyett, hogy csak egyszer kéne foglalkozzunk vele.



Felhő
2

igyvan

Anonymous · 2006. Júl. 26. (Sze), 20.33
Szerintem aki kicsit többet fogalkozik cms-ekkel az már rég írt magának ilyen automat kódgenerálós cuccot... én nemvagyok egy nagy mágus mégis csináltam me minek urogassak meg dolgokat folyamat ujra...