$_COOKIE

[MarcoMonteiro]

Bom dia,

estou a desenvolver uma loja on-line e já estou na parte final (também essa a parte que dá mais trabalho) - desenvolver o sistema de compra.

Ora bem, aqui vai o meu raciocínio:
A loja tem produtos que não têm um preço definido, mas sim cada produto tem definido um preço por metro quadrado e aquando da visualização do produto o utilizador pode inserir num formulário a altura e a largura do produto e o preço e calculado dinamicamente com javascript.

Posteriormente o utilizador carrega em comprar e eu pensei em guardar os valores num COOKIE da seguinte forma:

Código PHP:

setcookie("product[" . $idproduct . "]", $price); 


desta forma guardo um id e um preço para cada id, mas estou a ter alguns problemas, algumas das vezes o COOKIE não é guardado.


e mais, não sei se a utilização de COOKIES para algo do género é o mais indicado, mas apareceu-me ser o mais usado, tendo em conta que muitas vezes quando estou numa loja online, mesmo depois de sair quando volto os produtos ainda se encontram no meu carrinho.

se alguém aí com mais experiência me puder dar umas dicas em como criar o carrinho de compras agradecia :-)

cumprimentos

[Bruno Bernardino]

Boas,

Pessoalmente faria essa parte no início e não no fim do projecto, mas talvez seja uma questão de preferência pessoal.

Quanto ao facto de guardares os valores em Cookies, não recomendo de maneira nenhuma, pois estes são facilmente manipuláveis pelo utilizador.

Os cookies devem ser utilizados para guardar valores identificativos de sessão/utilizador, e/ou variáveis que não sejam relevantes a nível de informação, do tipo qual o background escolhido ou assim.

Idealmente deverias ter uma tabela com os "carrinhos de compras" identificados pelo utilizador e/ou sessão (valor encriptado no cookie, caso o utilizador não tenha login).

Depois esses valores deverão estar noutra tabela com os "itens do carrinho de compras", associados ao carrinho de que falei atrás.

Espero ter-me feito entender.

Relativamente à questão de calcular o valor por JS, fazes bem pois deve-se usar o máximo de JavaScript para evitar que seja o servidor a processar tudo, mas tens de fazer sempre um "double-check" no servidor, pois tens de supôr que a informação que vem do utilizador é manipulada pelo mesmo!

Abraço

[NeMewSys]

Bruno Bernardino, não concordo, por 2 motivos.

1 - "Relativamente à questão de calcular o valor por JS, fazes bem pois deve-se usar o máximo de JavaScript para evitar que seja o servidor a processar tudo"

Sim, faz sentido, mas não te esqueças que (apesar de parecer irrealista), ha bastante gente que usam browsers sem JavaScript, e ha mais ainda que tem anti-virus da tanga que bloqueiam JavaScript. (Sim, esta semana só, apanhei 3 casos desse genero).
E como o Zé da horta não percebe um boi do que é a internet e o bill gates e afilhados, vai culpar o teu site por não funcionar... Por isso, fia-te no servidor, que actualmente o overload já não é um problema para sites cujo trafego não seja abusivo (tipo google.com).

2 - "mas tens de fazer sempre um "double-check" no servidor, pois tens de supôr que a informação que vem do utilizador é manipulada pelo mesmo!"

Pera? Estás a dizer que temos de poupar trabalho ao servidor, e agora, apesar de teres usado o metodo que referiste no ponto 1, o servidor vai ter de fazer todo o trabalho outravez para confirmar que o cliente fez tudo certo?
Para não ter 1 trabalho vais arranjar 2?

[Bruno Bernardino]

NeMewSys,

O 2 aparece pelos casos que falaste contra no 1. A questão do 2 poderá significar 1 de 2 coisas (supuseste a 1ª da minha seguinte lista):

1. Este cálculo não será sempre realizado mas sim se algum valor de referência não coincidir com o esperado.

