MYSQL adatbázis módos

June 29, 2015

Sziasztok!

Az alábbi probléma megoldásában szeretném kérni a segítségeteket:

Hogy lehet azt megoldani, hogy például az e-mail cím megadása után az űrlapra betöltöm a MYSQL adatbázisban található adatokat módosításra?

HTML űrlap:

<html>

<head>

<title>Űrlap</title>

<body>

<p>

</p>

<p>

<label for="tel">Telefonszám:</label>

</p>

</p>

<p>

</p>

<p>

<label for="rendeles">Rendelés:</label>

<option value="">Kérjük, válasszon!</option>

<option value="Sajtos pizza">Sajtos pizza</option>

<option value="Bolgonai pizza">Bolognai pizza</option>

</select>

</p>

................................

<button type="submit">Küldés</button>

<p>Módosítás</p>

<p>

<input type="text" name="email">E-mail cím:

</p>

/*Amikor itt beírják az e-mail címet, ha létezik az adatbázisban, akkor az űrlapra betöltené a MYSQL adatbázisból az adatokat.*/

<p>

Megadott adatok módosítása

/*Erre a gombra kattintva módosítaná az adatbázisban található adatokat*/

</p>

PHP feldolgozás:

<?php

$kapcsolat=mysql_connect("localhost","username","Password");

mysql_select_db("db",$kapcsolat);

mysql_set_charset("utf8",$kapcsolat);

$sqlutasitas="INSERT INTO table (nev, tel, cim, email, rendeles) VALUES ('$_POST[nev]','$_POST[tel]','$_POST[cim]','$_POST','$_POST[rendeles]')";

mysql_query($sqlutasitas);

mysql_close($kapcsolat);

print "<p align="Center">Köszönjük rendelését!</p>";

?>

Előre is köszönöm a segítséget!

Ha lehet, kérlek a kódot egészítsétek ki.

June 29, 2015

Amit itt megmutattál, minden szempontból hibás. Az űrlap felépítése, a HTML kódja, a PHP függvények használata, a kapott adatok feldolgozása, maga a módosítás megléte is kérdéses. A fenti kódot semmilyen formában ne használd élesben. Mielőtt nekilátnál egy weboldal, egy űrlap elkészítéséhez, vedd a fáradságot, és tanuld meg rendesen mind a HTML-t, az SQL-t, és a PHP nyelvet, legalább az alapvető dolgokat. Vagy keress valaki olyat, aki ért is hozzá, esetleg egy weboldalkészítő cégnél rendeld meg. Bár könnyedén ki tudnám javítani a kódodat, hogy az működőképes legyen, és csak fel kelljen tölteni a szerverre, ez a fórum nem arra van, hogy mások helyett dolgozzunk, hanem segítsünk, ha elakadtak.

A HTML alapok megtanulására ajánlom figyelmedbe a PC World Weboldalkészítő suli sorozatát. Nagyon jól bemutatják ebben a mai technikáknak megfelelő weboldal elkészítését.

A PHP és SQL megtanulásához magyar nyelvű leírást most nem igen tudok mondani. Ellenben angol nyelven elérhetőek a hivatalos dokumentációk, és számtalan tutorial. Keress rá! A w3schools oldalon jó leírást adnak az alap dolgok megtanulásához.

Ezekre a dolgokra kell figyled:

- <!DOCTYPE html> a kezdő elem.

- A head, body, html, és form tagok nincsenek lezárva. Ezeket minden esetben le kell zárni (pl. </head>, amikor vége a head-ba kerülő résznek).

- Az űrlap karakterkódolását be kell állítani, pl <meta charset="utf-8" />

- A labe-ek csak akkor működnek, ha van olyan input (vagy select, textarea), aminek az id tulajdonsága megegyezik a label for tulajdonságával.

- Az option-nak nem szövegben adjuk meg az értékét, hanem hozzárendelünk egy jelet (pl. számot), amit aztán a szerver oldalon azonosítunk, mint sajtos vagy gombás pizza.

- Az űrlap elküldésére <input type="submit" name="kuldes" value="Megrendelés" /> tagot használj. A button nem erre lett kitalálva.

- Align attribútumot nem használunk a szöveg helyzetének beállítására. Erre a CSS való.

