Jump to content

Passagem de parâmetros para a mesma página


deathseeker25
 Share

Recommended Posts

deathseeker25

Boas,

O título do tópico não está totalmente especificado, no entanto não sei que outro nome dar a este processo que estou a tentar executar.

Acontece que estou a desenvolver um painel de administração e pretendia que o código ficasse todo apenas numa página. Como sou um novato em php, só conseguiria fazer este painel de administração recorrendo a várias páginas.

Por exemplo, para fazer a função de editar um registo, teria de recorrer a três páginas: uma para mostrar os registos e selecionar o registo que se pretende editar, outra para mostrar o formulário com os dados do registo passíveis de serem editados e outro para finalmente actualizar a base de dados com o novo registo. Considero isto uma má prática, visto que envolve muitos ficheiros, o que dificulta a outros programadores a leitura e compreensão do código, portanto é preferível colocar tudo num ficheiro.

Tentei atingir o objectivo recorrendo a programação funcional (utilizando functions para determinadas tarefas). Já me deram uma ajuda num problema anterior, no qual recorri a uma função para inserir registos na BD através de um formulário, sendo que todo o código ficou colocado na mesma página.

Agora, o que pretendo realmente é editar um registo. Como já referi, poderia fazê-lo recorrendo a três ficheiros de código diferentes, passando parâmetros por url através da utilização do $_REQUEST. Mas pretendo continuar a utilizar programação recursiva e colocar o código todo no mesmo ficheiro, como já repeti.

Vou-vos mostrar o que já desenvolvi, para que percebam o que quero fazer:

function editcode()
{

$ligacao=mysql_connect("$localhost","$utilizador","$password") or die("Impossível ligar ao servidor: ".mysql_error());

$sql="SELECT *FROM codigo";

$resultado=mysql_query($sql,$ligacao);

if($resultado){

	print("<table width=\"90%\" align=center border=0>");
	print("<tr><td width=\"40%\" align=center>Id</td>
			   <td width=\"40%\">Título</td>
			   <td width=\"40%\">Utilizador</td>
			   <td width=\"40%\">Linguagem</td>
			   <td width=\"40%\">Data</td>
			   <td width=\"40%\">Hora</td>");

	while($registo=mysql_fetch_array($resultado)){

		$id=          $registo["id"];
		$codename=    $registo["codename"];
		$utilizador=  $registo["utilizador"];
		$linguagem=   $registo["linguagem"];
		$data=        $registo["data"];
		$hora=        $registo["hora"];

	print("<tr><td align=center><a href=\"editcode.php?id=$id&codename=$codename&utilizador=$utilizador&linguagem=$linguagem&data=$data&hora=$hora\">$id</a></td><td>$codename</td><td>$utilizador</td><td>$linguagem</td><td>$data</td><td>$hora</td>");
	}

	echo "</table>";
	}
	else{

	echo "Não há registos!";
	}

	mysql_close();


?>

Esta é a função que supostamente irá servir para visualizar os registos e escolher um para editar, no caso de querer disponibilizar o código em páginas diferentes. Depois teria de passar os parâmetros desta forma:

<form method="post" action="ficheiro_de_visualizaçao_ dos_registos.php">
Nº de id - <?php echo $_REQUEST['id'];?><br>
<table border=0 width=60%>
<tr><td width=30%>Título - </td>
       <td><input type="text" name="codename" value="<?php echo $_REQUEST['codename'];?>"
</td></tr>
<tr><td width=30%>Utilizador - </td><td><input type="text" name="utilizador" value="<?php echo $_REQUEST['utilizador'];?>>
</td></tr>

etc....
etc...
etc...

E por aí fora para cada um dos campos.

Acontece que pretendo fazer isto no mesmo ficheiro, isto é, passando os dados de outro modo que não por url e indo buscá-los por outro modo que não o $_REQUEST.

Como posso fazê-lo? De acordo com a vossa experiência, de que modo será mais viável fazê-lo? ;)

Link to comment
Share on other sites

Porque não passas uma variável action no url que diz o que queres fazer?

Ou se não queres passar os dados pelo url porque não fazer um form só com inputs do tipo hidden e passá-los por post? Com um bocadinho de javascript à mistura...

Desaparecido.

Link to comment
Share on other sites

deathseeker25

Não existe nenhum problema em passar os dados pela url.

Eu sei que não. Mas, para o fazer, teria obrigatoriamente de ter mais de um ficheiro de código-fonte. O que eu quero é situar o código todo no mesmo ficheiro, sendo que a passagem de parâmetros teria de decorrer na mesma página.

Porque não passas uma variável action no url que diz o que queres fazer?

Ou se não queres passar os dados pelo url porque não fazer um form só com inputs do tipo hidden e passá-los por post? Com um bocadinho de javascript à mistura...

Podes exemplificar para que se compreenda melhor. Como é que vou buscar os dados de inputs hidden através do $_POST, sem passar os dados por algum lado? ;)

