content top

Request-urile http – cand si de ce sa folosim GET sau POST

Request-urile http – cand si de ce sa folosim GET sau POST

M-am gandit ca ar fi momentul sa vorbim putin despre request-urile http. Desi ele nu sunt nici pe departe un subiect nou, ele au inceput sa fie folosite explicit de catre programatori numai de cativa ani.

De ce spun explicit? Pentru ca in mod implicit le folosim cu totii, de multe ori fara sa ne dam seama. Cand scriem un URL in bara de adrese a browser-ului, acesta face un request http catre server pentru a incarca pagina pe care am cerut-o. La fel, de cate ori completam un formular si apasam Submit, facem un request http catre fisierul de pe server ce proceseaza informatiile pe care i le-am dat.

Deci de unde discutia despre GET si POST? Pentru ca in modul “implicit” despre care am vorbit mai sus, si-au batut altii capul in locul nostru. Browser-ul face in mod implicit cereri prin GET, iar formularele (daca nu se specifica altceva), trimit datele prin POST. De ce sa ne mai batem capul?

Simplu. In ultimii ani, tehnologia AJAX a castigat foarte mult teren in aplicatiile web. Ea este disponibila demult, dar pana la aparitia librariilor JavaScript (jQuery, Prototype, etc.) era destul de laborioasa. Se folosea un obiect de timp XMLHttpRequest care trebuia instantiat diferit in functie de suportul oferit de diferite browsere.

Mai mult, datele odata aduse de pe server trebuiau parsate “manual” si inserate acolo unde aveam nevoie in pagina. Pe scurt, se putea dar era greoi.

Insa de cand librariile mai sus mentionate ne-au scapat de partea laborioasa a AJAX-ului noi, programatorii, putem sa ne concentram asupra partilor importante in lucrul cu aceasta tehnologie. Si pentru ca AJAX stie sa faca reuqest-uri atat prin GET cat si prin POST, ramane la latitudinea noastra sa decidem ce metoda folosim.

Astfel ca ajungem la intrebarea din titlu. Cand folosim GET si cand folosim POST; si mai ales, de ce?

Sa analizam pentru inceput numele celor doua metode. Prima se numeste GET, care ne duce de prima data cu gandul la “a aduce”. Deci metoda GET a fost gandita pentru a aduce date de pe server (cum ar fi incarcarea unei pagini in browser).

In schimb, metoda POST vine de la “a pune” sau “a trimite”. Ea este folosita atunci cand vrem sa trimitem date catre server pentru a fi prelucrate de acesta.

Bine bine, dar exista vreo diferenta intre ele? Ce ne opreste sa submitem un formular prin GET? Sau sa facem un request AJAX prin POST, chiar daca vrem numai sa aducem date de pe server? NU. Ambele requesturi vor avea efectul dorit.

Dar asta nu inseamna ca vor fi corecte. Nu uitati ca exista doua metode pentru ca ele se comporta diferit. De exemplu GET este supus cache-ingului, in timp ce POST nu. Iar metoda post ascunde parametrii trimisi din browser, pe cand GET ii va insira pe toti in bara de adresa.

Evident, AJAX-ul a fost folosit ca exemplu. Request-urile http pot fi facute prin socket-uri din PHP, sau prin alte metode proprietare folosite de diverse limbaje de programare.

Ce trebuie sa tinem minte? Desi aparent functioneaza la fel, GET si POST au fost gandite pentru scopuri diferite si ar trebui sa avem grija cum folosim flexibilitatea de alege intre cele doua metode.

Read More

Intreaba-ma: Executarea de scripturi PHP asincron

Intreaba-ma: Executarea de scripturi PHP asincron

Am fost abordat de unul din cititorii mei cu urmatoarea situatie (am sa reproduc felul in care a pus el problema):

Avem de-a face cu o pagina simpla (un HTML, sa zicem) care contine un formular; o vom numi pagina A. Pagina A face submit catre un script PHP, pe care-l vom numi B si care dupa ce termina ce are de facut redirecteaza utilizatorul catre pagina C (un landing page).

Deci care e problema? Pai, problema e ca scriptul B ruleaza cam mult (trimite o serie de email-uri) si utilizatorul sta si asteapta ca browser-ul sa incarce “ceva”.

Gabriel a venit cu o solutie interesanta la aceasta problema. A cautat un preloader care sa ruleze in timp ce se incarca scriptul B. Nu-i rau, dar eu cred ca aici se preteaza bine un AJAX. In general pentru astfel de situatii executarea asincrona este cea mai buna solutie.

Vezi Demo

Avand in vedere noile informatii, abordarea va fi in felul urmator: Pagina A face un request AJAX catre scriptul B si asteapta un raspuns. Intre timp afisaza o imagine de loading… (sau orice altceva). Cand termina ce are de facut, scriptul B il anunta pe A ca este momentul sa faca un redirect; catre landing page-ul C.

Bun, acum ca am vauzut despre ce-i vorba, sa descuram putin itele problemei. Vom incepe prin a da nume descriptive fisierelor, ca sa nu ne mai incurcam in litere.

Fisierul care contine formularul se numeste index.php si contine urmatorul cod:

<!DOCTYPE html>
<html lang="en">

<head>
	<title>AJAX Submitter</title>
	<link rel="stylesheet" href="style.css" type="text/css" />
</head>

<body>

	<div id="wrapper">
		<form method="POST" action="submit.php">
			<p>
				<label for="name">Name</label>
				<input type="text" name="name" id="name" />
			</p>
			<p>
				<label for="email">Email</label>
				<input type="text" name="email" id="email" />
			</p>
			<p>
				<label for="message">Message</label><br />
				<textarea name="message" cols="50" rows="7"></textarea>
			</p>
			<p>
				<input type="submit" value="Send" id="submit" />
				<img id="spinner" src="loading.gif" style="display:none; float: right;" />
			</p>
		</form>
	</div>

</body>

</html>

Codul este cat se poate de simplu, ca sa nu pierdem din vedere scopul principal. Dupa cum vedeti, formularul face submit catre un fisier PHP numit sugestiv submit.php.

<?php

session_start();

$name = "No name sumbitted";
if(isset($_POST["name"]))
	$name = $_POST["name"];

$email = "No email sumbitted";
if(isset($_POST["email"]))
	$email = $_POST["email"];

$message = "No message sumbitted";
if(isset($_POST["message"]))
	$message = $_POST["message"];

$_SESSION["name"] = $name;
sleep(3);
$_SESSION["email"] = $email;
sleep(3);
$_SESSION["message"] = $message;
sleep(3);

header("Location: landing.php");

?>

Codul este irelevant. L-am pus acolo doar ca sa execute ceva in spate. Mai mult, observati folosirea functiei sleep() de cateva ori. Asta ca sa simuleze faptul ca scriptul dureaza ceva mai mult decat in mod normal.

Dupa ce se executa codul, trimitem utilizatorul la un landing.php ca sa-l anuntam ca totul s-a intamplat cu succes. Codul arata asa:

<?php session_start(); ?>
<!DOCTYPE html>
<html lang="en">

<head>
	<title>AJAX Landing</title>
	<link rel="stylesheet" href="style.css" type="text/css" />
</head>

<body>

	<div id="wrapper">
		<h3>The following data has been sumbitted</h3>
		<p>Name: <?php echo $_SESSION["name"] ?></p>
		<p>Email: <?php echo $_SESSION["email"] ?></p>
		<p>Message: <?php echo $_SESSION["message"] ?></p>
	</div>

</body>

</html>

In momentul de fata avem exact situatia despre care vorbeam mai sus. La click, user-ul este trimis la submit.php unde nu vede decat o fereastra goala pana se executa codul. Abia la final este trimis catre landing.php.

Ca sa rezolvam problema, vom executa scriptul submit.php asincron. Ca sa ne fie mai usor, vom apela la jQuery pentru partea de AJAX.

Mai intai includem libraria jQuery:

	<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>

Apoi, tot ce trebuie sa facem este sa adaugam cateva linii de cod. Explicatiile le gasiti in comentarii la fiecare linie de cod unde acest lucru este necesar. P.S. Daca vi se pare greu de citit, il aveti mai jos fara comentarii (plus arhiva de la final):

	$(document).ready(function() {
		$("#submit").click(function(event) { // Declansam la click pe Submit
			event.preventDefault(); // Avem grija sa nu mai faca submit clasic
			$.ajax({
				url: "submit.php", // Unde facem requestul AJAX
				beforeSend: function() { // Inainte de request executam:
					$("#submit").css("display", "none"); // Ascundem butonul de submit
					$("#spinner").css("display", "block"); // Incarcam un loader (un gif)
				},
				type: "POST",
				data: ({
							name: $("#name").val(), // Luam valoarea lui 'name' pentru submit
							email: $("#email").val(), // Luam valoarea lui 'email' pentru submit
							message: $("#message").val() // Luam valoarea lui 'message' pentru submit
				}),
				success: function(msg) {
					window.location.replace("landing.php"); // La final, redirectam utilizatorul la landing.php
				}
			});
		});
	});