- mysql_* függvényeket nem használunk. Az 5.5-ös verziótól kezdve hivatalosan is elavultak, nemsokára ki is lesznek véve, több mint egy évtizede nem frissítették ezeket a függvényeket. Helyette használj pl. PDO-t.

- Soha nem szabad összefűzni a query-t a felhasználó által megadott adatokkal. Ha jön egy trükkös felhasználó, ez által kitörölheti az egész adatbázist, miután kiolvasott onnan minden adatot, és kedvére felhasználta. Ha PDO-t használsz, erre megoldás, ha kapcsolódáskor beállítod a karakterkódolást, és bindParam/bindValue függvényeket használsz az értékek átadására.

- A felhasználó által megadott adatokat minden esetben ellenőrizni kell, hogy azok formailag megfelelnek-e annak, amit elvárunk (pl. az e-mail cím helyes legyen).

- Ahogy azt is ellenőrizni kell, egyáltalán kitöltötte-e a mezőt a felhasználó. Erre az isset függvény alkalmas.

- A feldolgozás (PHP) és megjelenítés (HTML) különüljön el egymástól. A feldolgozást rakd külön fájlba, vagy a megjelenítés elé.

- Használj tabulátorokat vagy szóközöket a HTML olvashatóságának javítására.

- Biztos vagy abban, hogy szükség van az adatok módosítására egy pizza rendelésénél? Inkább jól láthatóan írd ki, hogy ellenőrizzék le az adatokat elküldés előtt. Az viszont biztos, hogy az e-mail cím megadásával való azonosítás nem jó megoldás. Így bárki bármilyen e-mail címet beírhat, és hozzáfér egyből más felhasználók adataihoz, helytelenre/valótlanra változtathatja azokat. Ha mindenképp akarsz módosítási lehetőséget, valahogy erősítsd meg, hogy tényleg az a felhasználó módosítja, aki eredetileg megadta az adatokat. Erre alkalmas egy felhasználó-rendszer, vagy gyors bejelentkezés pl. Facebook-on vagy Google-n keresztül. De minimum egy 10-20 karakteres véletlenszerűen generált kód eltárolása egy cookie-ben és az adatbázisban.

- Pontosan mi is az, amit nem tudsz? Az adatbázisból kilistázni az adatokat egy SELECT, módosítani pedig egy UPDATE paranccsal lehet.

Érdekes, azt írja a fórum, doctorwho-nak 22 hozzászólása van, de rákeresve csak 2-t jelenít meg.

June 29, 2015

- a kezdő elem.

Ez eddig ok.

- A head, body, html, és form tagok nincsenek lezárva. Ezeket minden esetben le kell zárni (pl. , amikor vége a head-ba kerülő résznek).

Ezt én is így "tanítom", de nem igaz. Ez egy teljesen valid, mini HTML5 dokumentum:

<!doctype html>
<html lang=en>
<head>
<meta charset=utf-8>
<title>blah</title>
</head>
<body>
<p>I'm the content

- Az űrlap karakterkódolását be kell állítani, pl

Nagyon kevés kivételtől teljesen felesleges, soha egyetlen formomban nem használtam még.

- A labelek csak akkor működnek, ha van olyan input (vagy select, textarea), aminek az id tulajdonsága megegyezik a label for tulajdonságával.

:igen:

- Az option-nak nem szövegben adjuk meg az értékét, hanem hozzárendelünk egy jelet (pl. számot), amit aztán a szerver oldalon azonosítunk, mint sajtos vagy gombás pizza.

Teljesen fakultatív. Hagyományosan számmal szokták demózni, de azt használsz benne, amit jónak látsz. Ha a select tartalma, például, egy asszociatív tömbből jön, akkor szöveges lesz a value.

- Az űrlap elküldésére tagot használj. A button nem erre lett kitalálva.

Na, ennél döntöttem el, hogy mégis válaszolni fogok... Ezt fejtsd ki, kérlek, mert ezek szerint teljes tévedésben élek és írom a formjaimat. Elképzelésem nincs, mikor használtam utoljára ...

...és bindParam/bindValue függvényeket használsz az értékek átadására.