Link to comment
Share on other sites

Não existe nenhum problema em passar os dados pela url.

Isso não é verdade.

Existe um limite máximo, de 4K creio eu (se estiver errado neste valor, por favor corrijam-me).

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

Creio que a solução para o teu problema está no uso de sessões.

Se não queres passar os valores por URL, podes guardá-los numa sessão.

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

A maioria dos script passam dados pela url, não vai ser o script pequeno que ele está a criar que vai passar o limite de 4k que tu dizes.

Guardar em sessões os dados de um input não é uma boa alternativa para o que ele quer fazer e não é seguro colocar dados em sessões ou cookies.

A melhor alternativa para o que ele quer é passar pela url ou por hidden como disse o TheDark

Link to comment
Share on other sites

deathseeker25

Creio que a solução para o teu problema está no uso de sessões.

Se não queres passar os valores por URL, podes guardá-los numa sessão.

Parece então que vou ter de aprender a trabalhar com sessões, para este caso. Já o teria de fazer para coisas que vou fazer a seguir neste mesmo script, pelo que me adianto já com o painel de administrador. ;)

Guardar em sessões os dados de um input não é uma boa alternativa para o que ele quer fazer e não é seguro colocar dados em sessões ou cookies.

Não é seguro como?! É mais seguro passar dados pelo url do que guardá-los em sessões? Porque razão?

A melhor alternativa para o que ele quer é passar pela url ou por hidden como disse o TheDark

A questão da passagem por hidden intrigou-me bastante, mas nunca fiz tal coisa pelo que gostava sinceramente de ver um exemplo do método. :P

Link to comment
Share on other sites

A maioria dos script passam dados pela url, não vai ser o script pequeno que ele está a criar que vai passar o limite de 4k que tu dizes.

Não disse que neste caso particular não fosse uma boa solução, apenas referi que, ao contrário do que afirmavas, existe um problema/limitação técnica com a passagem de dados por URL.

Guardar em sessões os dados de um input não é uma boa alternativa para o que ele quer fazer e não é seguro colocar dados em sessões ou cookies.

Explica-me lá porque é que para o que o deathseeker25 quer fazer as sessões não são uma boa alterantiva.

Quanto à segurança, usar cookies ou sessões é mais seguro do que passar os dados no URL onde toda a gente os vê.

Mais, ainda nas sessões não tens de usar a sessão do browser, podes usar outras técnicas/implementações de sessões.

A melhor alternativa para o que ele quer é passar pela url ou por hidden como disse o TheDark

É uma boa alterantiva, se é a melhor, depende das necessidades do deathseeker25.

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

[...]

A questão da passagem por hidden intrigou-me bastante, mas nunca fiz tal coisa pelo que gostava sinceramente de ver um exemplo do método. ;)

Não tem nada de mais, é como um campo de texto normal <input type="text" value="valor"...> mas que está escondido para o utilizador <input type="hidden" value="valor"...>.

De resto é igual a qualquer outro campo.

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

Ele não quer usar na url porque ele acha que é menos seguro.  O metodo que ele está a usar na form é  "POST" por isso os dados não vão para a url e não é a mesma coisa... pela url o metodo "GET".

Link to comment
Share on other sites

A questão da passagem por hidden intrigou-me bastante, mas nunca fiz tal coisa pelo que gostava sinceramente de ver um exemplo do método. ;)

a form é normal só muda o type no input exemplo:

<input type="hidden" name="exemplo" value=""> 

Em relação as sessões pensei que já soubesses que as sessões podem ser atacas pela url se não forem bem utilizadas, mas se quiseres utilizar podes uiliizar só dei a minha opinião.

Link to comment
Share on other sites

Ele não quer usar na url porque ele acha que é menos seguro.

Se a questão é segurança, então o melhor será usar SSL.

O metodo que ele está a usar na form é  "POST" por isso os dados não vão para a url e não é a mesma coisa... pela url o metodo "GET".

Não consegui perceber o que querias dizer, em especial na última frase que não me parece fazer qualquer sentido...

O POST e o GET funcionam de forma distinta, isso é um facto, mas as suas diferenças vão bem mais além do simples facto dos parametros fazerem, ou não, parte do URL.

Além disso, parece que a solução vai acabar por passar pelo uso de sessões por outras razões que não este ponto em particula que aqui estamos a discutir...

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

Não consegui perceber o que querias dizer, em especial na última frase que não me parece fazer qualquer sentido...

O POST e o GET funcionam de forma distinta, isso é um facto, mas as suas diferenças vão bem mais além do simples facto dos parametros fazerem, ou não, parte do URL.

Não vamos andar aqui a dizer todas as diferenças lol por isso só falei da url.

Além disso, parece que a solução vai acabar por passar pelo uso de sessões por outras razões que não este ponto em particula que aqui estamos a discutir...

Acho qeu também vai acabar em sessões... Mas eu preferia passar os dados pela url.