La final, ar trebui sa obtinem un fisier index.php care arata asa:

<!DOCTYPE html>
<html lang="en">

<head>
	<title>AJAX Submitter</title>
	<link rel="stylesheet" href="style.css" type="text/css" />
	<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>
	<script type="text/javascript">
		$(document).ready(function() {
			$("#submit").click(function(event) {
				event.preventDefault();
				$.ajax({
					url: "submit.php",
					beforeSend: function() {
						$("#submit").css("display", "none");
						$("#spinner").css("display", "block");
					},
					type: "POST",
					data: ({
							name: $("#name").val(),
							email: $("#email").val(),
							message: $("#message").val()
					}),
					success: function(msg) {
						window.location.replace("landing.php");
					}
				});
			});
		});
	</script>
</head>

<body>

	<div id="wrapper">
		<form method="POST" action="submit.php">
			<p>
				<label for="name">Name</label>
				<input type="text" name="name" id="name" />
			</p>
			<p>
				<label for="email">Email</label>
				<input type="text" name="email" id="email" />
			</p>
			<p>
				<label for="message">Message</label><br />
				<textarea name="message" cols="50" rows="7"></textarea>
			</p>
			<p>
				<input type="submit" value="Send" id="submit" />
				<img id="spinner" src="loading.gif" style="display:none; float: right;" />
			</p>
		</form>
	</div>

</body>

</html>

Dupa cum vedeti, n-am schimbat nimic in fisierele submit.php si landing.php. Am schimbat numai modul in care apelam aceste fisiere.

Acestea sunt elementele de baza pe care trebuie sa le stim pentru a oferi utilizatorului o experienta mai eleganta cu ajutorul AJAX.

Descarca arhiva

Read More

S-a lansat jQuery 1.6.1

S-a lansat jQuery 1.6.1

Se pare ca echipa de dezvoltare de la jQuery nu sta nicio clipa. La mai putin de 6 luni de la lansarea lui jQuery 1.5 si a lui 1.5.1 se pare ca deja avem de-a face cu versiunea 1.6.1.

Tineti cont, nu vorbim de jQuery 1.6. Acela s-a lansat deja pe data de 3 mai. Acum deja vedem primul update, ceea ce inseamna ca ritmul de dezvoltare este foarte rapid.

Daca folositi jQuery in activitatea de dezvoltare, va sfatuiesc sa cititi articolul de pe blogul lor, intrucat acesta contine atat modificarile care au aparut in aceasta noua versiune, cat si un mic ghid de upgrade de la 1.5.2 la 1.6.1.

Aveti grija, se pare ca unele lucruri s-au schimbat destul de mult, asa ca sfatul meu este sa cititi ghidul; aviz celor ce folosesc in mod constant .attr().

Read More

Resurse utile pentru dezvoltatorii ColdFusion

Resurse utile pentru dezvoltatorii ColdFusion

Acest articol este dedicat celor ce, la fel ca si mine, descifreaza limbajul de programare ColdFusion. Eu studiez acest limbaj de mai bine de doi ani (desi scriu doar de cateva luni despre asta) si in tot acest timp am adunat diverse resurse care sa-mi vina in ajutor.

Resursele sunt atat blog-uri si site-uri cu informatie de calitate despre ColdFusion, cat si instrumente menite sa ne faca viata mai usoara.

Sa la luam pe rand, asadar:

Raymond Camden (aka ColdFusion Jedi). Mare fan Star Wars si expert certificat in ColdFusion. Pe blogul lui veti gasi articole care trateaza tehnici de zi cu zi, articole pe care veti dori sa le adaugati in bookmarks pentru a reveni la ele la un moment dat.

Mai mult, o parte din articole vin ca raspuns la problemele pe care le intampina cititorii sai, asa ca sunt intotdeauna infipte in realitate. Bonus: in ultimul timp scrie foarte mult despre jQuery si jQuery Mobile.