Vagy egyszerűen a PDO::query-t, aminek paraméterként adod át az adatokat egy tömbben.

...egyáltalán kitöltötte-e a mezőt a felhasználó. Erre az isset függvény alkalmas.

Checkboxra és rádiogombra valóban, de a szöveges inputok, ha üresen hagyod őket, simán bejönnek a GET-be vagy a POST-ba üresként. Ebben az esetnem egy isset() - true nem jelent semmi értelmeset.

- Használj tabulátorokat vagy szóközöket a HTML olvashatóságának javítására.

Azt lehet, hogy használt szegény, ám mivel nem rakta kódblokkba a kódot, így a fórummotor szépen megszabadította tőle.

A többiben igazad van.

---------------------------------------------------

Átpakoltam az egészet a PHP-ba, lévén ennek a kérdésnek gyakorlatilag semmi köze az adatbázis-kezeléshez. Egyben felhívnám a témanyitó figyelmét a PHP téma tetején olvasható figyelmeztetésre:

Figyelem! Nagyon szépen megkérek minden érdeklődőt, hogy nulla PHP tudással ne tegyen fel kérdéseket!

A dolog nem így működik. Ez egy programozási nyelv, egy technológia, ezt legalább alapszinten meg kell tanulni, ha boldogulni akarsz. Enélkül legfeljebb megírjuk neked, amit szeretnél, amivel utána vagy tudsz kezdeni valamit, de inkább nem, ami további felesleges kérdéseket szül. Ennek semmi értelme, csak raboljuk egymás idejét. Mi sem úgy születtünk, hogy értettünk a PHP-hoz, időt és energiát fektettünk abba, hogy megtanuljuk. Tedd te is ezt, és örömmel segítünk!

Tudom, hogy ez úgy hangzik, mintha nem volnánk valami segítőkészek, de a fenti kód alapján teljesen egyértelmű, hogy fogalmad nincs arról, amit csinálsz vagy csinálni akarsz. Hogy egy hasonlattal éljek, ez olyan, mintha adnál nekünk egy félig magyar, félig kínai szöveget, hogy a magyar részeket fordítsuk le kínaira, és írjunk még hozzá két bekezdést a cseresznyefák virágzásáról, mert holnap el kell mondanod valahol ezt a szöveget, miközben egy szót nem tudsz kínaiul. Ebben egyszerűen nem tudunk segíteni.

June 29, 2015

Ezt én is így "tanítom", de nem igaz. Ez egy teljesen valid HTML5 dokumentum:

Igen, ezt én is tudom. De még megemlíteni sem látom értelmét. Minek? Normális weboldalaknál az a +10 karakter kiírása nehogy már gondot okozzon, cserébe azonban egységes felépítést kapunk. Tesztoldalaknál meg úgy se azzal foglalkozunk, valid-e az oldal.

Nagyon kevés kivételtől teljesen felesleges, soha egyetlen formomban nem használtam még.

Miért lenne felesleges? Össze kell egyeztetni a karakterkódolásokat, ami a fájlokban és az adatbázisban van. Persze elhagyható, de nem árt semmit se, ha odaírja hogy milyen a karakterkódolás.

Teljesen fakultatív. Hagyományosan számmal szokták demózni, de azt használsz benne, amit jónak látsz. Ha a select tartalma, például, egy asszociatív tömbből jön, akkor szöveges lesz a value.

Persze, bármi lehet, de nem megyünk semmire a bármivel. Korábban neked sem volt bajod vele.

Na, ennél döntöttem el, hogy mégis válaszolni fogok... Ezt fejtsd ki, kérlek, mert ezek szerint teljes tévedésben élek és írom a formjaimat. Elképzelésem nincs, mikor használtam utoljára <input type="submit"-ot>...

Hát... A kettő között csak annyi eltérés van, hogy a button-on belül lehet más tartalom is (nem csak szöveg). Szóval végül is mindegy, melyiket használjuk. De az input megszokottabb a form-okon belül, még a buttont inkább kattintáskor érdemes használni. Legalábbis bennem így alakult ki. Ez kb. olyan mint a b vs strong, mindkettővel elérhető ugyan az, de csak hogy lehessen vitázni meg hibázni, van nekünk két tag.