Por exemplo: Se o utilizador tiver JavaScript activo, digamos que irás alterar um qualquer valor de hash que o teu script reconhecerá como o utilizador tendo JavaScript activo, o que não irá acontecer se esta hash não coincidir com o esperado, logo, nessa situação será efectuado o cálculo no servidor, já que o utilizador não tem ou não quer ter activo o JavaScript.

2. Neste caso falo em double-check apenas para verificar se a informação foi correctamente submetida e não para recalcular, ou seja, permitindo apenas o submit do formulário por JavaScript (existem várias maneiras de garantir isto), e, se não fio submetido por JavaScript, rejeitar o processo.

Nestes casos nunca repito o processo 2 vezes, e mesmo que repetisse, num qualquer outro caso, seria uma vez no cliente e uma vez no servidor, garantia mais segurança sem perder performance.

[NeMewSys]

(23-02-2010 10:02)Bruno Bernardino Escreveu:  NeMewSys,

O 2 aparece pelos casos que falaste contra no 1. A questão do 2 poderá significar 1 de 2 coisas (supuseste a 1ª da minha seguinte lista):

1. Este cálculo não será sempre realizado mas sim se algum valor de referência não coincidir com o esperado.

Por exemplo: Se o utilizador tiver JavaScript activo, digamos que irás alterar um qualquer valor de hash que o teu script reconhecerá como o utilizador tendo JavaScript activo, o que não irá acontecer se esta hash não coincidir com o esperado, logo, nessa situação será efectuado o cálculo no servidor, já que o utilizador não tem ou não quer ter activo o JavaScript.

2. Neste caso falo em double-check apenas para verificar se a informação foi correctamente submetida e não para recalcular, ou seja, permitindo apenas o submit do formulário por JavaScript (existem várias maneiras de garantir isto), e, se não fio submetido por JavaScript, rejeitar o processo.

Nestes casos nunca repito o processo 2 vezes, e mesmo que repetisse, num qualquer outro caso, seria uma vez no cliente e uma vez no servidor, garantia mais segurança sem perder performance.

Então dessa forma basta o utilizador submeter bem um valor qualquer que o servidor aceita, independentemente deste estar alterado ou não? Continuo a achar seguro fazer tudo server-side, pois mesmo que tentes comparar o submit com o valor esperado, ele valor esperado tem de vir de qualquer lado.
Mas se a presença ou não do JS nos browsers, e a falta de protecção dos dados submetidos contra fraude não for um problema, sim, é super preferível tratar dessas operações em client-side para não sobrecarregar o servidor claro.

[ruicosta]

Desculpem intrometer-me em conversas de adultos, mas na minha humilde opinião, tudo deve ser feito em server-side. Porque?

Porque no servidor tudo irá funcionar e não estamos dependentes de funcionalidades ou gostos do utilizador.

Em termos de js, poderá existir uma camada por cima da camada do server, apenas e somente apenas for confirmado e segurado haver essa possibilidade do lado do cliente. Desde cálculos, efeitos, "ajax", etc

Cumprimentos,
Rui Costa

[RaCcOn]

Mas que grande confusão que aqui anda
Bruno, todos os dados poderão ser manipulados pelo utilizador, a solução que tens para não utilizares cookies é teres um campo na base de dados com o ID de utilizador e os produtos que estão no carrinho.
Seja de que maneira for vais estar a criar campos desnecessários de qualquer das formas, logo o melhor é a utilização de cookies.
Se podem ser alterados pelo user?Claro que podem, mas com que interesse?Adicionar mais produtos ao carrinho temporário?lol

[Bruno Bernardino]

RaCcOn, mas eu nunca disse o contrário. Pode ser alterado, a questão é que não se podem (ou essa possibilidade tem uma probabilidade perto do impossível) "passar" por outras pessoas ou obter/enviar dados "enganosos".

[ruicosta]

(24-02-2010 13:47)Bruno Bernardino Escreveu:  RaCcOn, mas eu nunca disse o contrário. Pode ser alterado, a questão é que não se podem (ou essa possibilidade tem uma probabilidade perto do impossível) "passar" por outras pessoas ou obter/enviar dados "enganosos".

Ou será que não poderão ter os cookies desligados?