Hozzászólások
-
SzerzőBejegyzés
-
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;Valószínûleg belefutottál egy karbantartási ciklusba.
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;”
Hmm, mennyire ismered az adatbáziskezelést, azon belül a relációs modelt? Amit leírtál az jól mûködik egy ömlesztett szöveges fájlban, de SQL-ben kivitelezhetetlen és értelmetlen.
Bbt:
pliz az eszreveteleket a lforumfaq figyelmbe vetelevel tedd (magyarul azt kommetezd);
[align=right][snapback]101598[/snapback][/align]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. 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õ.
Jelenleg csak egy gyorsan összedobott teszt oldal van a honlapomon, amit még nem szívesen teszek közzé. A hétvégén javítok rajta, talán vasárnap lesz kész a publikus változat.
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 11|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.
hmm… nah, akkor gondolkozzunk:
adatbázisszerkezet (mysql v postgres alapokon lesz?);
a faq felépítésérõl van vmi 5let? pl h hány szintû lesz v ilyesmi…
[align=right][snapback]101550[/snapback][/align]Az adatbázisszerkezet SQL alapokon van, a lekérdezéseket külsõ fájlban lévõ függvények tartalmazzák. Jelenleg csak a mysql.php van meg, a PostgreSQL kliens még nincs kész, mert az esetleges atattábla változásokat 2x kellene átírni és tesztelni.
Talán jobb lenne korlátlan számú szintre tervezni a fákat, és teljesen el kellene különíteni a tartalomtól. Az eredeti FAQ két szintes, és a harmadik szint a tartalom.
ergo amig nincs kesz a sajat motor, addig vmi uncool kommersz vackkal is beerjuk; csak legyen ma’ vmi;
Van esetleg vmi felhasználható FAQ forrásod amit be lehetne dobni a darálóba? Esetleg a régi formátumú fájlod megvan még?
SZVSZ a WiDoMbo nem a legjobb erre a célra. Aranyos meg minden, de csak kis rendszerekhez jó. Fellow FAQ gyõjteménye 318 tételt tartalmaz jelenleg, megszámoltam. :icon_biggrin: A legnagyob probléma az, hogy nem elég kitenni, hanem könnyen megtalálhatónak és könnyen karbantarthatónak kell lennie. Ezért lenne jó a több fás rendszer, ami témakörönként, nehézségi szintenként, népszerûségként, stb. lehetne megjeleníteni. A WiDoMbo e tulajdonságok nélkül is megfelelne, ha nem ekkora mennyiségû kérdést kellene kezelni. Egy többszáz tételes környezetben senki sem fogja egyesével átnézni, hogy mi változott, ehhez át kellene írni (ha jól láttam, nem taralmazza ezt a funkciót, vagy a csoportos áthelyezést).
Személy szerint egy egyedi változatra szavazok, lennénk páran akik meg tudnák valósítani. Jelenleg egy teszt változat fut a http://gabaman.uw.hu címen, de az csak 1 órás tákolmány. Bbt is elküldte nekem az oldal szerkezeti tervét:
Code:1.index:
-bejelentkezés
-felh. név
-jelszó
-hibás bejelentkezésre login-regisztráció
-feltételek elolvasása
-adatok:-felh.név
-jelszó
-emilcím
-automatikus: hány bejegyzést tett, hányat javított, hányat korrigált.
-egyebek
->mondjuk emilben visszaigazolni a reget
->ugrás a bejelentkezésre-keresés
-hibás linkre figyelemfelhívás
opcionális:
-legújabb bejegyzések mutatása
-leggyakrabban látogatott bejegyzések mutatása
-linkek, bannerek stb.2. Bejelentkezés utáni index:
-új faq kérdés létrehozása
-keresés (hogy megnézze van-e már ilyen…)
-a faq kérdés elhelyezése a fában
-a faq kérdés
-a faq válasz
-megjegyzés(pl.: xy válasza, én nem teszteltem)
-automatikusan: -a bekerülés ideje
-beküldte
-az új kérdés logolása, esetleg adminok értesítése-meglévö faq kérdés szerkesztése (kicsi)
-gyakorlatilag ua. mint az új kérdés, csak a mezõk kitöltve.
-automatikusan: -a régi változat archiválása
-a javítás logolása (kis javításnál nem kell, hogy ki igazított rajta, illetve elég csak a logban)-meglévö faq kérdés szerkesztése (nagy)
-gyakorlatilag ua. mint az új kérdés, csak a mezõk kitöltve.
-automatikusan: -a régi változat archiválása
-a javítás logolása
-javította
-javítás ideje-keresés
-keresés kulcsszavak alapján
-kulcsszavak
-hol keresse (fõ témák)
-pontosan egyezõt/legjobban hasonlítót
-egy lapon hányat mutasson 🙂
-keresés a fában
-fa mutatása, klikkelgetés, vissza gomb…-esetleg listázás: -idõrendben
-abc sorrendben
-fa szerkezetben, abc sorrendben-legújabb szerkesztések megtekintése
-idõrendi sorrendben
-betûrendben, adott idõre visszamenõen
-a beküldõ adatai alapján-regisztrált tagok keresése
-mi változott az utolsó bejelentkezésed óta(nem tom kell-e ilyen)Mellesleg talán ez lenne az elsõ magyar Linuxos közösség által fejlesztett project.
Tehát, amire én gondolok, az egy FAQ-Wiki öszvér fejlesztése. A meglévõ megoldások egy részét átnéztem, de nem találtam semmi újrafelhasználható dolgot.
FAQ, mert:
– fa topológiájú
– kérdés-válasz alapú
– nem információ, hanem problémaorientáltWiki, mert:
– mindenki által szerkeszthetõ (opcionális)
– belsõ hivatkozásokkal rendelkezik
– általános témaköröket ölel fel
– értelmezõ szótárral rendelkezik (pl. felbukkanó ablakokban pár soros értelmezés)
– adatbázis alapú
– több „nézet” szerint lekérdezhetõHogy is ugorjunk neki? Nekem mostanában nem lesz rá sok idõm, de elõbb úgyis át kellene beszélni, hogy mit hogyan valósíthunk meg. Legelõször el kellene dönteni a licenceket. A PHP motort GPL, a tartalmat meg FDL, vagy Creative Commin License alatt kellene kiadni. Nekem inkább az FDL tetszik.
Egy gyorsan összedobott adatbázisterv (hogy mit kellene eltárolni):
Users: név,email, honlap, jogok
Csoport: Név, alcsoportok, rákattintások száma
Infó: Kérdés, Válasz, Csoportok, népszerûség, látogatottság, nehézségi szint, változatok, módosító neve, m. idõpont, megjegyzések„Nézetek”: Csoportok szerinti (fa), népszerûség, látogatottság, változás
A fentieket csak vitaalapnak szánom. Jó lenne kitalálni vmilyen struktúrát, hogy milyen legyen az oldal szerkezete. A grafika ráér, most még korai lenne foglalkozni vele. Most egy picit sietek, de ez úgyis látszik a leírtakon.
Legyetek szívesek kommentálni.
Ha fizetési módokat keresítek, az E-pénz is jó megoldás lehet. Alacsony jutaléka és kis átfutási ideje van. Egyedül a kivét a legdrágább (kivétenként egyszeri 1.80 € ~ 460 Ft), de összegtõl független.
Egy picit visszakanyarodnék az eredeti témához. Teljesen megértem Fellow álláspontját. Valaki segítségért jön ide, valaki meg csak mert itt mindenre ingyé’ válaszolnak. Szerintem is be kell(ene) vezetni fizetõs szolgáltatást. Majd egyszer, ha más szelek fújnak. Egyre többen jönnek már olyan kérdésekkel, amibõl világosan kiderül, hogy helyettük kellene vmit megoldani, mert nem hajlandóak rá (vagy csak lusták utánanézni). A valódi segítség az O.K., de az is módjával. Már én sem szívesen válaszolok 1000. alkalommal, de akkor is csak szájbarágósan. Talán ez is szolgáltatás.
Amivel nem értek egyet, hogy mindezt Csabának kellene a nyakába varrni, vagy hogy ezt az egészet a Linuxfórumhoz kellene kötni. Aki ilyet akar, indítson saját vállalkozást, vállalja a bukás kockázatát. Ami a FAQ/Wiki fejlesztését illeti, csak egy linuxfórumot segítõ fejlesztést tervezgetek Fellow FAQ-jához(csak nagyon ráérõsen), szó sem volt fizetõs megoldásról. Bizonyos nem publikus okok miatt nem tudok anyagilag segíteni, de más téren úgy gondolom, hogy igen (bár ez csak lehetõség). Fellow eredeti kezdeményezése is egy ilyen lett volna.
Ami a fizetõs rendszert illeti, jó ötlet, és mûködõképes is. Csak nem most és nem itt Magyarországon. Itthon még egy nem anyagi alapú projectet is nehéz elindítani, mert a sok bõgés és fikázás, a fejlesztõket meg sokan madárnak nézik.
Sajnos még sokat kell fejlõdnie a magyar Linuxos közösségnek, hogy összességében megüssön egy elfogadható szintet. Nem akarok bántani ezzel senkit sem, szerintem általánosságban igaz.
Mostanában készülök egy egyszerû C értelmezõt készíteni, akkor csak felvázolom a lényeget:
scanner.l :
Code:#include%x string
%{
” { BEGIN(string); }
[^”]* { strcpy(lval.str, yytext); return TOKEN_STRING; }
” { BEGIN(INITIAL); } printf { return TOKEN_PRINTF; }
panic { return TOKEN_PANIC; }[ tn] { printf („%s”, yytext); }
. { printf („%s”, yytext); }
%}parser.y :
Code:#include%union {
int i;
float f;
char* str;
}%token
TOKEN_STRING %token TOKEN_PRINTF
%token TOKEN_PANIC
%{
line:
| line lines
;lines:
TOKEN_PRINTF „(” string
{ printf („printf2 (%d, %s”, getid(), $3); }
| TOKEN_PANIC „(” string „)” „;”
{ printf („panic2 (%d, %s”, getid(), $3); }
;string:
TOKEN_STRING
{ $$ = strdup(lval.str); }
;
%}Valószínüleg van benne néhány hiba, ez csak vaktában hoztam össze. Annyit csinál, hogy a forrásfájlban (ez a rész nincs meg) megkeresi a printf („valami” és a panic („valami”); sorokat, ahol a tagok között bármennyi szóköz, tab, sorvége jel lehet, majd kicseréli õket. Hasonló feladatra Perl script jobb, mert gyorsabban elkészül (az már megvan), de túlzottan lassú ezért írom meg most C-ben.
-
SzerzőBejegyzés