Vagy egyszerűen a PDO::query-t, aminek paraméterként adod át az adatokat egy tömbben.

Ezt honnan szedted? A dokumentáció nem ír ilyenre lehetőséget.

Checkboxra és rádiogombra valóban, de a sima szöveges inputok, ha üresen hagyod őket, simán bejönnek a GET-be vagy a POST-ba üresként.

Ez igaz, előtte az adatok ellenőrzésébe beleértettem ezt is, de előtte isset kell, mert ha el sincs küldve, akkor az empty($_POST["a"])-ra hibát adna.

June 29, 2015

Miért lenne felesleges? Össze kell egyeztetni a karakterkódolásokat, ami a fájlokban és az adatbázisban van. Persze elhagyható, de nem árt semmit se, ha odaírja hogy milyen a karakterkódolás.

Igen, de ennek az a legegyszerűbb módja, ha minden UTF-8-ban van, és a

-ben ezt megadjuk charsetként. Azzal, hogy különböző kódolású weboldalt, adatbázist és esetleg PHP-fájlokat használunk, sok értelmét nem látom, hacsak nem az a cél, hogy irgalmatlanul megszívassuk magunkat. Másfél éve álltunk át latin2-ről UTF-8, mind a mai napig találok latin2-es kódolású PHP fájlokat a rendszerben. Agyrém.

Korábban neked sem volt bajod vele

Öööö... Igen, oda akartam még írni, hogy ezen nyilván nem azt értem, hogy kisregényt kell írni a value-ba. Amiről a másik témában inkább szó volt, az az ilyen jellegű adatok tárolása adatbázisban. Néha azonban jól esik, ha egy adatsorból ránézésre látom, hogy az mit jelent, és nem kell egy külön táblát megnyitni azért, hogy kiderüljön. Például a szállítási és fizetési módjaink nincsenek adatbázisban tárolva, azok egy közös modul ősről származtatott objektumok, és mindegyiknek van egy saját, egyedi class tulajdonsága (ami egyébként sokkal inkább id, de történelmi okokból classnak hívják mind a mai napig), ez kerül bele a rendelésbe is. Amikor admin oldalon a rendelések listájánál szűrni kell különböző feltételek szerint, ezekben a

De az input megszokottabb a form-okon belül, még a buttont inkább kattintáskor érdemes használni.

A

Ezt honnan szedted? A dokumentáció nem ír ilyenre lehetőséget.

Ezt, kérlek, onnan szedtem, hogy péntek óta keveset alszom. Bocs. Nyilván a DB classunknak van quote metódusa, ami kap $sql-t placeholder stringekkel és asszoc tömböt, hogy mit mire kell cseréljen, és végül az egész egy PDOStatement::execute()-ban köt ki, mert ott már lehet ilyet.

(De jó végre beszélgetni valakivel ilyesmikről! )

June 29, 2015

A HTML5 szabvány szerint az UTF-8 kódolás az alapértelmezett érték, szóval csak akkor kell megadni, ha ettől eltérünk (persze, akkor nem UTF-8-at kell adni. ) Elférni viszont elfér a kódban.

A tageket tényleg nem kell zárni, de én is jobban szeretem, ha zárva vannak. Arról nem is beszélve, hogy a normális szerkesztő eszközök automatikusan zárják őket. Még a Notepad++ is tudja ezt, igaz kell hozzá egy kiegészítő.

ASP.NET esetén a button formon kívül is használható, simán ráakasztható egy függvény hívás. Bár PHP-vel nem nagyon foglalkoztam, de elméletileg ott is kéne mennie a dolognak. Az már más kérdés, hogy ASP.NET esetén a formnak nem kell form tagek között lennie, mert a model alapján így is megtalálja az adatokat. Nem szép dolog, de működik. Bár ha meg kéne nézni mi az amit ASP.NET megenged, és amit PHP-ben nagyon nem kéne csinálni, szerintem páran tépnék a hajukat tőle.

June 29, 2015

A HTML5 szabvány szerint az UTF-8 kódolás az alapértelmezett érték, szóval csak akkor kell megadni, ha ettől eltérünk

Forrás?

Amennyire meg tudom ítélni, ez olyannyira nincs így, hogy a HTML5 szabvány konkrétan leírja, hogy hogyan, milyen lépésekkel kell meghatározni egy weboldal karakterkódolását, ha az nincs deklarálva. Ráadásul régebbi IE-eket könnyen be lehet csapni, ezért fontos, hogy mindig deklaráljuk a karakterkódolást.

...ASP.NET esetén a button formon kívül is használható, simán ráakasztható egy függvény hívás.

Hogyan? Azt nem tudom, hogy az ASP.NET-nél ez hogy megy, de a PHP egy szerveroldali nyelv, ami azt jelenti, hogy a világon semmit nem "lát" abból, hogy mi történik az általa legenerált és a böngészőnek elküldött weboldalban. JS-ből akasztható rá, persze, de ha megfeledkezünk arról, hogy JS nélkül is működnie kell a gombnak, máris megsértettük a progressive enhancement valamint a graceful degradation alapelveket, és ott találjuk magunkat a szürkületi zónában.

June 29, 2015

Ez kb. olyan mint a b vs strong, mindkettővel elérhető ugyan az, de csak hogy lehessen vitázni meg hibázni, van nekünk két tag.

A <b> és a <strong> között van különbség, mégpedig az, hogy ha egy szövegfelolvasó-szoftver elolvassa a <strong> taget, akkor a benne lévő szöveget jobban kihangsúlyozza, míg a <b> tag csak a kinézetét állítja félkövérre. Hasonló a helyzet az <i> és az <em> párossal is.

Ez így lehet, hogy csak apróságnak tűnik, de akadálymentesített weboldalak készítésénél jól jöhet ez a tudás.

June 29, 2015

Igen, de ennek az a legegyszerűbb módja, ha minden UTF-8-ban van, és a <head>-ben ezt megadjuk charsetként.