Link to comment
Share on other sites

Não consegui perceber o que querias dizer, em especial na última frase que não me parece fazer qualquer sentido...

O POST e o GET funcionam de forma distinta, isso é um facto, mas as suas diferenças vão bem mais além do simples facto dos parametros fazerem, ou não, parte do URL.

Não vamos andar aqui a dizer todas as diferenças lol por isso só falei da url.

Além disso, parece que a solução vai acabar por passar pelo uso de sessões por outras razões que não este ponto em particula que aqui estamos a discutir...

Acho qeu também vai acabar em sessões... Mas eu preferia passar os dados pela url.

Tipicamente opta-se por POST ou GET, mas nem sempre é a melhor solução.

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

Considero isto uma má prática, visto que envolve muitos ficheiros, o que dificulta a outros programadores a leitura e compreensão do código, portanto é preferível colocar tudo num ficheiro.

Isto é completamente errado!!!

Existem mesmo muitos utilitários que após um projecto acabado, imaginemos um programa em C, com 60 000 de code

permitem facilmente dividir por vários ficheiros para melhor percepção do que faz, depois é só escrever um pequeno relatorio a descrever o objectivo de cada ficheiro para se no futuro se pegar de novo no projecto.

Além de dividir em vários ficheiros também dividir o código em várias funções isto é de forma modular.

passando parâmetros por url através da utilização do $_REQUEST

usa o $_GET ao invés do $_REQUEST

o $_REQUEST é uma estupidez de todo o tamanho existir, visto que é um array com os dados de $_GET, $_POST e $_COOKIE

Link to comment
Share on other sites

o $_REQUEST é uma estupidez de todo o tamanho existir, visto que é um array com os dados de $_GET, $_POST e $_COOKIE

Não entendi essa parte do  $_REQUEST ser um array com os dados de $_GET, $_POST e $_COOKIE.

Podes explicar melhor ? ;)

Link to comment
Share on other sites

o $_REQUEST permite aceder tanto a valores do $_GET, $_POST ou $_COOKIE

basicamente é uma grande açorda!

é uma estupidez usar e penso que foi mesmo descontinuado apartir de uma certa altura em algumas versões de PHP

existe um POST sobre o assunto no forum

http://www.portugal-a-programar.pt/index.php?showtopic=2911

basicamente se não tens a certeza se um dado valor é dado por preenchimento de uma form ou através da URL, basta usares o isset para verificar qual deves usar.

usar o $_REQUEST é muito mau também para a legibilidade do código fonte, pois a primeira vista não consegues perceber de "onde vêm as coisas".

Link to comment
Share on other sites

deathseeker25

Considero isto uma má prática, visto que envolve muitos ficheiros, o que dificulta a outros programadores a leitura e compreensão do código, portanto é preferível colocar tudo num ficheiro.

Isto é completamente errado!!!

Existem mesmo muitos utilitários que após um projecto acabado, imaginemos um programa em C, com 60 000 de code

permitem facilmente dividir por vários ficheiros para melhor percepção do que faz, depois é só escrever um pequeno relatorio a descrever o objectivo de cada ficheiro para se no futuro se pegar de novo no projecto.

Além de dividir em vários ficheiros também dividir o código em várias funções isto é de forma modular.

passando parâmetros por url através da utilização do $_REQUEST

usa o $_GET ao invés do $_REQUEST

o $_REQUEST é uma estupidez de todo o tamanho existir, visto que é um array com os dados de $_GET, $_POST e $_COOKIE

Portanto,  recomendas mesmo o uso de vários ficheiros para uma acção qualquer..

Sempre achei que muitos ficheiros só fariam com que o utilizador tivesse mais dificuldade em ler e compreender o código... :P

Link to comment
Share on other sites

Só para esclarecer em relação ao hidden...

A ideia é criar algo deste genero:

<input name="accao1" type="button" value="acção:editar, nome:manel, apelido:papagaio" onclick="send('editar', 'manel', 'papagaio');">
<input name="accao2" type="button" value="acção:apagar, nome:josefino, apelido:rococó" onclick="send('apagar', 'josefino', 'rococó');">
<input name="accao3" type="button" value="acção:inventar, nome:martelo, apelido:farinha amparo" onclick="send('inventar', 'martelo', 'farinha amparo');">

<form enctype="text/plain" action="file.php" id="form1" method="post">
<input type="hidden" name="accao" value="">
<input type="hidden" name="nome" value="">
<input type="hidden" name="apelido" value="">
</form>

e um script deste:

<script type="text/javascript">

function send(accao, nome, apelido) {
form1=document.getElementById("form1");

form1.accao.value=accao;
form1.nome.value=nome;
form1.apelido.value=apelido;

form1.submit();

}

</script>

Não testei... mas isso deve funcionar... ou se não funcionar vai lá com algumas pequenas alterações... acho eu... 8-)

EDIT Acabei de testar e parece que acertei à 1ª :P

Desaparecido.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.