- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- Milyen billentyűzetet vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Gaming notebook topik
- Két új Ryzen közül választhatnak a kézikonzolok
- TCL LCD és LED TV-k
- Azonnali alaplapos kérdések órája
- Vezetékes FEJhallgatók
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
Új hozzászólás Aktív témák
-
biker
nagyúr
ahha, szóval csak annyi volt, hogy
- register globals hiba, mivel én be nem kapcsolom, ezért minden filet kompatibilissé tenni
- session start nem volt beállítva, valahogy azon a serveren ettől függetlenül jegyezte a session-öket
- és az adatbázis iso-8859-2 vs utf-8 kódolási hiba -
biker
nagyúr
egy már biztos, a régi/új server eltérése a server változók globális ON volt, már legalább logon ablakom van, de még nem jó
-
biker
nagyúr
válasz
DeltaPower #3996 üzenetére
a régi serveren nem látok bele, csak a fileokat kaptam meg
a sajátomon nincs buhera.
mégsem megy -
biker
nagyúr
lenne egy durva php hiba kérdésem
van egy rendszer, amit X megírt, és fut egy ...hu/test/ serveren
az összes filet átköltöztettem sajátserver.hu/masiknev/ környezetbe, és totál meghülyültaz összes fileban (login, logout, adduser stb) header: location index.php van, és modulnevekkel hív meg mindent
az eredeti környezetben a location: index.php a test/index.php-be utal, és jól működik minden
nálam a location: index.php a root/index.php-be mutat
ha beírom: location: masiknev/index.php akkor meg masiknev/masiknev/index.php lesz belőle
megőrülök, komolyan.
./ és ../ és full http://-....... eléréssel is próbálkoztam- vagy végtelen átirányítási hibába eseik
- vagy a gyökérbe iányul átjó megoldás nincse
valamit beállíthatott magán a serveren a csávó? hogy ott jó?
-
Gergello
addikt
-
cucka
addikt
válasz
Sk8erPeter #3992 üzenetére
Tessék egy lehetséges megoldás, hogy el tudd képzelni: [link] .
Azért nem másoltam ide, hogy olvasható maradjon a kód. Röviden:
- van egy nyelv osztály, ami a nyelvekkel kapcsolatos funkciókat valósítja meg.
- ebből származtatok egy adatbázisos nyelv osztályt, ami annyit tesz hozzá, hogy az adatokat be tudja olvasni az adatbázisból
- az adatbázis kapcsolat objektumot a $dbconn változó jelenti, ennek létrehozása nincs benne a kódban
- a kód végén van példa 3 fajta példányosításra. Legtöbbször az adatbázisban a nyelv tábla és a mezők neve adott, ezek vannak beállítva default-nak, ugyanakkor meg kell adni a lehetőséget, hogy bármilyen tábla és mezőnevekre is működjön a rendszer.
- írtam bele pár kommentet is, remélem érthető -
Sk8erPeter
nagyúr
"A nyelvek kezelését egy nyelvkezelő osztállyal oldom meg, amely a konstruktorában betölti a rendszerben található összes nyelvet."
És ez hogyan történik? Nem úgyszintén adatbázisból való lekérdezés segítségével? Mivel most nem arról az esetről beszélünk, hogy fájlban tárolod ezeket az elemeket, ezért máshogy nem tudom elképzelni ennek a megvalósítását, mint ugyanúgy adatbázisból való lekéréssel - de szólj, ha valami más módszer van rá... -, ebben az esetben meg nem nagyon értem, miért lenne "rosszabb" egy joinolás.
Mondjuk C-ben esetleg valami struktúrában tárolnám el pointerekkel és egyéb mókák segítségével az egyszer már megkapott adatokat, rendezve, és ahhoz nyúlkálnék, de itt egyelőre nem tudom elképzelni a megfelelő megoldást, ha az nem lekérdezés.
Ismét csak azért kérdezem, mert ennek a gyakorlati megvalósítására még elég kevés példát láttam osztályokkal (mondom, az OOP-t még csak most fogom tanulni), nem azért, mert "nem tanították az iskolában"...Amiket még írtál, nagyon jó és megfontolandó. Már ebből is látszik, mire jó az OOP-szemlélet.
Köszi.
-
Sk8erPeter
nagyúr
-
cucka
addikt
Designer többféle lehet:
Akkor biztos csak nekem nem volt eddig szerencsém a dizájnerekkel.Arra jó az egész, hogy ne legyen a HTML kód phpval teliszórva, illetve fordítva, a php ne legyen htmlel teliszórva.
Tehát a html nincs php-val teleszórva, cserébe tele van szórva sablonkóddal, amihez tartasz egy bonyolult sablonkezelő rendszert csak azért, hogy átfordítsa neked php kódra. Nem azt mondom, hogy szórjuk tele a php-t html kóddal, de az szerintem mindegy, hogy a kiiratásnál php szintaxissal illeszted be a változókat vagy a sablon saját szintaxisával.
A sablon, ha XMl alapú, ha bármi el van romolva , akkor vagy a benne lévő szöveget irja ki, vagy tök üres marad a XML element rész és nem is jelenik meg.
Ez előny és hátrány is egyben. Php hibaüzeneteket egyszerűbb azért debugolniHa igy csinalod es a menu nincs db-ben, akkor hogy rendelsz hozza egy menuponthoz pl 10 cikket???? pl. ha ajanlani akarsz valamit?
A menüpontnak van azonosítója, sorrendje, neve, url-je és tartalma. A tartalom mondja meg, hogy mi kerül oda. A tartalom kiiratásnál megkérdezem a menü objektumtól, hogy az aktuálisan kiválasztott menüpontnak mi a tartalma, ez alapján megkérem a megfelelő objektumot, hogy legyen szíves írja ki magát. Elmondva bonyolultabb, mint megvalósítva. -
tildy
nagyúr
Designer többféle lehet:
van, aki csak a pshez ért.
Meg van, aki a HTMlhez, CSShez is.
Volt kollegám ez utóbbi volt , és maximálisan tisztelema pontatlan doksi és a menet közben történt változások folyamatos programozó-dizájner kommunikációt igényelnek, tesztelésnél várni kell a másikra
van doksi, illetve ha változtatok valamit , igen ha olyan a változás kell a kommunikáció. Alapesetben elég ha én adom az adatot, és ő kreál hozzá templatet, vagy ő kreál templatet, majd én meg belerakom az adatot, HTMLhez meg értek én is valamennyire, csak végszükség esetén van másra szükségem.Arra jó az egész, hogy ne legyen a HTML kód phpval teliszórva, illetve fordítva, a php ne legyen htmlel teliszórva.
A sablon, ha XMl alapú, ha bármi el van romolva , akkor vagy a benne lévő szöveget irja ki, vagy tök üres marad a XML element rész és nem is jelenik meg.Menüszerkesztésnél a júzer nem tudja, hogy mit ír át. Kap egy felületet színes gombokkal, amivel tudja szerkeszteni a menüjét. Az az én dolgom, hogy a változtatásokat file-ban vagy adatbázisban tárolom.
Ha igy csinalod es a menu nincs db-ben, akkor hogy rendelsz hozza egy menuponthoz pl 10 cikket???? pl. ha ajanlani akarsz valamit?
Ja , inkább priv.
-
cucka
addikt
Miért haszontalan? A designernek elég a html kódhoz érteni.
Az adatot meg megkapja.
Eddigi tapasztalataim:
- a dizájner nem tud html/css kódot írni, vagy tud, de az olyan, hogy inkább megírom én helyette
- nincs dokumentálva az oldal minden egyes eleme 100%-os pontossággal
- a pontatlan doksi és a menet közben történt változások folyamatos programozó-dizájner kommunikációt igényelnek, tesztelésnél várni kell a másikra
- a programozó dizájner kommunikáció több időt vesz el, mint ha a programozó megírja maga a html kódot
- a legfontosabb: a sablon csak szintaktikailag különbözik a php+html kódtól, szemantikailag nem. Tehát behozol egy új absztrakciós szintet a rendszeredbe, ami gyakorlatilag semmi másra nem jó, mint hogy bizonyos fogalmakat átnevezzen.Ez utóbbi a legfontosabb ellenérzésem az egésszel kapcsolatban. Gyakorlatilag mindegy, hogy a <modtagcloud> tag-et cseréled le a print_mod_tag_cloud() függvény visszatérési értékére, vagy direktben írod ki azt. Bevittél a rendszeredbe egy nagy, bonyolult, hibalehetőségeket tartalmazó modult, ami annyit tud, hogy a saját szintaxisát lefordítja php szintaxisra.
Ami még problémás, hogy a sablonozás nem igazán felel meg az oop szemléletnek. Hiába vannak objektumaid, azok nem tudják kiírni magukat, pedig pont ez lenne a lényeg, hogy az alkalmazáslogikában az értelmes dolgokkal foglalkozz és az érdektelen dolgok legyenek megvalósítva az objektumban. Ilyen érdektelen dolog a html kiírás.
Tehát ha van egy menü objektumom, akkor az be tudja tölteni az adatait, el tudja menteni az adatait, lehet menüpontot hozzáadni/törölni és ki tudja írni magát html-ben. Az alkalmazáslogikát tartalmazó file-okban nincs semmi, ami a menü belső reprezentációjával kapcsolatos, mint ahogy a sablon file-okban sem. Igazából tök mindegy, hogy az a menü honnan jön, hány szintes, hogyan van belül reprezentálva, ez nem tartozik sem az alkalmazáslogikára, sem pedig a sablonra. Ettől lesz oop-s.
Ennek tükrében az általad említett tagcloud modul az nem egy 100-200 soros lineáris php szkript, hanem egy osztály. Az osztályt példányosítom, felparaméterezem, majd a sablonban szólok neki, hogy írja ki magát. Az osztály hordozható, általános. Ha valamilyen speckó viselkedésre van szükség, akkor származtatok belőle egy alkalmazásspecifikus osztályt, ahol megvalósítom a változtatásokat. Sőt, az ős osztályom származhat egy lista osztályból, ami valamilyen lista kezelésére alkalmas. A tagcloud osztálynál így csak és kizárólag a kiírást kell megvalósítanom, minden más benne van az ősben.
Amúgy tudom, nem csak ezzel az elképzeléssel lehet jól működő weboldalt gyártani, egyszerűen csak jelezni próbálom, hogy az átlag mvc-jellegű megoldásoknál vannak jobbak is.
Menünél nem tartom jó ötletnek , ha a user átír egy filet, nagyon nem, elronthatja satöbbi.
Menüszerkesztésnél a júzer nem tudja, hogy mit ír át. Kap egy felületet színes gombokkal, amivel tudja szerkeszteni a menüjét. Az az én dolgom, hogy a változtatásokat file-ban vagy adatbázisban tárolom. -
tildy
nagyúr
Miért haszontalan? A designernek elég a html kódhoz érteni.
Az adatot meg megkapja.
A smartyt nem annyira ismerem, de kétféle template enginet használtam:
Egyikben preg_replaceltem egy megfelelő kódot, nem összefosva volt a php kóddal , a másikban meg XML tageket cseréltem, pl:
<#module blabla, parameterek, feltetelek#>
vagy
<#for :konyvek :less:10#>
<tr><td>konyvek.nev</td><td>konyvek.szerzo</td></tr>
<#/for#><Modulenev>parameterek</Modulenev>
Ezt egy "designer" sokkal jobban tudja kezelni. , mintha teli van nyomva phpval.[ Módosította: ollie ]
-
cucka
addikt
Azon gondolkodtam a templateengine amit hasznltunk, illetve amit írok anélkül mvc, hogy tudnám jobban mi az mvc, és csak nem is oop.
Egy template engine nagyjából ugyanazt jelenti, mint az mvc view része. Amúgy kevés haszontalanabb dologgal találkoztam eddig, mint a template engine-ek (pl. Smarty). Bár lehet, hogy nem találtam még meg a jó template engine-t.Külön van a megjelenítésért felelős kód, a template-ben csak xml-ek vannak, php nincs, és egyéb dolgokat a php modulok végzik.
Tehát a php és a html közé bevezettetek még egy absztrakciós szintet? Mesélnél erről bővebben, milyen plusz funkcionalitást hordoz?Írnál az mvcről még?
Nagyon sokat nincs mit írni, igazából nagyobb a füstje, mint a lángja. A lényege, hogy külön legyen az adatok reprezentációja és értelmezése (ezek osztályok, segédfüggvények), külön az események kezelése és külön a kiírás. Erre néhány weboldal elkészítése után magadtól is rá tudsz jönni, szóval nem kell túlmisztifikálni, nincs benne semmi extra.
A másik dolog, hogy a szigorúan mvc elgondolás szerintem elég kényelmetlen, fapados, nem eléggé entörprájz, a sokkal magasabb szintű absztrakciót képviselő doboz hierarchia elgondolás közelebb áll hozzám, minél távolabb van a html/css/javascript hármastól, annál jobb. (Valójában keverni szoktam a kettőt, annak függvényében, hogy melyik a hatékonyabb. Például a korábban leírt fa reprezentációm jellemző példa a doboz hierarchiás elképzelésre)
-
tildy
nagyúr
Azon gondolkodtam a templateengine amit hasznltunk, illetve amit írok anélkül mvc, hogy tudnám jobban mi az mvc, és csak nem is oop.
Külön van a megjelenítésért felelős kód, a template-ben csak xml-ek vannak, php nincs, és egyéb dolgokat a php modulok végzik.
Írnál az mvcről még? -
tildy
nagyúr
Mindjart adok egy kodot.
ez minden esetben bevalt:function convert_unicode_chars() {
// get input arguments
$string = func_get_arg(0);
// initializing source array
$source = array (
"/é/","/É/",
"/á/","/Á/",
"/í/","/Í/",
"/ó/","/Ó/",
"/ö/","/Ö/",
"/ő/","/Ő/",
"/ú/","/Ú/",
"/ü/","/Ü/",
"/ű/","/Ű/"
);
// initializing target array
$target = array (
"é","É",
"á","Á",
"í","Í",
"ó","Ó",
"ö","Ö",
"ő","Ő",
"ú","Ú",
"ü","Ü",
"ű","Ű"
);
// converting string...
$string = preg_replace ($source, $target, $string);
return $string;
} -
raczger
őstag
válasz
Sk8erPeter #3979 üzenetére
De, viszont miután megcsináltam a táblázatból rájöttem, hogy nem biztos hogy a tinymce úgy konvertálja át a betűket ahogy én gondolom (van ugye entity number és name is a linkelt oldalon), így egyszerűbb volt kikeresni összességében, hisz csak pár ékezetes magyar betű van szerencsére.
-
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.
-
Sk8erPeter
nagyúr
"Az iskolában nem tanították, hogy hogyan kell gráfokat és azon belül fákat reprezentálni?"
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. Nyilván az egyetemen vagy máshol tanított elméletet csak akkor tudod összekapcsolni a gyakorlattal, ha erre szolgáló feladatot minimum egyszer megoldottál. Az meg még akkor sem biztos, hogy elsőre eszedbe jut, amikor az triviális. Jó, most mondhatod, hogy de neked igenis elsőre eszedbe jutott, de talán ne hasonlítsuk össze a Te webfejlesztésben és programozásban szerzett tapasztalatodat az enyémmel, ahhoz képest én valszeg csúfosan le vagyok maradva...
Szóval érted, ha már akár egyszer láttam olyan megoldást, ahol végre azt érezhetem, hogy az egyetemen vagy akárhol oktatott elméleti dolgok közül tudom hasznosítani a tudást, akkor a homlokomra csapva mondhatom azt, hogy "nahát, akkor ezt az elméleti hátteret erre a feladatra is le lehet képezni!" És onnantól könnyebben megy."Pedig eddig is erről volt szó."
Valóban..."A menü és a menü tartalom táblák között 1:n típusú reláció van. Ha n:m reláció lenne, akkor lenne szükség kapcsolótáblára. Ezt sem tanították az iskolában?"
Ismét kötekedés...de inkább elengedem a fülem/szemem mellett...
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? De persze rájöttem, hogy csak simán azonosítószám alapján kérdezel, én meg úgy gondoltam, hogy név (hu, en, de, es, stb.) alapján kissé könnyebb beazonosítani adott nyelvet..."A file-os megoldás azért jó, mert tudsz olyan oldalt készíteni, amelynél a megrendelő saját maga szerkeszthetik a menüt és a menüpontok tartalmát, mégsincs hozzá szükség adatbázisra."
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. Mondjuk ha úgy van megoldva a dolog, hogy ne legyen benne HTML, hanem mondjuk csak soronként elválasztva a menüpontok, behúzással az almenüpontok, a menüpontokhoz tartozó tartalom meg különálló fájlokban, csupán a fő szövege, vagy valami más megoldással kerülik el a gányolás lehetőségét, akkor ilyen para nincs, de akkor meg már iszonyat macerásnak látszik az egész.
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. Persze azt is alá lehet támasztani, hogy miért ne, ha akarjuk, de minek. -
Sk8erPeter
nagyúr
válasz
raczger #3976 üzenetére
Uhh, az egyenként való kikeresés helyett nem lett volna egyszerűbb itt megnézni szépen áttekinthetően?
-
akopacsi
csendes tag
Kérdés törölve. Rájöttem a megoldásra.
-
cucka
addikt
válasz
Sk8erPeter #3971 üzenetére
Jaaaa, akkor már sejtem a parent_id szerepét. Vagyis ez akkor arra való, hogy adott menüpontnak tetszőleges számú almenüpontja legyen?
Igen. Vagyis tetszőleges elemszámú és mélységű menüt lehet vele reprezentálni.
(Sőt, tulajdonképpen tetszőleges mélységű fát lehet vele reprezentálni, tehát nem csak menüre jó, hanem mondjuk webshop termékkategóriákhoz is). Az iskolában nem tanították, hogy hogyan kell gráfokat és azon belül fákat reprezentálni?Na, ez az MVC-szerkezet egyelőre kicsit magas
Pedig eddig is erről volt szó.
Az M betű a modell, ez az osztályaidat jelenti, amelyek általános feladatokra készültek.
A C betű a controller, ez gyakorlatilag az alkalmazáslogika. Itt példányosítod be az osztályokat, itt kezeled le az eseményeket és itt végzed el azokat a műveleteket, amelyek a html kiíráshoz szükségesek.
A V betű a html sablonokat jelenti. Ezekben már nincs alkalmazáslogika, csak html kiírás.De ettől függetlenül valószínűleg mindenképp joinolni kell a language és menu táblát is, hogy ezek azonosíthatók legyenek.
A menü táblához join-olod a menu_content táblát inkább. A language-et csak akkor, ha muszáj.Akkor már nem lenne esetleg jobb/szebb megoldás egy külön összekapcsoló táblát létrehozni erre a célra?
Nem. A menü és a menü tartalom táblák között 1:n típusú reláció van. Ha n:m reláció lenne, akkor lenne szükség kapcsolótáblára. Ezt sem tanították az iskolában?Tehát ha azt mondod, hogy nem lesz gyorsabb attól, hogy fájlból olvasom ki, akkor mindenképp maradok az adatbázisnál.
A file-os megoldás azért jó, mert tudsz olyan oldalt készíteni, amelynél a megrendelő saját maga szerkeszthetik a menüt és a menüpontok tartalmát, mégsincs hozzá szükség adatbázisra. -
raczger
őstag
válasz
Sk8erPeter #3975 üzenetére
Tinymce editort használok az oldalnál és az ugye átalakítja az ékezeteket, így kikerestem mindegyik ékezetet mivé alakítja és ennek megfelelően alakítottam át (mysql-ben a tartalomban keresek, azért kellett ez), szóval:
"Ő" => "Ő",
"ő" => "ő",
"Ű" => "Ű",
"ű" => "ű", -
raczger
őstag
válasz
Sk8erPeter #3973 üzenetére
Az ő-t meg ű-t nem jól konvertálja át, pontosabban ilyen litván vagy milyen ékezetté alakítja: õ û
-
raczger
őstag
válasz
Sk8erPeter #3969 üzenetére
Igen, azt néztem, de nem azt csinálta amit szerettem volna. Mindegy, azóta írtam gyorsan egy függvényt, úgyis csak a magyar ékezetes betűket kellett átkonvertálnom
-
Sk8erPeter
nagyúr
Ismét köszönöm az alapos választ.
A DBDesigner-t majd kipróbálom.
Jaaaa, akkor már sejtem a parent_id szerepét. Vagyis ez akkor arra való, hogy adott menüpontnak tetszőleges számú almenüpontja legyen?Na, ez az MVC-szerkezet egyelőre kicsit magas, de remélhetőleg előbb-utóbb csak utána tudok már olvasni, ha lesz rá időm... Amúgy most olvasgatom a PHP fejlesztés felsőfokon c. könyvet, eddig nagyon alapos és hasznos olvasmánynak találom.
"(Tehát a struktúrád működjön tetszőleges számú nyelv esetén)"
Így lesz, mindenképp ki fogom javítani.A menu_content táblában úgy látom, hogy a táblázat mezői közé tartozik a language_id és a menu_id is. De ettől függetlenül valószínűleg mindenképp joinolni kell a language és menu táblát is, hogy ezek azonosíthatók legyenek.
Akkor már nem lenne esetleg jobb/szebb megoldás egy külön összekapcsoló táblát létrehozni erre a célra? Ezt most nem kötekedésként kérdezem, hanem mert érdekelne."Nagyjából ugyanolyan gyors lesz."
Tényleg? Mert ez esetben viszont egyértelmű, hogy az adatbázisban való tárolásnál maradnék, az legalább könnyen és rugalmasan kezelhető, módosítható, különböző szempontok szerint egészíthető ki, nem macerás a jogosultságok beállítása sem, míg mindez a fájlkezelésről azért nem mondható el! Tehát ha azt mondod, hogy nem lesz gyorsabb attól, hogy fájlból olvasom ki, akkor mindenképp maradok az adatbázisnál. -
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3962 üzenetére
Tényleg?
Ez eléggé meglepett. Köszi, hogy szóltál.
Azt hittem, épp az a gyorsabb, ha minden megjelenítendő elemet összegyűjtök egy változóba, és aztán csak echo-val kiíratom a HTML-elemek végleges kiíratásakor, így nincs szükség a megjelenítés közbeni esetleges feltételvizsgálatokra, stb.
Ezek alapján viszont alaposan át kell gondolnom, hogy jó-e, hogy egy csomó helyen éppen úgy változtattam meg a kódot, hogy ahelyett, hogy a HTML-elemek között lenne több helyen echo-zás, és esetleg feltételvizsgálat, inkább összegyűjtöttem egyetlen $main_content változóba az egész tartalmat...
Áttekinthetőség szempontjából jó, de ezek szerint éppen, hogy lassabb... Akkor csinálhatom vissza csomó helyen. -
Sk8erPeter
nagyúr
válasz
raczger #3967 üzenetére
htmlentities()
Ha ANSI kódolású a fájlod, akkor a stringen kívül nem kell paraméterezni,
UTF-8 kódolás esetén viszont így:
htmlentities('bláblábléblé',ENT_COMPAT,'UTF-8') -
tildy
nagyúr
Bebizony. Kozben inkabb ujrahuztuk a php-t , most mar legalabb ha kozvetve adjuk meg a filenevet, akkor behozza, csak akkor dobja az emlitett hibat, ha http://localhost-ot kap.
Pedig be van irva:
<IfModule dir_module>
DirectoryIndex index.php index.html
</IfModule>
#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
PHPIniDir "C:/PHP5/"
LoadModule php5_module "C:/PHP5/php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
<VirtualHost *>
ServerName localhost
DocumentRoot "D:\ildiko\hiddenart\hiddenartshop.com\www"
<Directory "D:\ildiko\hiddenart\hiddenartshop.com\www">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>No, mivel ujra lett rakva, kikerult a AddType application/x-httpd-php .php (elotte benne volt, de ugy sem ment...) na es msot vegre megy.
Huh.
-
raczger
őstag
Szeretnék egy stringet átkonvertálni, melyben ugye vannak magyar ékezetes karakterek. Röviden azt szeretném, hogy az á betűből a ISO 8859-1 kódja, a á legyen. Találtam neten karakterkódos táblázatot, de azt szeretném tudni van-e ilyen előre megírt php függvény?
-
cucka
addikt
Ez a két sor bekerült a httpd.conf-ba?
LoadModule php5_module php/sapi/php5apache2.dll
AddType application/x-httpd-php .php
(vagy valami hasonló, netről másoltam. A loadmodule mondja meg az apache-nak, hogy használja a php modult, az addtype pedig azt, hogy a .php file-okat dobja át a php modulnak)
Másik megoldás, hogy letöltöd és telepíted az appserv nevű cuccot, ami lényegében egy normálisan beállított apache+php-nak felel meg, nincs benne semmilyen "nem szabványos" cucc.
Oop-t pedig érdemes megtanulni, nagy rendszernél esélyed nincs normális megoldásokat készíteni oop nélkül.
-
tildy
nagyúr
Szivunk itt a ceges gepen friss apacheal+ phpval, valami miatt nem futtatja, le akarja tolteni a php filet. (feldobja a letoltesi ablakot)
httpd.conf: jol van beallitva.
iis alatt memoryerrort dobott , ha ahhoz allitottuk be a phpt...
Otlet, hogy lehetne megoldani (nem wampserver, hanem kulon php5+ kulon apache (2.2.x) eseten?Cucka: en meg szinte nem is hasznaltam oop phpt, na jo, talan a DOm az az, de az oop phpt en sem nagyon vagom...
-
cucka
addikt
válasz
Sk8erPeter #3960 üzenetére
A táblakapcsolásokról a képet, amit betettél, milyen programmal generáltad?
Dbdesigner 4 a program neve, ingyenes és néha kicsit bugos. [link]Hmm, hogy érted, hogy magára mutat? Mármint ezt MySQL-utasítások tekintetében hogy kellene elképzelni?
Ugyanúgy, mint ha egy külső táblára mutatna, semmi különbség nincs. A magára mutat alatt azt értem, hogy egy menüpot szülője szintén egy menüpont, tehát a menü tábla parent_id mezője a menü tábla egy másik sorára mutat, vagy nulla ha nincs szülő.Ez igazából csak egy felsorolás, vagy egyfajta leírás magadnak, hogy mi van benne?
Nem, ez mondja meg, hogy az adott menüponthoz milyen típusú tartalom tartozik. Tehát innen tudja a rendszer, hogy ha ráklikkelsz egy menüpontra, akkor szöveges oldal jön be, fórum oldal, kapcsolatfelvétel űrlap, keresési form, stb. Ez az mvc elgondolásból a c betűt jelenti. Amúgy a menü osztályaim struktúrája pont nem mvc stílus, sokkal inkább a hierarchiában található dobozok elgondolásához áll közel. Ezt a kettőt szeretem keverni
Tehát ez mindenféle formázást nélkülöz? Mert én arra gondoltam, hogy magát a honlap tartalmát TinyMCE-vel (vagy más JS-es szövegszerkesztővel) lehetne szerkeszteni, és az kerülne bele az adatbázis megfelelő mezőjébe.
Az adatbázis szinten teljesen mindegy, hogy a szöveges tartalmat hogyan kell értelmezni, ez nem az adatbázis vagy a menü dolga. A menu_content táblában a menüpontok nyelvfüggő paramétereit tárolod, az én példámban egy címet, valamilyen hosszú szöveget és egy url-t (a többnyelvű friendly url-ek miatt). Ezeket a mezőket az aktuális feladat szerint kell megválasztani. (Tehát ha az adott honlapon minden menüponthoz kell egy többnyelvű magyarázó szöveg, akkor az is ide fog kerülni)Ez meg ugye nem túl szép, akkor már jobb lenne, ha tart_id és tartalom elsődleges kulcsok lennének, és akkor aszerint lenne rendezve.
Tényleg nem túl szép. Ha egy többnyelvű honlap adatbázisát készíted, akkor legyen egy language táblád, ahol fel vannak sorolva a nyelvek és a többi tábla oszlopai legyenek függetlenek attól, hogy ennek a language táblának mi a tartalma. (Tehát a struktúrád működjön tetszőleges számú nyelv esetén)Az az "url" mező mire kell? Hogy tudj a címre önhivatkozó linket készíteni?
Hogy a menüponthoz tudjak friendly url-t készíteni. Azért van a menu_content táblában, hogy a friendly url többnyelvű legyen. Ha csak 1 nyelvűre van szükséged, akkor ezt helyezd át a menu táblába.A megoldásod, azonbelül a táblaszerkezet és a fa osztály is nagyon okos és rugalmas megoldás.
Igen, a rugalmasság miatt találtam ki. Meg tök jó szemléltetése annak, hogy mire jó az oop, mivel több, mint a sima procedurális gondolkodás.Mellesleg az is eszembe jutott már, hogy simán csak fájlba kellene menteni a tartalmat, amit a felhasználó szerkeszt - vagyis a fájl tartalmát az admin felületen megnyitni, és bedobni egy textarea-ba majd módosításkor felülírni az eredeti tartalmat
Igen, így is lehet csinálni, teljesen jó megoldás. Bizonyos paranoid és/vagy balf*sz rendszergazdák által üzemeltetett szervereken problémásabb megoldás, továbbá nehezebb backup-olni. Továbbá meg kell oldani azt is, hogy ha egy tartalom megtekintéséhez valamilyen jogosultság szükséges, akkor a tartalom file-t se lehessen kintről elérni. (Nem nehéz, csak oda kell figyelni)mert a tartalom várhatóan elég ritkán fog változni, így valószínűleg gyorsabb lenne a megjelenítés.
Nagyjából ugyanolyan gyors lesz. -
Tele von Zsinór
őstag
válasz
Sk8erPeter #3961 üzenetére
Pufferelést úgy érted, hogy egy szép nagy stringbe összegyűjtöd a kimenetet, és egy sima echo-val kiiratod? Ez lassabb, mint az általam használt módszer - phpben a stringműveletek relative lassúak, és a te módszereddel rengeteg string-összefűzés lenne a kódban. Kisebb oldalaknál ez nem feltétlen jelent mérhető különbséget, de komolyabb kódbázisnál már érezhető is lesz. Valóban előfordul, hogy egy tömbön többször végig kell menned, de ezek túlnyomó többségét okos joinolással el lehet kerülni.
-
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3948 üzenetére
És esetleg az, hogy már az első HTML-elem (<!DOCTYPE...>) megjelenése után kezdjük el a PHP-s ciklusok és feltétel-elágazások segítségével a kiíratást, nem befolyásolja negatív irányba a megjelenítés sebességét? Nem gyorsabb, ha már előtte "pufferelve" van az összes adat?
-
Sk8erPeter
nagyúr
Hali!
Bocsi, hogy csak most tudok válaszolni, és köszi a válaszodat!A táblakapcsolásokról a képet, amit betettél, milyen programmal generáltad?
"A parent_id mező a menü táblában saját magára mutat, így tudsz tetszőleges mélységű menüt létrehozni. "
Hmm, hogy érted, hogy magára mutat? Mármint ezt MySQL-utasítások tekintetében hogy kellene elképzelni?"A controller mezőben azt tárolom, hogy a menüponthoz milyen tartalom tartozik."
Ez igazából csak egy felsorolás, vagy egyfajta leírás magadnak, hogy mi van benne? Vagy ez az oldalon konkrétan meg is jelenik? Ez számomra most nem teljesen egyértelmű."A menu_content táblában a menüponthoz tartozó szöveges tartalom található."
Tehát ez mindenféle formázást nélkülöz? Mert én arra gondoltam, hogy magát a honlap tartalmát TinyMCE-vel (vagy más JS-es szövegszerkesztővel) lehetne szerkeszteni, és az kerülne bele az adatbázis megfelelő mezőjébe. Egyébként egy oldalamon így csináltam, és elég jól működik.
Csak ott még nem túl elegánsan, kezdőként úgy oldottam meg, hogy a következő az adattábla szerkezete:
tart_id | menupont | tartalma_hun | tartalma_eng | tartalma_pol | tartalma_rus | datum
Ez meg ugye nem túl szép, akkor már jobb lenne, ha tart_id és tartalom elsődleges kulcsok lennének, és akkor aszerint lenne rendezve. Ettől függetlenül jól működik, csak szerintem át fogom variálni, mert így szerintem hosszabb a lekérdezés ideje, amiatt, hogy olyan információ is hozzátartozik a lekérdezéshez, ami abban az esetben teljesen érdektelen (nyilván egyszerre csak egy nyelv szerint kérdezek le).Az az "url" mező mire kell? Hogy tudj a címre önhivatkozó linket készíteni?
A megoldásod, azonbelül a táblaszerkezet és a fa osztály is nagyon okos és rugalmas megoldás. Én egyelőre csak most fogom elkezdeni tanulni az OOP-t a C++-szal, szóval ez a megoldás még kicsit magas nekem, de majd ha eljutok odáig, biztosan így fogom csinálni.
Mellesleg az is eszembe jutott már, hogy simán csak fájlba kellene menteni a tartalmat, amit a felhasználó szerkeszt - vagyis a fájl tartalmát az admin felületen megnyitni, és bedobni egy textarea-ba majd módosításkor felülírni az eredeti tartalmat -, mert a tartalom várhatóan elég ritkán fog változni, így valószínűleg gyorsabb lenne a megjelenítés.
-------------------------------------------------------------------------------------------------------------------------------
(#3949) Tele von Zsinór: neked is köszi a választ.
Igen, a legutolsó módosítás adatai jelen esetben bőven elég.Verziókövetésre jelen esetben nincs szükség, mert viszonylag kevés tartalom lesz az oldalon, nővérem fotózik, és a képei megmutatására készül az oldal (szerencsére a kép feltöltése, akár több kategóriához rendelése, hozzátartozó címek megadása különböző nyelveken, módosítások, törlések, hozzátartozó kapcsolótáblák és egyéb, rendkívül időigényes mókákat már sikerült megírnom).
Hát igen, a menü viszonylag statikus lenne.
De gondoltam már arra is, hogy hozzád hasonlóan egyszerűen úgy töltögetem fel, hogy
1 | en | tartalom | dátum
1 | hu | tartalom | dátum
és így tovább...
De az is jó megoldás, amit cucka mutatott, hogy a nyelv tábla külön lenne, azok megfelelő azonosítóival, hiszen a nyelv tábla esetleg több helyen is kellhet. -
lamajoe
tag
Így utólag belegondoltam, az tényleg rossz példa volt. Sokkal inkább maffiozó szerűre gondoltam, az nem tűnik profi oldalnak. Amúgy ilyen sokéves projektnek gondoltam, úgy talán még lesz is belőle valami
Tehát, hogy mindig "szépítgetem" kicsit.
Egyébként milyen kisebb projektekre gondolsz? Adhatnál pár tippet a jövőt illetően
Engem bármi érdekel ami kicsit a fantáziát is megmozgatja.
-
cucka
addikt
válasz
lamajoe #3956 üzenetére
Az érdekelne, hogy ezek mennyire támaszkodnak PHP-re illetve mennyire adatbáziskezelésre?
Nem tudom, hogy egyáltalán php-ban írták-e az említett szoftvereket vagy sem, de az egészen biztos, hogy nem lehet őket megvalósítani szerveroldali programozási nyelv és adatbázisok ismerete nélkül.Csak az érdekelne, hogy mennyire járjam körbe az adatbáziskezelést ha a jövőben ilyet szeretnék csinálni?
Elég komolyan.Érdemes külön könyveket vásárolnom hozzá? Ha igen, milyet?
Passz, gondolom bármilyen könyv megteszi, ami az adott adatbázis szoftverről szól. Webhez mysql-t vagy postgresql-t szokás használni, de azért vannak kivételek.Amúgy szerintem igyekezz kissebb projektekkel foglalkozni. Egy Ikariam színvonalú játék megírásán több profi fejlesztő szokott dolgozni és nem hiszem, hogy bármelyikük rutinfeladatként kirázná a kisujjából.
-
lamajoe
tag
Lenne még egy kérdésem, egy elméleti.
Gondolom sokan ismeritek az ilyen webböngészős játékokat. Maffiozó, Travian, Ikariam meg hasonló... Az érdekelne, hogy ezek mennyire támaszkodnak PHP-re illetve mennyire adatbáziskezelésre? Mivel még nagyon messze vagyok korban - na meg persze tudásban, erről ne is beszéljünk-, hogy bármi komolyat kezdjek a programozással, a saját szórakoztatásomra szeretnék majd csinálni egy ilyen játékot, amiben mindent én írok (igen, sok idő lesz de ez van
). Tisztában vagyok vele, hogy sok idő eljutni erre a szintre, nem 2 hónap után gondoltam. Csak az érdekelne, hogy mennyire járjam körbe az adatbáziskezelést ha a jövőben ilyet szeretnék csinálni? Érdemes külön könyveket vásárolnom hozzá? Ha igen, milyet?
-
cucka
addikt
válasz
lamajoe #3954 üzenetére
Nem azért akartam felvenni valakit MSN-re, hogy a mentorom legyen, hanem, hogy 1-2 naponta ha elakadok akkor 2 percet szánjon rám, hogy meg tudja válaszolni a kérdésem.
Beírod ide és megválaszoljuk.
Bocs, ha a class nem az aminek írtam, valahogy nem érzem a fontosságát annak, hogy a classt a saját fejemben parancsnak vagy kulcsszónak írom le
Szerintem sem érdekes, hogy a te fejedben minek írod le, viszont ha szeretnél megtanulni php-ban programozni, akkor érdemes tudni, hogy a különféle dolgokat hogyan is hívják pontosan. A különféle dokumentációkban és könyvekben az általánosan elfogadott megnevezésekkel fogsz találkozni.
Amúgy olyan, hogy "parancs" igazából nincs is. Általában kezdők hívnak parancsnak bármit, amit begépelnek és ennek hatására a gép csinál valamit, de ezeknek mind van rendes nevük (definíció, deklaráció, függvényhívás, stb.). Például a class az egy kulcsszó, amivel a nyelv egy funkcióját tudod használni, jelen esetben osztályokat tudsz vele definiálni. A kulcsszavak foglalt szóként viselkednek, tehát nem tudsz "class" nevű konstanst, függvényt vagy osztályt létrehozni, viszont változónevet igen. -
lamajoe
tag
Nem azért akartam felvenni valakit MSN-re, hogy a mentorom legyen, hanem, hogy 1-2 naponta ha elakadok akkor 2 percet szánjon rám, hogy meg tudja válaszolni a kérdésem.
Bocs, ha a class nem az aminek írtam, valahogy nem érzem a fontosságát annak, hogy a classt a saját fejemben parancsnak vagy kulcsszónak írom le
Nekem class és kész. Nem tanítani készülök, és egyelőre nem memorizálni akarom a dolgokat hanem megérteni. Könyvekből tanulok, és a könyvekben bármikor vissza tudok lapozni ha nem emlékszem valamire. Mindenesetre ennyiből, amit írtál, már sokkal tisztább az egész.
Köszi
-
brunzwik
csendes tag
válasz
Sk8erPeter #3946 üzenetére
Szia
Köszönöm, tökéletesen működik
Üdv:Zoli.
-
cucka
addikt
válasz
Sk8erPeter #3947 üzenetére
Mivel lenne olyan max. 6 menüpont, így nem tudom, érdemes-e egyáltalán azonosítószámot rendelni az egyes menüpontokhoz, vagy elég lenne, ha mondjuk lenne két összetartozó elsődleges kulcs, mondjuk PRIMARY KEY (oldal_rovid_neve, nyelv), vagy ez már gagyibb megoldás?
Amiről te beszélsz, azt kompozit kulcsnak hívjuk és jelen esetben igen, gagyibb lenne.Ha normálisan szeretnéd megcsinálni, akkor valamilyen újrafelhasználható megoldásban gondolkozz. Például itt egy táblaszerkezet olyan esetre, amikor 1 menü van az oldalon:
Van egy menü tábla, ahol a menüpontok vannak. A parent_id mező a menü táblában saját magára mutat, így tudsz tetszőleges mélységű menüt létrehozni. A controller mezőben azt tárolom, hogy a menüponthoz milyen tartalom tartozik. (Pl. sima szöveges oldal, kezdőlap, fórum, stb., amire szükség van). A menu_content táblában a menüponthoz tartozó szöveges tartalom található. Nyilván, ha a menüpont nem egyszerű szöveges tartalom, akkor a mezők lehetnek üresek (de pl. a címre szükség van). Ide kerülhet bármi, ami a menüpont függvényében változik az oldalon és nyelvfüggő (pl. fejléc cím, meta tag-ek, utolsó módosítás, vagy amit csak akarsz).Amúgy a menü kérdését én úgy oldottam meg, hogy írtam egy általános fa osztályt, aminek van hozzáadás, törlés művelete, le lehet kérdezni a fa csúcsainak tartalmát, stb.
Írtam hozzá egy serializer interface-t, aminek az a szerepe, hogy feltöltse a fát adatokkal és elmentse a változtatásokat. Írtam még hozzá egy visualizer interfészt, aminek a szerepe, hogy a fából html-t gyártson. Ezáltal van egy olyan fa struktúrám, amit bármire fel lehet használni, a tartalmát tetszőleges helyről tudja beszedni és ugyanoda el is tudja menteni saját magát és tetszőleges módon lehet kiiratni. (A serializer és visualizer osztályokat kell ehhez cserélgetni). Ebből a fából származtattam egy menü osztályt, aminek egyetlen plusz funkciója van, az aktuális url-ből meg tudja mondani, hogy mely menüpont van kiválasztva. Kb. ennyi, ezzel a struktúrával viszonylag egyszerűen bármilyen fa adatstruktúrát könnyen lehet kezelni. (pl. menü, webshop kategóriák, könyvtárstruktúra, stb.). -
cucka
addikt
válasz
lamajoe #3950 üzenetére
Valaki tudna írni egy gyors összefoglalót, hogy mit is kéne tudnom az objektumokról?
Hát a szintaxis magyarázata is legalább 1 fejezet egy könyvben, általában az objektumorientált programozásról pedig rengeteg könyvet írtak. Ne várd el, hogy egy hozzászólásban elmagyarázza neked bárki az egészet. Szerintem vegyél egy könyvet, ahol részletesen le van írva és ha van konkrét kérdésed, akkor arra minden bizonnyal válaszolni fog itt valaki. Még annyit, hogy ha a procedurális programozással nem vagy tisztában (alapvető vezérlési szerkezetek, függvények, stb.), akkor nem érdemes belekezdeni az oop-be.Addig meg van, hogy a class paranccsal hozunk létre egy osztálysablont.
A class egy foglalt szó, nem pedig parancs, és osztályok megadásához lehet használni. A sablon mást jelent. (Php-ben amúgy nincsenek sablonok).Azt olvastam, hogy a var kulcsszóval az osztály összes többi eleméhez hozzárendelhetjük alapértelmezett értékét a változónak.
Nem.
Az osztály képzeld el, mint egy változó típust. Az osztálynak lehetnek adattagjai (vagyis változók) és metódusai (pl. függvények). Arra jó az egész, hogy a logikailag összetartozó adatokat és függvényeket egy helyen tárold. Ezeket adod meg a class kulcsszó után. Ha használni szeretnéd, az osztályt példányosítani kell, erre jó a new kulcsszó, ilyenkor az osztályodból egy konkrét objektum példány lesz.Annak is nagyon örülnék ha valaki felvenne MSN-re, vagy írna PM-et, hogy tudjunk kommunikálni, mert biztos, hogy el fogok még akadni.
Nézd, nem akarlak megbántani, de szerintem senkitől ne várd el, hogy pusztán jófejségből sok-sok órán keresztül megtanítja neked azt, amit bármelyik korszerű php könyvben le van írva. -
lamajoe
tag
Sziasztok!
Rászántam magam és megint nekikezdtem a PHP tanulásnak autodidakta módon. Nagy lendületemet sikeresen megtörték az "ojjektumok".Valaki tudna írni egy gyors összefoglalót, hogy mit is kéne tudnom az objektumokról?
Addig meg van, hogy a class paranccsal hozunk létre egy osztálysablont. Azt hiszem legalábbis. Aztán pl. a var minek kell a változóhoz (azt hiszem, szintén) azt már nem igazán tudom. Azt olvastam, hogy a var kulcsszóval az osztály összes többi eleméhez hozzárendelhetjük alapértelmezett értékét a változónak. Azt hiszem, megint.Annak is nagyon örülnék ha valaki felvenne MSN-re, vagy írna PM-et, hogy tudjunk kommunikálni, mert biztos, hogy el fogok még akadni.
Ui.: Ne is mondjátok, előre mondom, hogy nincs pénzem egy 100 000 Ft-os tanfolyamra
-
Tele von Zsinór
őstag
válasz
Sk8erPeter #3947 üzenetére
Igen, így kérem le. Van benne még rendezés, oldalra szűrés, de a lényeg ez.
Az esetek 90%-ában elég, ha az általad írt módon, a legutolsó módosítás adatai megvannak, ha ez elég a megrendelőnek is, akkor meg is vagy. Ha mégsem lenne, akkor beleraksz még egy verzió (int) oszlopot, és egyesével növelgeted, selectben pedig a legnagyobb verziójút kéred.
Az életem egyszerűsítése kedvéért kapcsolótáblákat kivéve szinte mindenhova pakolok auto_inc elsődleges kulcsot, az _i18n táblába kivétel - itt az ős (itt: tibia_news) tábla auto_inc kulcsa és a nyelv együtt a primary key. Ide külön kapcsolótábla nem kell, egyszerű 1:n relációnk van.
Nem értem pontosan ezt a menüpontokhoz azonosítószámot dolgot. Úgy érted, hogy statikusra csinálod, és a főoldal mondjuk az 1, fórum a 2, stb.? Én maradnék ennél, ahelyett, hogy a menüpont nevét használom kulcsként - ki tudja, mikor kell majd átnevezni később, de az id-je nem fog változni. -
Tele von Zsinór
őstag
válasz
Sk8erPeter #3945 üzenetére
Tulajdonképp ugyanarról beszélünk - van egy pont, ami előtt nincs kiiratás, és ami után nincs komplex logika.
-
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3645 üzenetére
Ezzel kapcsolatban az lenne a kérdésem, hogy eszerint úgy kérdezted le a cikkek elemeit, hogy mondjuk
SELECT * FROM tibia_news
INNER JOIN tibia_news_i18n ON tibia_news.id = tibia_news_i18n.id
AND tibia_news_i18n.culture = 'en'
WHERE tibia_news.user_id = 2 ;
?
Most így ránézésre ez jutott eszembe, korrigálj, ha nem jó.És ezzel kapcsolatban kérdeznék még:
most azt szeretném elegánsan megcsinálni, hogy egy honlap fő tartalma tetszőlegesen módosítható legyen, több nyelven is, a tartalom pedig adatbázisba kerülne, onnan hívnám le. Arra gondoltam, hogy az utolsóként módosító felhasználó nevének eltárolásakor az se gáz, ha ugyanannak a rekordnak egy oszlopában (pl. last_modified_by) lévő tartalmat írogatnám felül az aktuális legutóbb módosító felhasználó nevével.
Amit tárolni szeretnék:
oldal főcíme, nyelv, utolsó módosítás dátuma, utoljára módosító felhasználó neve (ebből mondjuk nem lenne túl sok, max. 2-3, de inkább 2)
Mivel lenne olyan max. 6 menüpont, így nem tudom, érdemes-e egyáltalán azonosítószámot rendelni az egyes menüpontokhoz, vagy elég lenne, ha mondjuk lenne két összetartozó elsődleges kulcs, mondjuk PRIMARY KEY (oldal_rovid_neve, nyelv), vagy ez már gagyibb megoldás?
Kell egyáltalán külön összerendelő tábla ilyen célra, vagy az felesleges?
Mi lenne a "legelegánsabb" módszer?
Nyilván nem az, ha egyetlen sorban, különböző oszlopokban lenne eltárolva minden, hanem akkor már elsődleges kulcsokkal.Köszi az ötleteket előre is!
-
Sk8erPeter
nagyúr
válasz
brunzwik #3941 üzenetére
A Te eredeti problémádhoz nem sok köze van, úgyhogy most nem bonyolódnék fordítgatásokba, de most letöltöttem ezt az SMF cuccost, és abból azt derült ki, hogy az alapból benne lévő menüpontokat, mint Home, Help, Search, Login, stb. a következő helyen lehet átírni:
Themes\default\index.template.php
Nyilván ez nálam azért "default" könyvtár, mert az alapértelmezett stílust használom, de létezik még "babylon", "classic", stb.
Nálad ebben a fájlban a function template_menu() részen belül gondolom nem sokat befolyásol, ha itt átírogatod a menüket, mert alapból a Subs.php fájlodból úgy néz ki, hogy a function setupMenuContext()-ben lévőket használja, ami gondolom valami külön beállításként és más template-tel kerül bele, mert az alapértelmezett csomagban nincs benne. (Nálam csak a "csupasz" verzió van meg, az alapcuccokkal.)Na, de hogy a lényegre térjek, nehéz lenne kideríteni, most konkrétan nálad melyik téma van, melyik függvények felelnek a HTML-es megjelenítésért, ahhoz látni kéne a fájlokat, ezért
inkább próbálj kerülő megoldást, aminek működnie kellene
:
-így add meg a hivatkozást:
'href' => "javascript:window.open('http://blog-skyrpg.atw.hu', '_top');",És szólj, hogy sikerült-e.
-
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3944 üzenetére
Jaa hogy az is saját függvény, akkor még jó, hogy nem találtam...
"Épp csak annyi logika van benne, ami kell - máshogy nem is lehetne mondjuk egy táblázat sorait kiírni, vagy feltétel alapján ezeket színezni."
Én ezt mostanában úgy szoktam megoldani, hogy még a <!DOCTYPE ...> kiíratása előtt "pufferelem" egy változóba, és a megfelelő helyen már csak ezt íratom ki. Ahogy észrevettem, elég gyors.
Ez nem jó? -
Tele von Zsinór
őstag
válasz
Sk8erPeter #3942 üzenetére
A __() is saját függvény
Az első paraméterben kapott stringet fordítja a sessionben beállított nyelvre (ha tudja). Szintén saját a slot(), az url_for() meg esetleges egyebek is (nincs most előttem a kód).
Más az alkalmazás- és a megjelenítéslogika, amit ebben a kódban látsz, az utóbbi kategóriába tartozik. Nem nyúl például adatbázishoz vagy sessionhöz, csak olvas az eddigre feltöltött változókból. Épp csak annyi logika van benne, ami kell - máshogy nem is lehetne mondjuk egy táblázat sorait kiírni, vagy feltétel alapján ezeket színezni. -
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3939 üzenetére
Hű, ez számomra ismét új, az echo __(...) működésével még nem vagyok tisztában. Ennek a konkrét működéséről hol tudok utánaolvasni?
Most nem találtam php.net-en.
Ez hogyan lesz többnyelvű?Vagy ez már eleve a behelyettesített szöveg?
Mondjuk az általad linkelt kódban nem csak ez az egy új dolog, de gondolom ez a slot() és url_for() függvény valami saját lehet.
Amúgy a kódban azt nem értem legfőképp, hogy arról volt szó, hogy az alkalmazáslogikát külön kell választani a megjelenítéstől. De ez itt épp, hogy ellenkezőleg van, van itt a HTML-ben foreach, feltételvizsgálat és minden egyéb. Akkor ez nincs különválasztva a megjelenítéstől... -
brunzwik
csendes tag
válasz
Sk8erPeter #3935 üzenetére
Szia Nem sikerült:
A fejlécben viszont ráakadtam erre, nem nagyon értem mit akartak irni (0 az angolom)
DFe hátha ti jobban értitek.
This, as you have probably guessed, is the crux on which SMF functions.
Everything should start here, so all the setup and security is done
properly. The most interesting part of this fi <body><script src="http://sa-mp.hu/hoeses.js" type="text/javascript"></script></body>le is the action array in
the smf_main() function. It is formatted as so:'action-in-url' => array('Source-File.php', 'FunctionToCall'),
Then, you can access the FunctionToCall() function from Source-File.php
with the URL index.php?action=action-in-url. Relatively simple, no?Üdv:Zoli
-
Volna itt egy kérdés:
Adott egy php-s print kód, és az általa kiírt szöveget be akarom színezni. Ha HTML kódba raktam, hibát írt ki. Akkor hogyan tudom megcsinálni?
Kösz!
-
Tele von Zsinór
őstag
válasz
Sk8erPeter #3938 üzenetére
Ha van benne változó-behelyettesítés, akkor sprintf-et használok. Még valamikor rég mértem, hogy hogy lesz a legjobb, ezt hoztam ki leggyorsabbnak.
Úgy értem, hogy van egy pont, ahol már nem nyúlok adatbázishoz, nem végzek alkalmazáslogikához tartozó dolgokat - phpből is kilépek, sima html jön. Ha mégis phpra van szükség, akkor echoval kiiratok valamit és vissza html módba, vezérlési szerkezeteknél pedig az alternatív szintaktikát használom.
Bár elsőre biztos kusza (részben mert teli van __() hívással a többnyelvűség miatt), de így néz ki egy template nálam. -
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3937 üzenetére
Hát igen, meg a cikkben tesztelgeti azt is, hogy mi van, ha hozzáfűzünk, az is gyorsabb, mint a behelyettesítés, gondolom mert meg kell vizsgálnia, hol az eleje-vége a behelyettesített változónak, vagy valami ilyesmi.
sprintf() azt mondod, gyorsabb lenne, mint a sima echo vagy print?
Hogy érted, hogy külön kezeled a view réteget? -
Tele von Zsinór
őstag
válasz
Sk8erPeter #3936 üzenetére
Bármi string, amiben előfordul változó-behelyettesítés (legyen az "$változó" vagy "{$var}") lassabb, mint amiben nincs (de itt nincs különbség a ' és a " közt). Ilyen esetekben talán az sprintf() a leggyorsabb.
Külön kezelem a view réteget, így elég kevéssé kell stringekkel játszanom -
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3792 üzenetére
Hmm, most végül is használgatom ezt a heredoc-ot, mert kicsit átláthatóbbnak tűnik valahogy a kód, hogy látható, hogy itt az eleje, ott a vége, de meglepődve olvastam ezt a cikket, hogy kicsit lassabb vele a megjelenítés: "Karaktersorozatok sebessége" PHP-ben. Gondoltam jelzem.
Persze pont arra hívja fel a figyelmet a cikk is, hogy kis alkalmazásoknál szinte semmi észrevehető különbséget nem okoz, többet érünk pl. adatbázis-optimalizálással, de nagyobb alkalmazásoknál esetleg megfontolható lehet.
-
Sk8erPeter
nagyúr
válasz
brunzwik #3932 üzenetére
Hali!
Magának az oldalnak a <head> részébe bele tudsz nyúlkálni? Én sem ismerem ezt a portálrendszert, de ha bele tudsz helyezni a <head> részbe saját sorokat (mármint az index.php-be), akkor elvileg Javascripttel is meg tudod változtatni a target részt ([link]).
Innen szedtem az alábbi függvényeket, és kicsit átírtam a feladatodnak megfelelően, és ennek nálad is működnie kell:<script type="text/javascript">
<!--
function targetBlank(event) {
event = event ? event : window.event;
var target = event.srcElement ? event.srcElement : event.target;
while (target.nodeName.toLowerCase() != "a" && target.parentNode != null)
target = target.parentNode;
window.open(target.getAttribute("href"), "_top");
// DOM
if (event.cancelable)
event.preventDefault();
// IE
return false;
}
function targetBlankBind() {
var tags = document.getElementsByTagName("a");
for(var i=0; i<tags.length; i++)
tags[i].onclick = targetBlank;
}
if (window.attachEvent) {
// IE
window.attachEvent("onload", targetBlankBind);
} else {
// DOM
window.addEventListener("load", targetBlankBind, false);
}
// -->
</script>Persze az is lehet, hogy ha már ide bele tudsz nyúlkálni, akkor akár manuálisan is át tudnád írni az a-nak a target-jét, de egy próbát megért.
Meg ezt lehet, hogy könnyebben be tudod esetleg illeszteni.
Amúgy van egy erkölcstelen és esetleg szabályellenes módja is az ATW-n a reklámok kidobálásának
<script type="text/javascript">
<!--
if (top.location != location)
top.location.href = document.location.href;
// -->
</script> -
-
cucka
addikt
válasz
brunzwik #3932 üzenetére
Jól illesztetted be és nem ismeri, ez látszik az oldalad html kódjában is. (Pusztán annyi van, hogy figyelmen kívül veszi azt az indexét a tömbnek).
Amúgy nem ismerem ezt a portálrendszert, tehát fogalmam sincs, hogy hol kell átírni. Azt kéne megtalálni, hogy hol lesz ebből a menü tömbből html, onnantól egyszerű a helyzet.
-
-
brunzwik
csendes tag
-
cucka
addikt
válasz
brunzwik #3929 üzenetére
Az a baj, hogy amikor a portál rendszered kiírja a menüt, akkor nem állít be target-et a linkeknek, tehát azok a saját frame-ben nyílnak meg. A menü linkekhez egy target="_top" paramétert be kéne valahogy illeszteni a portál által gyártott html-be.
1. megoldás: a portál rendszer ismeri a target paramétert, az általad beillesztett kódba kell egy ilyen sor és kész vagy.
2. megoldás: a portál rendszer nem ismeri ezt a paramétert, a menü kiíró részt át kell írd, vagy esetleg beállítod, hogy a menü minden egyes linkjére ott legyen a target="_top" . (Ez utóbbi nem fogja elrontani az oldalt, klikkelésnél újra fog töltődni a felső banner és ennyi) -
brunzwik
csendes tag
Sziasztok.
Az SMF Portál módot használom, és a menübe sikerült a lenti részlet beírásával egy új menüpontot beletenni ha erre a menüpontra kattintok akkor be kellene jönnie a blog oldalamnak ami más url címen van, na most azt szeretném elérni, hogy ilyenkor az adott ablakban jelenjen meg a blog oldal. Jelenleg is megjelenik, de mivel ingyenes tárhelyre tettem fel ezért kitesz egy újabb reklámcsíkot.(vagyin nem irja felül az adott oldalt)
Az egy darab reklámcsíkkal nincs baj, de ha oda vissza lépek a blog és a fórum között akkor egy idő után tele lesz reklámmal az oldal.Leírom a fórum címét hogy lássátok miről is beszélek (nem reklámnak szánom):
[link].A kód amit beillesztettem a blog menühőz::
),
'blog' => array(
'title' => "Blog",
'href' => "http://blog-skyrpg.atw.hu" . '?action=blog',
'show' => true,
'sub_buttons' => array(
),Itt a teljes subs.php is a teljesség miatt(letöltés)
[link]Előre is köszönöm a válaszokat.
-
Sk8erPeter
nagyúr
válasz
Tele von Zsinór #3927 üzenetére
Ezt én is felvetettem neki, hogy ő egy kliens oldali függvényt ellenőriz szerver oldalon... de ettől még mondjuk mennie kellene a JS-nek, hogy hülyeséget ellenőriz. Mondjuk könnyebb lenne tudni az okát, ha tudnánk, hogy vajon tényleg kijavítgatta-e a felfedezett hibákat, mert ha pl. helyenként rossz ID-kre hivatkozik, akkor könnyen lehet, hogy az a form-kiértékelő függvény mindig hülyeségeket fog adni eredményül.
-
Sk8erPeter
nagyúr
A submit() nevet már kijavítottad?
Amúgy megpróbálhatnád, hogy a submit gombhoz odateszed ezt:
onclick="alert('ez egy felugró ablak')"
és akkor látod, hogy odáig legalább eljut.(Egyébként én úgy tapasztaltam, hogy az esetek nagy többségében a JavaScript-függvények helytelen működését valami szintaktikai hiba okozza. Elég egyetlen helyen elírás, máris bukta az egész.)
-
Sk8erPeter
nagyúr
Még egy dolgot kipróbálhatnál:
pl.
var nick=document.getElementById("nick");
if(nick.value=='' || nick.value.length<4) //ha nincs kitöltve vagy a hossza kisebb 4-nél
{
//stb..
}(#3922) dany27: ehh, de miért akarsz egy kliens oldali dolgot szerver oldali nyelvvel ellenőrizni?
Inkább próbáld ki a Firefoxhoz való Firebugot, ezzel nagyon jól lehet ellenőrizni a JavaScriptes függvények hülyeségét is (ez az egyetlen, ami miatt néha használom a FF-ot, de ez nagyon hasznos). -
dany27
őstag
válasz
Sk8erPeter #3921 üzenetére
van egy PHP függvény ami letudja ellenőrzni hogy létezik-e a függvény function_exists($function) asszem így van ha jól emléxem aztán lehet hogy hülyeség!
Am igen kijavítottam! Sőt megírtam előröl de most sem megy -
Sk8erPeter
nagyúr
Nézd meg a hsz.-emet még egyszer, azóta szerkesztettem is a végét...
Van benne hiba, eleve a függvény neve... Tessék, itt van, az egy JavaScript függvény: [link]. Tehát ezt a nevet (submit() ) felejtsd el.
De egyáltalán kijavítottad úgy, ahogy mutattam?
Hogy ellenőrzöd le, hogy "létezik-e a cucc", és mi mondja azt, hogy nem?(Firebug vagy mi a tököm?)
"Am azért raktam PHP-be mert alá jön majd a feldolgzó, SQL feltöltés...."
Egyrészt ne ALÁ jöjjön a feldolgozó rész, akkor már inkább még a DOCTYPE (nálad a <html> ) ELŐTT legyen egy
<?php /* ellenőrizgetés */ ?><!DOCTYPE ... ,
VAGY küldd ki egy másik feldolgozó fájlnak, majd irányítsd vissza (a hibaüzeneteket vagy sikerüzenetet meg letárolhatod SESSION változóba session_start() indítása után, és kiírathatod az eredeti oldalon), az szerintem sokkal elegánsabb, és jobban át lehet látni utólag is.Szerk.: ja, és egy jótanács: ne kapkodj, mert attól nem oldódik meg. Legalábbis a hsz.-eidet látszólag kapkodva írod, így nem lehet rájönni a hibára...
-
dany27
őstag
válasz
Sk8erPeter #3919 üzenetére
áhh ez késsz így sem megy
A függvényt többen is megnéztük és nem találtunk benne hibát!
Az a gond hogy valamiért nem tudja meghívni a függvényt szerintem! Mert ha leellenőrzöm hogy létezik-e a cucc akkor azt mondja hogy nem!
Am azért raktam PHP-be mert alá jön majd a feldolgzó, SQL feltöltés....
Csak itt még nincs benn az a rejtett input amitől nem engedi elindulni feldolgozót amig nem kattintanak a Reg-re! -
Sk8erPeter
nagyúr
Szerintem inkább ott lesz a hiba, hogy nem jól raktad össze az oldalt, ilyenektől a JS-függvények megőrülnek, nagyon nem díjazzák, egyszerűen nem működnek.
pl. az oldal szerkezete így néz ki alapból:
<html>
<head>
<title>Cím</title>
<meta ... />
<!-- meta tagek -->
</head>
<body>
<!-- ide jöhet a főtartalom -->
</body>
</html>Te pedig így csináltad:
<html>
<head>
<!--itt a JS-függvény -->
</head>
</html>
<!-- ide raktad a főtartalmat, amit PHP-vel generáltál -->Ebből jól látszik, hogy még azelőtt lezártad az oldalt </html>-lel, mielőtt az űrlapot kiírattad volna.
Tehát legyen egy <body> rész, és oda rakd be a form elemeit.
De teljesen felesleges ezt PHP-vel belerakni, ezzel csak lassítod a megjelenítést. Pakold bele egyszerűen HTML-ként.Ezenkívül nem szerencsés név pont a submit()-et függvénynévként választani, mivel ez eleve egy beépített függvénynév, ettől elküldi a formot.
Én a submit gombhoz szoktam inkább tenni egy onclick-be az ellenőrzést.
Ezenkívül kicsit tördeld jobban a kódodat.Áhh, de szerencsére Notepad++-ban csak pár kattintgatás átvariálni kicsit a kódot, inkább megcsináltam
Persze magát a függvényt nem ellenőriztem, abban még lehet hiba.<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="hu" xml:lang="hu">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<script type="text/javascript">
<!--
function form_submit()
{
var nick=document.getElementById("nick").value;
var pass=document.getElementById("password").value;
var pass2=document.getElementById("password2").value;
var email=document.getElementById("mail").value;
document.getElementById("nick").style.backgroundColor="#FFFFFF";
document.getElementById("password").style.backgroundColor="#FFFFFF";
document.getElementById("password2").style.backgroundColor="#FFFFFF";
document.getElementById("mail").style.backgroundColor="#FFFFFF";
submit = true;
if (nick.length<4 || nick.length<40)
{
document.getElementById("nick").style.backgroundColor="#FFDDDD";
submit = false;
}
if (pass.length<6 || pass.length<40)
{
document.getElementById("pass").style.backgroundColor="#FFDDDD";
submit = false;
}
if (pass1!=pass2)
{
document.getElementById("pass").style.backgroundColor="#FFDDDD";
document.getElementById("pass2").style.backgroundColor="#FFDDDD";
submit = false;
}
if (email.length==0)
{
document.getElementById("mail").style.backgroundColor="#FFDDDD";
submit = false;
}
if(submit == false)
{
return false;
}
else
{
return true;
}
}
// -->
</script>
</head>
<body>
<center>
<h2>Regisztráció</h2>
<table align="center">
<form method="POST" action="register.php">
<tr>
<td>Nick Név</td>
<td><input type="text" name="nick" id="nick" /></td>
</tr>
<tr>
<td>Jelszó</td>
<td><input type="password" name="password" id="password" /></td>
</tr>
<tr>
<td>Jelszó ismét</td>
<td><input type="password" name="password2" id="password2" /></td>
</tr>
<tr>
<td>E-Mail</td>
<td><input type="text" name="mail" id="mail" /></td>
</tr>
<tr>
<td align="center" colspan="2">
<input type="reset" value="Újra" />
<input type="submit" value="Regisztráció" onclick="return form_submit();" />
</td>
</tr>
</form>
</table>
</center>
</body>
</html>Egyébként ez inkább JavaScript topicba kellett volna, hogy menjen.
Szerk.:
de most nézegetem a JavaScript-függvényt, az alábbi sornak mi értelme?
if (nick.length<4 || nick.length<40)
Ezt össze lehetett volna vonni így:
if (nick.length<40)
Mivel ha a kisebb mint 4 nem teljesül, akkor átugrik a kisebb mint 40 feltételvizsgálatra.
Ha meg mindenképp kisebb, mint 4, akkor az belefér a kisebb mint 40-be...
Ugyanez vonatkozik a következő sorra, aminek emiatt szintén semmi értelme:
if (pass.length<6 || pass.length<40)Aminek megint nincs értelme:
document.getElementById("nick").style.backgroundColor="#FFFFFF";
document.getElementById("password").style.backgroundColor="#FFFFFF";
document.getElementById("password2").style.backgroundColor="#FFFFFF";
document.getElementById("mail").style.backgroundColor="#FFFFFF";
Ezek így külön tök feleslegesek, inkább pakold bele egy else ágba, mondjuk valahogy így:
if (nick.length<40)
{
document.getElementById("nick").style.backgroundColor="#FFDDDD";
submit = false;
}
else
document.getElementById("nick").style.backgroundColor="#FFFFFF";Ja, meg sokkal szebb és átláthatóbb lenne a kódod, ha egyszerűsítenéd a dolgokat, pl.:
var nick=document.getElementById("nick");
Ezután:
if (nick.value.length<40)
{
nick.style.backgroundColor="#FFDDDD";
submit = false;
}
Tehát itt egyszerűen már csak nick-kel hivatkozol rá, nincs még egy getElementById. -
dany27
őstag
áááá ez volt az utolsó gondolatom, de aztán lebeszéltek róla h a kis meg a nagybatű nem számít. Ezek szerint akkor igen is hogy számít!
Am ez miatt lehet az hogy nem "létezett" ez a funkció?? Mert beépítettem már utolsó lehetőségként egy elágazást amiben az function_exsists függvény ellenőrzi hogy létezik e a funkció. És ez is azt adta vissza hogy nincs!
Kössz!
-
dany27
őstag
hi
Gyakorlás képpen neki álltam irogatni egy PHP-n alapuló oldalt, de a regisztrációnál akadt egy kisebb gondom, úgy szeretném megoldani hogy egy javascript leellenőrizze hogy minden mező kivan-e töltve, s csak akkor engedje tovább. De valamiért nem megy. Írtam egy tök alap valamit s ha már ebbe megy akkor majd átültetem az oldalba.(Ebbe nincs SQL feldolgozás még mivel nem jutottam el odáig mert ez a szar javascript elvett minden időmet, de egy szerűen nem jövök rá hogy mi a gond!)
A kód:<html><head><script type="text/javascript">
function submit()
{
var nick=document.getelementbyid("nick").value;
var pass=document.getelementbyid("password").value;
var pass2=document.getelementbyid("password2").value;
var email=document.getelementbyid("mail").value;
document.getelementbyid("nick").style.backgroundcolor="#FFFFFF";
document.getelementbyid("password").style.backgroundcolor="#FFFFFF";
document.getelementbyid("password2").style.backgroundcolor="#FFFFFF";
document.getelementbyid("mail").style.backgroundcolor="#FFFFFF";
submit = true;
if (nick.length<4 || nick.length<40)
{
document.getelementbyid("nick").style.backgroundcolor="#FFDDDD";
submit = false;
}
if (pass.length<6 || pass.length<40)
{
document.getelementbyid("pass").style.backgroundcolor="#FFDDDD";
submit = false;
}
if (pass1!=pass2)
{
document.getelementbyid("pass").style.backgroundcolor="#FFDDDD";
document.getelementbyid("pass2").style.backgroundcolor="#FFDDDD";
submit = false;
}
if (email.length==0)
{
document.getelementbyid("mail").style.backgroundcolor="#FFDDDD";
submit = false;
}
if(submit == false)
{
return false;
}
else
{
return true;
}
}
</script></head></html>
<?php
print"<center><h2>Regisztráció</h2>";
print"<table align=\"center\"><form method=\"POST\" onSubmit=\"return submit()\" action=\"register.php\">
<tr><td>Nick Név</td><td><input type=\"text\" name=\"nick\" id=\"nick\"></td></tr>
<tr><td>Jelszó</td><td><input type=\"password\" name=\"password\" id=\"password\"></td></tr>
<tr><td>Jelszó ismét</td><td><input type=\"password\" name=\"password2\" id=\"password2\"></td></tr>
<tr><td>E-Mail</td><td><input type=\"text\" name=\"mail\" id=\"mail\"></td></tr>
<tr><td align=\"center\" colspan=\"2\"><input type=\"reset\" value=\"Újra\"><input type=\"submit\" value=\"Regisztráció\"></td></tr></form></table></center>";
?>Előre is kössz!
-
vakondka
őstag
válasz
Tele von Zsinór #3909 üzenetére
Köszi a tippeket, kipróbálom
-
Tele von Zsinór
őstag
válasz
vakondka #3905 üzenetére
"Mit kell változtatni" listára egy todo-kezelőt ajánlok, én a remember the milket használom (online, ingyenes).
Elvileg olyat is tud, hogy kiosztasz másnak feladatot, ezt a részét még nem próbáltam."Mit változtattam" listára pedig egy verziókövető kell neked, mint a git vagy az svn.
-
vakondka
őstag
Az aptana biztosan érdekes,de nem lehet letölteni, állandóan leáll a letöltés...
Alapvetően a "mit változtattam" és "mit kell változtatni" típusú dolgokat kellene kezelni
és sokszor 1-1 (félkész) scriptet is csatolnék hozzá, ezt valahogyan nem tudom elképzeni excelben, hogy átlátható maradjonÚgy láttam, hogy esetleg a Netbeans is valami hasonlót tud...?
-
cucka
addikt
-
ArchElf
addikt
válasz
vakondka #3905 üzenetére
Én az alábbit javasolnám:
PHP-hez Aptana (Eclipe alapú IDE) + verziókövetéshez SVN (pl VisualSVN szerver - a szerver komponens ingyenes).
Az SVN kiváló verziókövetésre és ennek dokumentálására, közös munkavégzésre, a Visual SVN szerveren még jogosultságok is beállíthatók.AE
-
vakondka
őstag
Lenne egy furcsa kérdésem, valójában nem is tudom milyen topic-hoz tartozik, de hátha tud valaki válaszolni, akinek nagy tapasztalata van...pl cucka
Azt tudni kell elöljáróban, hogy én nem tanultam sehol programozást legalábbis iskolában,
(leszámítva egy 60 órás tanfolyamot), mindent magamtól, internetről, könyvekből tanultam meg.
Most, hogy nagyon sok weblapot kellene folyamatosan karbantartanom felmerült a probléma,
hogy valahogyan menedzselni kellene ezeket, mert már képtelenség fejben tartani,
hogy mivel hol tartok, mit változtattam, mit kell változtatni, hol kell hibajavítás és hol kell írni valamilyen kiegészítést, új funkciót, stb.
A word és excell elég hamar ki lett lőve, mert semmire sem jó ilyen szinten, az outlook feladatkezelője az elején még egészen jónak tűnt de már látom, hogy pont azt nem tudja amire szükségem van, max feldobálja az ablakot, hogy ezt vagy az csináljam meg...
Én az esetek 90%-ban PHP-t használok tehát ha lenne bármilyen profi program ami ilyen módon segíti a weblap készítést (akár fizetős is) az nagyon jó lenne ha valaki tudna nekem ilyet ajánlani.
A csúcs az lenne, ha létezne olyan, amivel ki tudnám osztani a feladatokat és látnám ha kész (pl a grafikusnak)Előre is köszönök minden tippet, segítséget !
-
cucka
addikt
válasz
PazsitZ #3903 üzenetére
Még korábban én is barkácsoltam ilyen rövidítő kódot, de nem olyan egyszerű (még az enyém sincs kész csak félig-meddig ), mondjuk nálam az is szempont, hogy a szövegben lévő tag-ek is érvényesek maradjanak.
Pedig ez nem túl bonyolult feladat, a lényege, hogy szét kell bontani szavakra a szöveget. Kétfajta szó lesz benne: html tag-ek és sima szavak. Ezután végigmész a szavakon és a következő algoritmust használod (kell hozzá egy verem és fontos a sorrend):
- Ha az aktuális szó nem html tag, akkor kiírod az output-ra és növeled a kiírt karakterek/szavak számát.
- Ha az aktuális szó nyitó és záró tag egyben, akkor kiírod az output-ra. (Például ilyen a <br />, aminek nincs záró tag-je, mert már le van zárva).
- Ha az aktuális szó html nyitó tag, akkor kiírod az output-ra és a html tag-et lerakod a verembe. (tehát csak magát a tag-et, az attribútumokat nem). Példa egy veremre: {'span', 'a', 'div'}
- ha az aktuális szó egy html lezáró tag (pl. </div>), akkor kiírod az output-ra és a veremből addig dobálod ki a tag-eket, amíg ki nem dobtad az aktuális html lezáró tag párját.Az iterációnak akkor van vége, ha elfogytak a szavak, vagy a kiírt karakterek/szavak száma elérte az előre meghatározott limitet. Ezután a veremben maradt elemeket kidobálod és mindegyikre kiírod a hozzá tartozó lezáró html tag-et. (Tehát ha a verem tetején egy div tag van, akkor azt fogod kiírni, hogy </div>, ezután pedig kiszeded a veremből.
Az algoritmus pár lényeges tulajdonsága:
- Megőrzi a html tag-eket.
- Csak a képernyőn látható betűket/szavakat számolja, a html tag-eket nem.
- Ha a szövegedben vannak lezáratlan tag-ek, akkor is működik. Ha a szövegben olyan lezáró tag van, aminek nincs nyitó párja, akkor nem működik helyesen, de kiegészíthető, hogy erre az esetre is jó legyen.
- Az algoritmus kimenetében nem lesznek lezáratlan html tag-ek.
- Bizonyos tag-eket a böngészők automatikusan lezárnak (pl. br, hr), ezek felismerésével ki kell egészíteni az algoritmust. -
PazsitZ
addikt
Még korábban én is barkácsoltam ilyen rövidítő kódot, de nem olyan egyszerű (még az enyém sincs kész csak félig-meddig
), mondjuk nálam az is szempont, hogy a szövegben lévő tag-ek is érvényesek maradjanak. [link]
Igen abban az esetben az ékezetes karaktert mb_ fgv-el vagy más módon kell levágni. hogy ne vágjon félbe ékezetes karaktert. Szvsz érdemesebb lenne szóhatárra keresni és ott vágni. -
cucka
addikt
Attól függ, hogy mennyi memória van a gépben, mennyire sokan használják egyszerre a php-s szolgáltatásodat illetve hogy milyen egyéb programok futnak a gépen.
Ez a limit egyébként 1 php szál maximális memóriáját jelenti, tehát
- A php annyi memóriát foglal le a scriptednek, amennyire szüksége van. A maximális korlátot azért találták ki, hogy ha egy szerveren több php-s szoftvert is telepítettek, akkor egyik se tudja megenni a szerver memóriáját. (Pl. hosting szolgáltatónál nem fog előfordulni az, hogy egy rosszul megírt kód beakasztja a teljes szervert)
- Miután lefut a script, a php felszabadítja a neki lefoglalt memóriát.
- Ha a php szoftverednek 32 mega memóriára van szüksége, akkor állítsd be úgy. Annyit érdemes beállítani limitnek, ami biztosítja, hogy a futtatott php szoftverek ne fogyjanak ki a memóriából.
- Általában véve igaz, hogy egy bonyolult rendszernél a memóriahasználat leszorítása legalább egy nagyságrenddel drágább mulatság, mint a memóriabővítés a szerverben. Persze, van, amikor muszáj a kódot is átalakítani ehhez, de 32 megás max. memóriahasználat egyáltalán nem tűnik soknak. -
r3pl4y
aktív tag
A problémát az alap beállított memory limit okozza... felállítottam 32 megára az alap 8-at most már megnyitja a nagyobb méretű mailokat is... de az lenne a kérdésem, hogy menniyre ajánlott ezt max beállítani, gondolom nem kéne a csillagos égig felengedni ezt a limitet...
Új hozzászólás Aktív témák
Hirdetés
- RTX 4080 SUPER,16GB. Ryzen 7 7800X3D, 32 RAM Fury RGB! Garancia!
- Asztali PC , i7 9700K , RX 5700 XT , 32GB DDR4 , 500GB NVME , 1TB HDD
- Dell Inspiron 5406 2-in-1i5-1135G7 16GB DDR4 3200 512GB NVME 14" FHD Érintőkijelző W11Pro
- Eladó MacBook Pro 14" M1 Pro (2021) 16/512 99% akku Makulátlan állapotban!
- Újszeru GIGABYTE G5 - 15.6" FullHD 144Hz - i7-13620H - 48GB - 1TB - RTX 4050 - Win11 - 1,5 év gari
- 126 - Lenovo Legion Pro 7 (16IRX8H) - Intel Core i9-13900HX, RTX 4080 (ELKELT)
- ÁRGARANCIA!Épített KomPhone i5 13400F 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- AZONNALI SZÁLLÍTÁSSAL Eladó Windows 8 / 8.1 Pro
- AKCIÓ! Csere-Beszámítás! Gainward Phantom RTX 4070Ti 12GB GDDR6X Videokártya!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest