Hirdetés
- Luck Dragon: Asszociációs játék. :)
 - hcl: MS Office365 Linuxon
 - btz: Internet fejlesztés országosan!
 - sziku69: Fűzzük össze a szavakat :)
 - Brogyi: CTEK akkumulátor töltő és másolatai
 - weiss: Lakodalom van a mi utcánkban...
 - droidic: Windows 11 önállóság nélküli világ: a kontroll új korszaka
 - LordAthis: RETRÓnia - RETRÓ Mánia - Úton van hozzám egy csodás történelmi darab!
 - gban: Ingyen kellene, de tegnapra
 - hcl: Kelj fel komám, ne aludjál
 
Új hozzászólás Aktív témák
- 
			
			
						cucka
addikt
válasz
							
							
								Sk8erPeter
							
							
								#3980
							
							üzenetére
						Most mit kötekszel? Nem arról volt szó, hogy fingom sincs, mi az a gráf vagy fa, hanem arról, hogy jelen esetben Te hogy oldottad meg a gyakorlatban.
Nem kötekedésként írtam. A fa tárolási eljárásom amúgy teljesen szokványos megoldás, nincs benne semmi hókuszpókusz. Azért kérdeztem, hogy tanították-e, mert általában egyetemeken ilyesmiket meg szoktak mutatni gyakorlati órákon, tehát nem kell mindent az alapoktól magyaráznom
 .A kérdés oka az volt, hogy először úgy képzeltem, hogy a language táblát is azért kell joinolni, mert mondjuk úgy kérdezel le, hogy "... WHERE language.name='en';", és akkor tényleg kellett volna joinolni, mivel akkor különben honnan szeded a nevet?
Egy lekérdezésnél akkor kell bejoin-olni egy táblát, ha szükséged van valamilyen mezőre belőle. A nyelvek kezelését egy nyelvkezelő osztállyal oldom meg, amely a konstruktorában betölti a rendszerben található összes nyelvet. Ha szükségem van arra, hogy a "hu" nyelvnek mi az azonosítója, akkor megkérdezem a nyelvkezelő objektumtól (és nyilván fordítva is, ha mondjuk a 2-es nyelv szöveges nevére van szükség). Így megspórolom, hogy minden egyes, többnyelvű adatot érintő lekérdezésbe bele kelljen join-olni a nyelv táblát is.Igen, viszont így megnő az esélye annak, hogy elcseszi a fájlt, és ha nem ért a HTML-hez, akkor néz, hogy miért nem működik.
Félreértetted. A felhasználó által szerkesztett menü egy xml-ben van, a felhasználó által szerkesztett szöveges tartalom pedig file-okban. Magát a honlap sablonját nem piszkálhatja, egyszerűen csak kap egy fckEditor-t, ahova beírhatja a szöveges tartalmakat. Így nem tud elrontani semmit.Akkor meg már mondjuk az a kérdés is felmerül, hogy miért is ne használjunk adatbázist a saját életünk megkönnyítésére, és alakítunk ki egy jó admin felületet a megrendelőnek, ahol sokkal szebb felületen tudja szerkesztgetni a menüpontokat és a belső tartalmat.
A most említett file-os megoldásom pontosan ugyanazt tudja, mint ha adatbázisból működne a dolog. A korábban említett, oop-s fa reprezentációm pont ezért hatékony, mert a hozzá tartozó alkalmazáslogika, adminisztrációs felület vagy megjelenítés szempontjából érdektelen, hogy adatbázisban vagy xml-ben tárolod a fát/menüt.A file-ban tárolós megoldás azért hatékony, mert sok ügyfél csak egy pár menüpontból álló szöveges honlapot kér. Ezt megfelelő keretrendszerrel ezt 1-2 nap alatt meg lehet csinálni és csak egy php-s tárhelyre van szükség hozzá. Gyakorlatilag csak a html/css részét kell elkészíteni, a többi már kész van, ezért fontos követelmény a programkódnál az újrafelhasználhatóság.
 
Új hozzászólás Aktív témák
- ÁRGARANCIA!Épített KomPhone i9 14900KF 64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
 - Samsung Galaxy S21+ / 8/128GB / Kártyafüggetlen / 12Hó Garancia
 - Microsoft Surface Pro // Surface // Surface laptop 10.gen i5, Ryzen // 12,5 13,5 15 //
 - Fujitsu Lifebook A3510 Laptop
 - Lenovo ThinkPad X1 Active Noise Cancellation fejhallgató
 
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Promenade Publishing House Kft.
Város: Budapest
								
							
 .
