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

Conditii in ColdFusion – tag-urile cfif/cfelse

Conditii in ColdFusion – tag-urile cfif/cfelse

In acest articol vom trata un subiect aparent banal printre programatori. Si cand spun banal, nu inseamna ca este mai putin important. Numai ca fiind folosit atat de des, acest element sa trivializeaza si-l luam ca pe un dat.

Este vorba despre banalele expresii conditionale. Am ales sa dedic un articol acestui element dintr-un motiv foarte simplu. Asa cum va spuneam si intr-un articol anterior, ColdFusion abordeaza putin diferit unele lucruri.

Expresiile if/else sunt un exemplu bun al acestui lucru.

Ca sa intelegem mai bine, sa vedem cateva bucati de cod. In PHP (ca in majoritatea limbajelor de altfel), un bloc if/else ar arata asa:

<?php
if($condition === true)
{
	// executa cod
}
else
{
	// executa cod
}
?>

Dar sa nu ne cramponam de limbaj. Hai sa vedem un bloc de cod generalizat, ca sa-l comparam dupa aceea cu ColdFusion.

if(expresie_de_evaluat)
{
	executa cod
}
else
{
	executa cod
}

Bun, din cele doua blocuri de cod, se vede destul de clar cum arata expresia if/else. Haideti sa portam acest cod in ColdFusion sa vedem cu ar arata. Studiind blocul de mai sus, am fi tentati sa scriem ceva de genul acesta:

<cfif expresie_de_evaluat>
	<!--- executa cod --->
</cfif>
<cfelse>
	<!--- executa cod --->
</cfelse>

Deci, ce nu e bine aici? Avem un bloc if, iar cand acesta se finalizeaza incepe blocul else. Ei bine, ColdFusion vede blocul if/else in felul urmator:

<cfif expresie_de_evaluat>
	<!--- executa cod --->

	<cfelse>
		<!--- executa cod --->
</cfif>

Dupa cum vedeti, <cfif> este singurul care se inchide. Totul se intampla in interiorul acestui tag, ramanand ca <cfelse> sa fie inclus tot aici. Obeservati de asemenea, ca <cfelse> nu se inchide. El tine automat din locul in care este deschis, pana acolo unde se termina <cfif>.

Si pentru cei dintre voi care sunteti fani ai lui elseif, tin sa va spun ca si ColdFusion ofera asa ceva. Se numeste <cfelseif> si se foloseste asa:

<cfif expresie_de_evaluat>
	<!--- executa cod --->

	<cfelseif expresie2_de_evaluat>
		<!--- executa cod --->

	<cfelse>
		<!--- executa cod --->
</cfif>

Dupa cum vedeti, conditiile nu sunt nici pe departe mai grele in ColdFusion. Sunt doar putin diferite fata de cele cu care ne-am obisnuit. Happy Coding.

Read More

Rute in CodeIgniter

Rute in CodeIgniter

In acest articol vom trata un feature foarte util in CodeIgniter, care din pacate este trecut cu vederea de o parte din dezvoltatori.

Este vorba despre asa numitele rute. Cu ajutorul lor putem sa definim niste handlere care sa reactioneze atunci cand un anumit parametru este trimis in browser.

Unul din cele mai intalnite lucruri la care sunt folosite rutele, este crearea de “URL-uri prietenoase”. Cu alte cuvinte, in loc de http://www.magazin.ro/produs/detaliu/23 o sa avem http://www.magazin.ro/detaliu-produs/telefon-mobil-android.

Sa vedem asadar, cum folosim rutele ca sa obtinem acest efect. Rutele sunt definite in mod previzibil in application/config/routes.php. In mod implicit, acest fisier contine o singura linie de cod (restul sunt comentarii):

	$route['default_controller'] = "welcome";

Ruta pe care o vom adauga noi pentru transformarea URL-ului, arata asa:

	$route['detaliu-produs/:any']='produs/detaliu';

Si acum sa explicam putin ce se intampla, ca sa putem trece mai departe. Sa luam mai intai primul URL si sa-l explicam, pentru cei care sunt mai noi in domeniul CodeIgniter. URL-ul: http://www.magazin.ro/produs/detaliu/23 apeleaza functia detaliu() cu ID-ul 23 din Controller-ul produs.php.

Deci cum ne ajuta noua ruta in functionarea URL-ului nr. 2? Dupa cum observati, de cate ori in URL este scris detaliu-produs urmat de orice altceva, CodeIgniter apeleaza functia detaliu() din Controller-ul produs.php.

Dar nu mai avem ID-ul. Cum identificam produsul dorit? Simplu, presupunand ca informatia este adusa din baza de date, in primul caz o sa avem un query de genul:

	$sql = "SELECT * FROM produs WHERE ID = " . $this->uri->segment(3);

Pentru mai multe detalii despre segmente, vezi articolul despre clasa URI in CodeIgniter.

Dar daca tabela produs, ar avea si un camp numit slug? Am putea ca la inregistrarea cu ID-ul 23 sa avem un slug “telefon-mobil-android”. Astfel, noul query va arata asa:

	$sql = "SELECT * FROM produs WHERE slug = " . $this->uri->segment(3);

Atentie! Va trebui sa va asigurati  ca slug-ul este unic la fiecare inregistrare in parte.

Dupa cum vedeti, rutele sunt o unealta importanta un arsenalul pus la dispozitie de CodeIgniter. Folosite in mod corect, deschid un nou set de posibilitati in dezvoltarea de aplicatii dinamice.

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
content top
  • RSS
  • Twitter
  • Tumblr
  • Facebook