gabaman:
tulsagosan jo kezdet, nagyon megmozgatott;
hiretelen elsoszamu problema, hogy nem enged be… olyat irt ki az uw, hogy a php script tullepte az idokeretet;

mindegy, amig tesztelgettem a leginkabb hianyzo funkcio a struktura konnyu kezelese (legalabbis ami szerintem jo megoldas lenne):
lfroumfaqbol idezek:

„
minden oldal elsõ sora meghatározza, hogy hol helyezkedik el a struktúrában, pld: „:hardware:videókártyák:nvidia”, így könnyen lehet új témákat elkészíteni, régieket áthelyezni, szétvágni, stb;
„

persze „egy level tobb agon” elv miatt, (kesobb) olyat is tudna:
:hardware:videokártyák:nvidia
:hardware:integráltvideókártyák:nvidia

gondolom nem olyan egszeru megvalositani, te a levelek mozagatasa, uj agak keszitese _nagyon_ leegyszerusodne;

imho ha ez kesz, akkor mar a lenyeg megvan;

imho le kene tisztazni a tovabbi fejleszteseket es a menetet;

Bbt:
pliz az eszreveteleket a lforumfaq figyelmbe vetelevel tedd (magyarul azt kommetezd);

Bbt:
„amin változttni kéne rajta, és lényeges is lenne (apróságot tudok többet is… ), hogy egy adott cikk megjelenhessen több helyen is egyidejûleg.”
„kéne rá egy jó keresõ, meg hogy alapértelmezettbe ne fa nézetben legyen, bár ez vázolva fentebb…”
ezek benne vannak; hagyne copy+paste;

csak azért kérdeztem, h fix v dinamikus szintûre kellene-e kódolni…
szal akkor dinamikus…

(hmm… van egy 5letem arra vonatkozóan, h hogyan lehetne megoldani azt, h egy „post” több „topicban” is megjelenjen:
az adatbázisban vhogyan így lenne tárolva
SELECT parent_id FROM tabla LIMIT 1

1|3|9|7|45

és akkor így kellene lekérni
SELECT * FROM tabla WHERE parent_id LIKE „%__topicid__%” ORDER BY id ;
)
[align=right][snapback]101560[/snapback][/align]

Ez így mûködik, de sajnos nem az igazi. A megoldás költsége közel O(n^2) – igazából kategóriák * összes elem – és a LIKE kitételt nem nagyon lehet indexelni. Szerintem jobb lenne, ha 2 táblában lenne tárolva a struktúra, külön a kategóriák kapcsolatainak és külön a kategóriákba tartozó elemeknek egy-egy tábla.

gabaman:
Megnéztem, elsõ közelítésbe tetszik.
Ami nagyon mellette szól, hogy piszok gyorsnak tûnik, imho az is marad, amíg nem akarjuk túl csicsásra…
amin változttni kéne rajta, és lényeges is lenne (apróságot tudok többet is… 🙂 ), hogy egy adott cikk megjelenhessen több helyen is egyidejûleg.
hirtelen észrevett apróságok:
-dátum formát valahogy „emberibben” kéne
-ilyet ír: „Az oldal frissítve (hibás): 20041202233818”

kéne rá egy jó keresõ, meg hogy alapértelmezettbe ne fa nézetben legyen, bár ez vázolva fentebb…
tetszik a licensz megoldás… 🙂

lehet érdemes lenne tolni be alá az anyagot? (jó sok copy-paste… 🙂 ) akkor lenne mit tesztelni…

megj.: szerintem a mambó cuccot elveri…
[align=right][snapback]101572[/snapback][/align]

gabaman:
„Valószínûleg belefutottál egy karbantartási ciklusba.”
eltelt, azota gyurtem egy kicsit;

„Hmm, mennyire ismered az adatbáziskezelést, azon belül a relációs modelt?”
csak elmeleti szinten;

„Amit leírtál az jól mûködik egy ömlesztett szöveges fájlban, de SQL-ben kivitelezhetetlen és értelmetlen.”
ertem;
foleg arra keresek megodlast, hogy egyszeruen lehessen a temakoroket kezelni (uj letrehozasa, regi atnevezese, athelyezese);

„Nem hiszem, hogy az általad elkészített leírás szentírás lenne. Ráadásul úgy készítetted el, hogy nagyon nehéz átlátni az egészet.”
magancelra keszult, azert raktam ki, hogy legyen vmi vitaalap;

„Nézd csak meg a Bbt által készített anyagot! Szellõs, áltatható és könnyen módosítható. A célját tökéletesen megvalósítja, átláthatóvá teszi a készülõ oldal struktúrális felépítését. Természetesen nincs kész, de itt az alkalom, hogy javíts rajta. Még a véleményedet sem mondtad el róla. Nekem nagyon tetszik, lényegében az adatbázis alap kivitelezése utáni teendõket készíti elõ.”
oke, megprobalom kigyujteni a jelenlegi publikus verzioval szemben az oteleteim;
egynelore a fontosak, amik megvaltoztatasa kesobb mar nehezebb lenne;