Ben Nadel este vesnicul curios. Pe blogul sau veti gasi raspunsuri la intrebari despre care nu stiati ca exista. Merge intotdeauna mai departe si incearca sa inteleaga ce se intampla in spatele tag-urilor si functiilor din ColdFusion.

Articolele sale sunt foarte riguros documentate si contin de obicei foarte mult cod.

Ben Forta este seful echipei de evanghelisti ColdFusion. Articolele sale nu sunt foarte tehnice insa urmarind-u-le veti fi tot timpul la curent cu ultimele noutati legate de evolutia acestui limbaj. In plus, din cand in cand mai publica cate un mic tutorial video cu lucuri simple, dar utile care se pot face in ColdFusion.

Documentatia online. Aici gasiti documentatia completa pentru ColdFusion 9 si vreo doua versiuni in urma (pana la 7 cred). Numele Live Docs indica faptul ca este actualizat constant, asa ca veti fi tot timpul la zi.

Adobe Devnet (sectiunea ColdFusion) este locul in care gasiti tot timpul cele mai noi tutoriale legate de acest limbaj. Articolele variaza de la rezolvarea unor probleme aparent banale, pana la mici aplicatii explicate pas cu pas.

Retete ColdFusion (sau ColdFusion Cookbook). Un loc unde sunt adaugate constant bucati utile de cod. Cea mai buna parte este faptul ca nu numai puteti sa contribuiti cu o reteta, dar puteti sa cereti una. Adica, daca aveti o problema de ColdFuison pe care nu stiti sa o rezolvati o puteti posta acolo si aveti sansa sa primiti raspunsul in scurt timp.

Forumul ColdFusion. Mai bine zis, forumurile; Adobe pune la dispozitia comunitatii o serie de forumuri unde dezvoltatorii pot face schimb de idei si se pot ajuta unul pe altul.

Evident, si acolo veti gasi vesnicii internauti care te trimit pe Google cand ai o problema, dar pentru fiecare astfel de individ, se gaseste cineva cu o mana de ajutor.

Adobe Community Helper este o extensie pentru Google Chrome care ne permite sa cautam direct in resursele puse de dispozitie de Adobe. Acestea includ atat documentatia oficiala, cat si Cartea de Retete si blogurile evanghelistilor Adobe. Mie mi-a fost utila in repetate randuri.

Multumita lui Adrian, tocmai am aflat despre http://www.easycfm.com/. N-am apucat sa ma uit foarte atent pe acolo, dar pare sa aiba de toate. Merita incercat.

Acestea nu sunt toate resursele pe care le-am gasit de-a lungul timpului, insa sunt cele pe care le-am considerat mai importante. Daca e ceva ce mi-a scapat, va rog sa-mi atrageti atentia si voi actualiza articolul.

Read More

Bug in WordPress 3.1.1 pe Google Chrome. Oare?

Bug in WordPress 3.1.1 pe Google Chrome. Oare?

De cand am instalat versiunea 3.1.1 am constatat un comportament ciudat al editorului de text din WordPress. Mi-a luat ceva sa observ acest mic bug, probabil pentru ca nu scriu atat de des cat ar trebui.

Deci care e bug-ul? Eu folosesc Google Chrome 10 (10.0.648.205 pentru geeks) cam la tot ce tine de online. Asta inseamna, bineinteles, si scrisul pe blog. Ei, se pare ca in versiunea 3.1.1 nu mai merge butonul de adaugare link. Stiti care, cel pe care il apesi ca sa adaugi un link pe cuvantul selectat atunci cand esti in modul vizual.

La inceput credeam ca “s-a” stricat WordPress si deja ma impacam cu gandul ca va trebui sa adaug link-urile din cod (nu ca ar fi prea greu, da’ mi-e lene). In schimb, m-am gandit sa incerc si pe Firefox si acolo totul e ok. Concluzia? WordPress are mici probleme cu Google Chrome.

Eu nu sunt convins ca aceasta este o problema globala. S-ar putea sa fie numai la mine, desi nu cred, pentru ca am testat pe Chrome de pe mai multe calculatoare. Asa ca va intreb si pe voi. Aveti aceeasi problema cand incercati sa adaugati link-uri in articole pe Chrome?

Pana la noi lamuriri, astept cuminte WordPress 3.1.2 care sunt convins ca va rezolva acest bug.

Read More
content top
  • RSS
  • Twitter
  • Tumblr
  • Facebook