Változó mennyiségű és típusú adatok (oszlopok?!)
Sziasztok!
Előre is bocs a címért és ha nehezen érthetően fogalmazok, a gond az, hogy én sem értem...
A mese:
Adott egy aránylag kicsi, nonprofit honlap (tervben), ahol meg kéne valósítani egyfajta rendezvényszervezést jelentkezéssel. Azazhogy nem egyfajta, hanem akárhányfajta, és minden programnál gyakorlatilag egyedi a jelentkezéshez szükséges adatok mennyisége is és típusa is. A programot aki szervezi, az ír (wysiwyg) egy programkiírást, ezzel nincs semmi gond, ez egy tartalomtípus. A baj az, hogy előre nem behatárolható, hogy milyen adatok kellenek a jelentkezéshez. (A felhasználókezelés itt nem lényeges, fórum, stb. miatt megoldott.)
Vázlatosan a szempontok (ha sikerül):
- A jelentkezési űrlapra ki tudja hány db input, textarea, stb. kell.
- Ezek mindegyikéhez gyakorlatilag egyedi label kell.
- A jelentkezések eredményét nem csak HTML táblába, hanem letölthető pl. XML fájlba (->Excel) is ki kell írni (ezt meg tudom oldani). Ezzel még utómunkáznak, tehát nem lehet benne "összetett adat" (ilyesmire gondolok:
- A programok kiírója ("honlapgazda") gyakorlatilag semmilyen HTML tudással nem rendelkezik.
- A programok közt még olyan különbség is előfordulhat, hogy egy jelentkező nem egy ember, hanem egy család, gyerekek számával, életkorral, stb.
- Hab a tortán: olyan is van, hogy aki (Jelentkező) az űrlapot kitölti, nem vesz részt a programon, hanem pl. a kisfiát íratta fel egy kirándulásra...
- Az egész történetnek egyszerűnek kell lennie a regelt Júzer és az üzemeltető számára is, "az sem ártana", ha aránylag kevés munkával meg tudnám oldani (=minimális táblaszám és kód).
- Nem cél, hogy "hű-de-webalkalmazás" legyen, már most szinte biztos, hogy jóval kevesebb pénz lesz rá, mint amennyibe reálisan kerülne. De én akkor is jó megoldást szeretnék.
Eredeti elképzelésem[1]: elsőre azt mondtam, a programok egy tábla, jelentkezések a másik. Össze kell szedni az összes olyan adatot, ami bármilyen jelentkezéshez kellhet (+1 tarcsi, meg egy id), ennyi oszlop megy a jelentkezések táblába. A program egyes példányaival tároljuk a required mezőket is (x db boolean). Na, ez azért nem jó, mert úgy tűnik, hogy nem lehet előre definiálni minden adatot.
Elképzelés[2]: legyen kiindulásként mondjuk 20 db sorszámozott adat. A program kiírásakor Üzemeltető sorban megadja a label feliratokat, amelyiknek nincs, az nem lesz a jelentkezős űrlapon. Ennek több hátránya van: nem tudom az adat típusát (...int, varchar, ...text, timestamp); sokat kell Üzemeltetőnek gépelni; nem tudok egyszerű megoldást arra, hogy az adott adathoz illeszkedő HTML beviteli elemet adjak az űrlapra.
Kérek mindenkit, akinek van valami ötlete, ossza meg velem! Lehet csak egy pici szikra hibádzik, de nem gyün...
Mégegyszer bocs ennyi rizsáért, de ez már eléggé idegesít. (Azért sincs kódmelléklet, mert még csak tervben van. Illetve lenne...)
Üdv. Pepita
■ Előre is bocs a címért és ha nehezen érthetően fogalmazok, a gond az, hogy én sem értem...
A mese:
Adott egy aránylag kicsi, nonprofit honlap (tervben), ahol meg kéne valósítani egyfajta rendezvényszervezést jelentkezéssel. Azazhogy nem egyfajta, hanem akárhányfajta, és minden programnál gyakorlatilag egyedi a jelentkezéshez szükséges adatok mennyisége is és típusa is. A programot aki szervezi, az ír (wysiwyg) egy programkiírást, ezzel nincs semmi gond, ez egy tartalomtípus. A baj az, hogy előre nem behatárolható, hogy milyen adatok kellenek a jelentkezéshez. (A felhasználókezelés itt nem lényeges, fórum, stb. miatt megoldott.)
Vázlatosan a szempontok (ha sikerül):
- A jelentkezési űrlapra ki tudja hány db input, textarea, stb. kell.
- Ezek mindegyikéhez gyakorlatilag egyedi label kell.
- A jelentkezések eredményét nem csak HTML táblába, hanem letölthető pl. XML fájlba (->Excel) is ki kell írni (ezt meg tudom oldani). Ezzel még utómunkáznak, tehát nem lehet benne "összetett adat" (ilyesmire gondolok:
123,456,789
egy varchar mezőben).- A programok kiírója ("honlapgazda") gyakorlatilag semmilyen HTML tudással nem rendelkezik.
- A programok közt még olyan különbség is előfordulhat, hogy egy jelentkező nem egy ember, hanem egy család, gyerekek számával, életkorral, stb.
- Hab a tortán: olyan is van, hogy aki (Jelentkező) az űrlapot kitölti, nem vesz részt a programon, hanem pl. a kisfiát íratta fel egy kirándulásra...
- Az egész történetnek egyszerűnek kell lennie a regelt Júzer és az üzemeltető számára is, "az sem ártana", ha aránylag kevés munkával meg tudnám oldani (=minimális táblaszám és kód).
- Nem cél, hogy "hű-de-webalkalmazás" legyen, már most szinte biztos, hogy jóval kevesebb pénz lesz rá, mint amennyibe reálisan kerülne. De én akkor is jó megoldást szeretnék.
Eredeti elképzelésem[1]: elsőre azt mondtam, a programok egy tábla, jelentkezések a másik. Össze kell szedni az összes olyan adatot, ami bármilyen jelentkezéshez kellhet (+1 tarcsi, meg egy id), ennyi oszlop megy a jelentkezések táblába. A program egyes példányaival tároljuk a required mezőket is (x db boolean). Na, ez azért nem jó, mert úgy tűnik, hogy nem lehet előre definiálni minden adatot.
Elképzelés[2]: legyen kiindulásként mondjuk 20 db sorszámozott adat. A program kiírásakor Üzemeltető sorban megadja a label feliratokat, amelyiknek nincs, az nem lesz a jelentkezős űrlapon. Ennek több hátránya van: nem tudom az adat típusát (...int, varchar, ...text, timestamp); sokat kell Üzemeltetőnek gépelni; nem tudok egyszerű megoldást arra, hogy az adott adathoz illeszkedő HTML beviteli elemet adjak az űrlapra.
Kérek mindenkit, akinek van valami ötlete, ossza meg velem! Lehet csak egy pici szikra hibádzik, de nem gyün...
Mégegyszer bocs ennyi rizsáért, de ez már eléggé idegesít. (Azért sincs kódmelléklet, mert még csak tervben van. Illetve lenne...)
Üdv. Pepita
NoSQL
MySql
Azonban nekem MySql megoldásra van szükségem, a szerveren valószínűleg nincs más - és ezen kívül én is csak a BDE-t ismerem.
Key-value?
Lehet
A pp-féle szerializált tárolás nekem tetszett. Egy-egy programra úgy 50 jelentkező szokott lenni (legyen max. 500), ennyinél még nem túl lassú egy programexport XML-be vagy CSV-be (lokális továbbfeldolgozáshoz).
Külön problémám volt (lett volna), hogy az adatellenőrzéseket hogy oldjam meg. Végül én arra tendáltam, hogy lesz 20-50 db előregyártott űrlapmező (táblában v. fájlban), mindegyikhez lekódolva az ellenőrzés, a program adminisztrátora meg kipipálgatja, hogy melyek kellenek az ő programjához. Ezt mondjuk elég nehéz könnyen továbbfejleszthetőre csinálni, de ez nem is volt szempont (állítólag 10 éve u.olyan jellegű programok).
Csak aztán ezt sem sikerült letárgyalni, de asszem ezt már leírtam itt valahol.
Kész megoldást használjatok.
Van számos kész megoldás a problémára, amit használni lehet erre. Én biztos nem állnék neki nulláról összerakni. A legegyszerűbb talán a Google megoldásának integrálása. Ha külső adattárolás zavar akkor meg valamilyen CMS/kérdőív generáló lenne szerintem az üdvözítő. Én erre a feladatra a Drupal + Webform kombót használnám. Egész jó a felhasználói felülete.
Ha magad szeretnéd, akkor viszont semmi esetre se javasolnám, hogy egy tábla fix mezőszámot használj. Én a következő felépítést javasolnám:
Kérdőívek tábla:
================
azonosító: egyedi azonosító (pl. MySQL autoincrement)
felépítés: text - benne serializálva a beállításokat tartalmazó tömb.
Válaszok/jelentkezések tábla:
===============
Kérdőív azonosító: külső kulcs a kérdőívek táblára
Válasz/jelentkezés: text - a választ tartalmazó tömb serializálva.
A nulláról fejlesztés nem lesz olcsó (már ha a munkaidőd költségét nem nullával számolod), rengeteg korláttal fog rendelkezni, a felhasználói interfésze borzalmas lesz és hozzád láncolja a nonprofit szervezetet. Ez utóbbi célt kivéve csak akkor tartom értelmesnek saját megoldásba vágni, ha a tanulás a célod. Ez utóbbit viszont mondd el a megrendelődnek is, hogy tudja miért készülsz el olyan lassan a megfogalmazott igényekkel.
pp
Nem CMS
A Google-féle dolog tetszetős, de nem a honlapon/tárhelyen van. (Mégis elképzelhető, hogy ez lesz a vége, köszi!)
Maradt a harmadik lehetőség. Pont ettől "féltem", hogy saját serializálót kell írjak (oda-vissza). Ezt hívtam "összetett adat"-nak. Viszont így maradhat két táblában, az adatszerkezet legalább egyszerű.
- Valóban. De mennyibe kerülne pl. Drupal-lal, egyedi sminkkel?
- Ha CMS-t használnék, akkor is legalább rövidtávon "hozzámláncolnám" őket.
- Nem tanulás a fő cél (bár szeretek tanulni), de semmiképp sem akarom egy mások által fejlesztett, általános célokra való rendszer korlátait felvállal(tat)ni. Nagyon jó a Drupal, de nagy is, bonyolult is - és szerverigényesebb is, mint egy "ici-pici" célszoftver. (Idő: ez inkább csak nekem szempont, de mire a Drupalba eléggé mélyen beletanulnék, addigra le is programozom bőven - remélem.)
Nagyon köszönöm a véleményed/ötleted, ez a szikra hiányzott:
serialize
. Esetleg - ha megtalálom - felhasználom a webform adatexportját is, kíváncsi vagyok, hogy csinálja (főleg Excelbe, ha nem CSV-vel).Idő nyerése kizárt a saját megoldásnál.
Kizárt, legalább próbáld ki, szánj rá fél-egy órácskát.
„- Valóban. De mennyibe kerülne pl. Drupal-lal, egyedi sminkkel?”
??? az egyedi sminket akkor is el kell készítened, ha nem Drupal (vagy bármi más), azt a több száz embernapot viszont meg tudod spórolni ami a választott rendszerbe már beleraktak. (bármit választhatsz, én azért javaslom a Drupalt mert igazából azt ismerem)
pp
Nemigazán időnyerés
Azonban nem fél-egyóra kipróbálnom a Drupal-t, pláne nem a sminkelést. Saját backend frontend-fejlesztésekor a saját változóimmal, hátteremmel kell tisztában legyek, nem a többezer ember által fejlesztettel.
Eddig a Drupallal komoly telepítési gondjaim is voltak, és nagyon-nagyon nem szeretem, ha nem értem egy szoftver "legbelső lelkivilágát", ha én (is) fejlesztem azt. Ehhez pedig jóval több kell, mint 1-2 óra.
A tárhelyről még nincs konkrét infóm, de kb. olyan (vagy gyengébb) lesz, mint egy ingyenes. Ha esetleg nincs cron, a frissítéssel már meg is vagyunk lőve.
De azért köszönöm neked a "Drupal felé lökdösést", idővel lehet, hogy odajutok! (Akkor viszont könnyen lehet, hogy Drupalfüggővé is válok.)
én is így voltam
Tapasztalatból mondom: ugyanez volt a felfogásom korábban és úgy gondoltam hogy ebből nagyon sokat is tanulhatok. Ez részben igaz, és jó ha az ember "belát a motorháztető alá" is, de ha határidők és pénzről van szó, akkor ez nem feltétlen a helyes út.
Tanulás szemontból tényleg nem rossz, viszont ha tényleg pénzt akarsz csinálni ebből, akkor javaslom a "futószalag-elv"-et:
építkezz abból ami van és amit már "feltaláltak" és minél gyorsabban add át. (most itt nem a végeredmény összelapátolására gondolok, csak érzékeltetni szeretném, hogy 0-ról megírni valamit más, mint egy közösség által több szempontból megcsócsált sokszorosan (0-ról) átírt eszközt működésre bírni). Első körben problémát fog okozni az "átállás", mert nem olyan formátumban vannak a dolgok, ahogy te szoktad, nem olyan könyvtárszerkezetben vannak, ahogy te szoktad ésatöbbi. De az első 1-2 ilyen "megerőszakolom magam" jellegű kör után, megvillannak ezeknek az előnyei, és hogy "jé, erre én nem is gondoltam (volna)".
A jQuery-vel való találkozásomnál voltam így: a javascripttől már a hideg rázott és lám, találtam valamit, ami megkönnyíti az életem - holott eleinte bonyolításnak gondoltam.
Viszont ha azt vesszük, a Drupal előtt is volt élet és a Drupal-t is emberek fejlesztik. De itt megintcsak érdemes visszakanyarodni a konkrét feladathoz és a konkrét célhoz.
Amúgy ha üzletileg nézzük, akkor gondolkodj üzletemberként: tehát ha eladásra szánsz ilyen - bonyolultabb - megoldást, akkor még a legelején érdemes megfontolni: érdemes-e egyáltalán foglalkozni a feladattal, ha például ugyanannyi idő alatt 10x annyi statikus html oldalt raksz össze (profibban) és 10x annyi további üzleti kapcsolatra teszel szert.
Az új kihívások és feladatok amik nem hagynak nyugodni és tényleg érdekesek/szórakoztatóak a számodra: fektess be: fordíts időt arra napi 1-2 órában (és munkaidőn kívüli tanulmányozással/tanulással), hogy elméleti megoldást találj rá. Aztán ha úgy látod, hogy erre komoly keresleted is lenne, akkor valósítsd is meg, a már összeszedett gondolatok/tervek alapján.
(Többszemélyes workgroup-oknál nyilván máshogy van és jó esetben minden feladatra megvan a külön ember, arra az iménti nem vonatkozik, de egyedül már csak így megy ;) )
Amúgy van egy másik járható út is: a fejlesztés értékét ténylegesen "kiszámlázod". Ha a megrendelőnek ez nem jó, akkor bemutathatsz neki egy "áthidaló" B tervet is, aminek a megvalósítását gyorsabban meg tudod csinálni. Ez persze azért nem az igazi, mert a megrendelő nem azt kapja amit akar, de még mindig jobb, mintha te is buksz rajta x időt (pénzt) és a végeredmény sem lesz tökéletes (tehát az üf sem lesz elégedett).
Megszívlelendő
konf.
Lehet, hogy egy ilyen alkalomra érdemes lenne benézni, hátha az előadásokból - és mindenféle ingyen reklámtárgyak begyűjtéséből :) - jóval több kerekedik ki, mintha leülsz elé és barátkozol a forráskóddal :)
Ecccer talán...
Egy custom (néha még a
Verziókövető
Nekem eddig még nem volt
Nem volt részlet
^ erre gondoltam.
^ erre gondoltam.
Drupalnak akkor van értelme,
Persze egyáltalán nem biztos, hogy egy nulláról lefejlesztett CCK-szerű interfész tanulhatóbb lesz, ellenben brutál sok munka.
Ez az ami minden rendszerről elmondható...
Még az egyedi fejlesztésekről is.
pp
Általában nem
Új tartalomtípus
Egyszer valaki azt mondta nekem, hogy egy mikrofon kéne billentyűzet helyett...
Azt feleltem: nem mikrofon kell, hanem egy jobb képességű titkárnő. :)