Itt valamit valamelyikőnk rosszul értelmezett, mert a válaszaid alapján nekem úgy jön le, te is azt mondod, hogy legyen az adatbázisban lévő adat karakterkódolása valami (UTF- és ugyan ezt állítsuk be a head-ban is egy meta segítségével. A fent bemásolt kódban nem volt ez meg, ezért mondtam hogy rakja oda. Mit kell másként csinálni szerinted?

A <button>

Oké, én ezt értem, de akkor most melyiket mire használjuk? Vagy teljesen mindegy, kinek melyik tag a szimpatikusabb? Feltételezhetjük, hogy a régi szokások támogatásán kívül más oka is van, hogy két tag alkalmas ugyan arra a feladatra. Rákerestem most, de nem igazán modtak konkrétimut a nagyok se, mikor melyiket használjuk.

Én viszont egyáltalán nem értem, mi szükség van a buttonra. Tök jó, hogy írhatok bele további tagokat, de mégis miért tenném? A gombok arra vannak, hogy egyszerűen rájuk kattintsunk, aztán valami történik. Más feladatot ne a button lásson el, ne jelenítsünk meg bennük részeredményeket stb. Ha pedig akarsz egy képet/ikont a gombra, minden egyes alkalommal beírni a button közé az img-et eléggé butaság lenne, amikor CSS-vel be lehet állítani a hétteret, a paddinggal vacakolva a megfelelő helyre rakni a szüveget. Ígyhét nem marad más, minthogy a button és az input ugyan az lesz a HTML fájlban, csak másként leírva. Vagy tudsz mutatni egy konkrét példát, ahol annyira szükség van a terjedelmes tartalomra, és indokolt, hogy egy űrlapnl használatos gomb tagját használják ott, ne pl. egy divet, amit js-sql kezelnek?

A <b> és a <strong> között van különbség, mégpedig az, hogy ha egy szövegfelolvasó-szoftver elolvassa a <strong> taget, akkor a benne lévő szöveget jobban kihangsúlyozza, míg a <b> tag csak a kinézetét állítja félkövérre. Hasonló a helyzet az <i> és az <em> párossal is.

Ez igaz, de pont azért, mert ma már nincs támogatva a b. Mert a nagyok azt mondták, hogy az egy csúnya elem, és aki formázást akar, az használjon strong-ot vagy css-t. Éppen e miatt már senkinek sem javasoljuk, hogy a b tagot használja. Na, ez a nem javasoljuk szerintem érvényes a button-input párosra is. Két tag ugyan arra a funkcióra nem kell. Döntsük el mlyiket használjuk, és legyen az egységes. Én amondó vagyok, hogy ha valaki túlformázott szöveget, táblázatot, vagy 5 képet akar egy button-on belülre zsúfolni, az valamit rosszul csinál. Az input-okat is tökéletesen lehet formázni, úgy, hogy azok szép gömbök legyenek. Hála a CSS3-nak már mindenféle trükközés lehetséges.

June 30, 2015

Szia!

Ahol elakadtam: Azt szeretném megvalósítani, hogy az e-mail cím megadása után ellenőrzőm, hogy szerepel-e az adatbázisban a megadott e-mail cím, ha igen, akkor az űrlapra betölteném az adatbázisból a megadott e-mail címhez tartozó adatokat.

Ezt követően lehetőség lenne az adatok módosítására.

June 30, 2015

Az a baj, hogy a fenti dologban nem lehet e-mail címet megadni. Az egésznek semmi értelme nincs. Ha egy picit belegondolsz, vizuálisan, nem kérheted el az email címet utoljára, ha az összes többi adat szerkesztése ettől függ. Főleg nem lehet egyetlen "Módosít" gombod, mert egy email cím mező és egy Módosít gomb együtt azt jelenti, hogy módosítod az email címet.

Szóval első körben hagyd a PHP-t, dolgozzál a HTML-en, csinálj egy normális formot, amiben a bekérni kívánt adatok a megfelelő sorrendben vannak. Ha nem tudod elsőre megcsinálni, akkor rajzold le, a lényeg az, hogy __gondolkodj__ rajta. Aztán mutasd meg, mire jutottál, onnan megyünk tovább.

----

A

Oké, én ezt értem, de akkor most melyiket mire használjuk?

A HTML4-ben bevezetett

Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. For example, a BUTTON element that contains an image functions like and may resemble an INPUT element whose type is set to “image”, but the BUTTON element type allows content.

Mondjuk, próbálj meg inputtal olyan gombot csinálni, amiben szöveg van, és mellette icon fontból valamilyen ábra. Szerintem nem lesz egyszerű.

June 30, 2015

Arra valóban nem alkalmas. Még nem kellett ilyet csinálnom, mindenre jó volt az input, így azt szoktam meg. De ha mindenre jobb a button, akkor miért, mire, mikor használjuk az input-ot? Csak kell hogy legyen indoka amiért nem dobták ki a HTML5 bevezetésekor, mondván ott a button, az jobb, használjátok azt.

June 30, 2015

Szerintem ne csinálj ebből magadnak problémát, használd tovább nyugodtan az inputot. Soha semmit nem dobnak ki, ott van benne a

meg az összes ilyen elavult dolog. Igaz, azokra azt mondják, hogy elavult, az -ra meg nem. Fakultatív, azt használod, amelyik tetszik.

Én jobban szeretem, hogy ránézésre meg tudom mondani, hogy mi input mező és mi gomb. Ennyi.

June 30, 2015

...ASP.NET esetén a button formon kívül is használható, simán ráakasztható egy függvény hívás.

Hogyan? Azt nem tudom, hogy az ASP.NET-nél ez hogy megy, de a PHP egy szerveroldali nyelv, ami azt jelenti, hogy a világon semmit nem "lát" abból, hogy mi történik az általa legenerált és a böngészőnek elküldött weboldalban. JS-ből akasztható rá, persze, de ha megfeledkezünk arról, hogy JS nélkül is működnie kell a gombnak, máris megsértettük a progressive enhancement valamint a graceful degradation alapelveket, és ott találjuk magunkat a szürkületi zónában.

WebForms esetén simán csinálhatsz neki egy onclick eseményt (:NEt-eset, nem JS alapút), amivel meghívod a C#-ban megírt függvényt, MVC esetén pedig többek közt @Html.Actionnal tudod elérni a C# kódot. Ezek ugyan JS kódokat fognak generálni a weblapba, de letiltott JS mellett is futnak, különben nem működnének a .NET-es weblapok. Viszont csak a generált JS fog lefutni, az általad írt kód nem, ha ki van kapcsolva a JS támogatás. Egyedül akkor van probléma, ha a böngésző nem támogatja a JS-t. De ilyent manapság egész nehéz találni.

June 30, 2015

Nem tudsz összerakni valami nyilvánosan látható helyen egy példát? Én olyat még nem láttam, hogy letiltottam a JS-t, de bizonyos JS-re lefordult kódok mégis futottak volna... Kicsit nehezen tudom elképzelni, hogy az ilyenkor kiiktatott JS-értelmező helyett mi a búbánat futtatja a JS kódot?

June 30, 2015

Ha nem felejtem el, akkor holnap legenerálok egy alap oldalt, és kirakom felhőbe.

June 30, 2015

Nagyon köszi.

July 1, 2015

WebForms: http://webforms6180.azurewebsites.net/

Forráskód: https://drive.google.com/file/d/0BxlXELI1pogYYzM0YzBKd0twWjg/view?usp=sharing

MVC: http://mvc2314.azurewebsites.net

Forráskód: https://drive.google.com/file/d/0BxlXELI1pogYcG56VmF2ZVM1NUk/view?usp=sharing

Mondjuk most nem sok JS-t tartalmaz a kód, mert ezek csak az alap sablonok.

A szerverre jóval kisebb méretű weblap kerül fel, mint a forráskód. Ennek egyik oka, hogy a .NET alapból fent van a szerveren, így azt nem kell felmásolnia, továbbá a forráskód se kerül fel, helyette 1 darab DLL-be fordított (és így tömörített) fájl kerül fel. A "HTML" (WebForms esetén ASPX, MVC esetén CSHTML) viszont felkerül.

July 1, 2015

Mit kéne lássak? Olyan, mintha valami default ASP.NET honlap volna, Learn more gomb, meg Microsoftra mutató linkek...

July 1, 2015

Csak az, nem írtam bele semmit, csak amit a VS legenerál egy új projekt esetén. A forráskódot megnézve, van pár hivatkozás, amit JS-en keresztül hív be. De ha gondolod rakhatok bele további funkciókat, ami JS-t generál.

July 1, 2015

Megnéztem őket JS nélkül és JS-sel együtt, nem látok különbséget sem kinézet, sem a fő strukturális HTML-kód, sem a működést tekintve. Amennyire meg tudom ítélni, pont ugyanaz a kód van mindkét böngészőfülön, annyi különbséggel, hogy az egyikben nem fut a JS. És tényleg nem fut, mert a Chrome ilyenkor nem látja a JS fájlokat, nem lehet őket megnyitni, nem lehet debug pontokat beállítani.

Szóval, akkor ez most mire példa? :hmm:

July 2, 2015

Mondjuk speciel chromal nem teszteltem, de amikor nézegettem, akkor IE, Firefox és Opera alatt is ment a JS kód kikapcsolt állapotban is. Bár tény, hogy ennek is volt vagy 2 éve.

July 2, 2015

Menni megy, csak kérdés hogy hogyan. A belépésnél ha nincs JS, akkor elküldi a formot, és utána írja ki a hibát. Ha van js, form elküldése nélkül ellenőrzi az adatokat. Pedig te azt állítod, kikapcsolt JS mellett is futna a JS, szóval nem kéne elküldenie.

July 9, 2015

Ha kikapcsolt JS mellett fut a JS a kliens gépén, azt úgy hívják, hogy bug. Hogy a Microsoft erre építsen valamely megoldásában, jobbára teljesen kizárt.

MYSQL adatbázis módos

Recommended Posts

doctorwho 0

Link to comment

Share on other sites

kléni 7

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

kléni 7

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

[OP]Destroy-man 160

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

Dani991 47

Link to comment

Share on other sites

kléni 7

Link to comment

Share on other sites

doctorwho 0

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

kléni 7

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

[OP]Destroy-man 160

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

[OP]Destroy-man 160

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

[OP]Destroy-man 160

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

[OP]Destroy-man 160

Link to comment

Share on other sites

payskin 917

Link to comment

Share on other sites

[OP]Destroy-man 160

Link to comment

Share on other sites

kléni 7

Link to comment

Share on other sites

Fujitsu 812

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Browse