Edenfall

é por isso que eu gosto desse fórum hehehe aparece cada pergunta e meia-pergunta... hahaha vai veno

o grande problema dos arquivos é que dependendo do tráfego do site, alguns usuários terão que ficar 'na fila' esperando a liberação do arquivo. o banco de dados é muito mais recomendados até para essas pequenas coisas. cada um tem o seu jeito... se vc for criar um sistema de contador de visitas, que abre uma única vez por sessão, é até bom usar um arquivo...

você vai colocar as TABELAS em um único BANCO DE DADOS, certo? supondo que eu tenha o seguinte protótipo: BANCO DE DADOS 'comments' com uma TABELA 'comments' dentro dele BANCO DE DADOS 'estatisticas' com uma TABELA 'estatisticas' dentro dele BANCO DE DADOS 'maladireta' com uma TABELA 'maladireta' e outra TABELA 'emails' dentro dele ficaria fácil de organizasse assim: BANCO DE DADOS 'portal' TABELA 'comments' TABELA 'estatisticas' TABELA 'maladireta_mala' TABELA 'maladireta_emails' ou mais ou menos isso. fica confuso por causa da quantidade de tabelas dentro de um único banco de dados, mas na prática você precisa fazer apenas uma conexão em vez de ficar abrindo e fechando conexões em diferentes bancos. é mais prático, mas você precisa prestar atenção nos nomes das tabelas pra poder lembrar depois pra que cada uma serve. qqer coisa, estamos ae

pode, mas ele fica meio confuso, a não ser que você coloque nomes bem fáceis de identificar em cada tabela que for usar.

o $_GET['nomedavariavel'] é padrão no PHP, e você pode usar também $HTTP_GET_VARS['nomedavariavel'] que dá na mesma, mas para 'economizar digitação', use o GET mesmo. você pode usar o $_REQUEST['nomedavariavel'] mas deve tomar cuidado pois este aceita os dados enviados pelo GET (url) e pelo POST (geralmente usado em formulários). você pode fazer também como o aspanhol disse, mas no seu arquivo 'php.ini' a diretiva register_globals deve estar setada para 'on' o $_GET nunca dá problema. geralmente os problemas ocorrem entre a cadeira e o monitor, como dizem (aqui acontece sempre)

ele sempre fica aberto mesmo. pra sair, você precisa apertar ctrl+c que ele conclui a tarefa (servir as páginas) e desliga. quanto ao mysql, o meu não fica nenhuma janela aberta, ele funciona em puro DOS mesmo. também, eu instalei os negócios manualmente aqui, seguindo um livro...

olha, não sei se é isso, mas quando tive um problema parecido, foi por causa da configuração do php.ini, mas não me lembro qual. um problema que tive foi com a pasta temporária onde eram guardados os arquivos de sessão (no servidor). então eu procurei no php.ini a linha: basta você verificar para qual diretório ele está redirecionando os arquivos de sessão do servidor e ver se ele existe (no meu caso, 'c:/temp/'). se ele não existir, tente criá-lo. mas acho que talvez esse não seja o seu problema, de qualquer forma, isso que eu postei pode te ajudar de alguma forma PS.:que livro você está usando?

então. o $HTTP_POST_VARS é mais antigo e dizem que pode não estar mais disponível em alguma futura atualização do PHP. Acho impossível que isso aconteça, mas não é uma hipótese a descartar. o $_POST['var'] é o estilo mais curto e ótimo para ser utilizado no caso. melhor do que atribuir um valor do $_POST['var'] a uma variável, é utilizar o próprio no código. estou fazendo isso e não tive problema algum até agora. e até agora não tive problemas quanto a trabalhar com o register_globals desativado.

http://www.firepages.com.au/dev4.htm se tiver alguma atualização, baixa também. eu to usando o xp professional (devidamente pirateado hehehe) e tá funcionando certinho. no ME eu prefiro instalar os pacotes separados. da uma olhada no menu iniciar se não tem nenhum atalho do tipo 'phpdev_2k_xp_nt'

então, eu não curto muito esse recurso e prefiro trabalhar com ele desligado. claro que ele tem, lá as suas utilidades, mas suponhamos que eu esteja trabalhando com sessões, dados de formulário e usando o (útil) php?dir: na url temos: beleza! eu tenho register_globals ativado e só preciso chamar o $area e o $contador diretamente pelo nome, sem precisar de frescuras como $area=$_GET['area'];. sem pensar, eu crio um formulário que trate de outro assunto, onde exista um input com o nome 'contador'. pronto! tá feita a merreba! pior ainda se eu trabalho num script que trabalhe com sessões e preciso definir uma variável de sessão chamada 'contador' com o valor 'true'. se o register_globals estiver ativado, essas variáveis vão se misturar e formar uma bagunça enorme que vai me custar pelo menos uns bons quartos de hora quebrando a cabeça pra descobrir o que está de errado. com ele desativado, posso trabalhar com essas mesmas variáveis, utilizando o seguinte: claro que se eu tomar bastante cuidado, posso evitar que esse tipo de coisa aconteça, mas num projeto grande, é quase impossível evitar esse tipo de erro. fica mais fácil desativar (ou simplesmente não usar, se você não tiver acesso ao php.ini) e gastar uns segundos a mais para usar as variáveis predefinidas no PHP. afinal, se fosse bom, não viria desativada no PHP existem alguns quesitos de segurança também, mas não me aprofundei nesse assunto ainda. a questão é: quais as vantagens de se ativar e de se desativar o register_globals?

seria algo como templates? você cria uma página separada só pra ser o menu, e quando mudar essa página, todas as outras mudam, certo? tem vários tipos, mas com HTML não é uma boa idéia. uma boa opção é usar SSI, mas não conheço muito desse recurso, nem sei se ele é habilitado nos provedores gratuitos.

obs: também usei o termo hacker no sentido real. mais uma coisa, me lembrei que script kiddies são os conhecidos defacers, ou seja, aqueles carinhas que se acham o máximo desfigurando o site dos outros. me recuso a ter tal atitude e prefiro ser chamado de lammer. com essa afirmação, nós acabamos voltando ao tópico em questão. quando precisamos, por exemplo, construir uma tabela complicada (mantendo o assunto dentro do fórum HTML), procuramos primeiro saber se isso já não foi feito por outros sites para olharmos como eles fizeram (código-fonte) e adaptar o código às nossas necessidades. isso é melhor do que 'reinventar a roda' e criar sozinho um código parecido com outros tantos que existem por aí. se bem que o caminho mais difícil é o que ensina mais e, portanto, é o melhor a seguir. pessaolmente, sou a favor de criar todo o código na unha, sem copiar, mas quando tenho pressa e quero aplicar algum efeito que vi em outro site, dou uma 'olhadinha básica' e procuro entender o que o cara fez, e não simplesmente copiar-e-colar. foi assim que aprendi a usar muita coisa que eu sei (CSS, por exemplo). tomando o caminho difícil, pegando uns atalhos de vez em quando e assim eu vou aprendendo

eu tenho esse aqui: http://www.submarino.com.br/books_productd...Id=196124&ST=SE mas a bíblia do PHP e a bíblia do MySQL devem ser os melhores, apesar de serem um pouco mais caros. se você tem noção de programação, não vai ter muitas dificuldades. parabéns pela escolha

tomando como exemplo: no dreamweaver funciona porque ele é um servidor, o que significa que links relativos à raiz do site funcionam. simplificando, na tag '<param name="movie" value="/XPINFO.swf">', basta tirar a barra ('/') antes do nome do arquivo. faça o mesmo na tag '<embed>'. depois repita a operação nos outros links. deverá funcionar diritinho. se você deixar essas barras, ele tentará procurar os flashes a partir da raiz do disco ('c:\'). faça isso e veja se resolve. seu dreamweaver deve estar com alguma configuração modificada. []'s

dá pra postar o código da página aqui?

você fechou a tag de todas as tabelas? já tive problemas de estrutura antes e o motivo foi esse. dê uma boa olhada no código e veja se elas estão fechadas.

quando eu disse que sou um scriptkiddie, quis dizer que o sou em termos de conhecimento, pois não me interesso por hacking além do que eu leio (e nem ponho em prática, com exceção do urlfil). na verdade, sou mais lammer do que scriptkiddie. em outras palavras: eu quis dizer isso com a outra frase, ok? []'s

se não conseguir nenhum aqui, tenta o fórum de javascript.

thuran, isso é o certo mesmo a se fazer. é como disse: eu aprendo fuçando o código do pessoal, coloco os direitos deles e boa. um dia quando um carinha entrar no meu site e ver ali o comentário, talvez a consciência pese e ele faça o mesmo... vamos torcer né... isso foi referente à frase que eu coloquei no final, não? eu sou mais um scriptkidie mesmo... não sei muita coisa sobre técnicas hackers, mas tenho alguns textos de hackers brasileiros e num dos comentários dos caras vi essa frase e achei que funcionaria muito bem aqui nesse contexto. ou seja, fuçamos as páginas para aprender, não o contrário.

oi, amigos... então, jissa, também concordo com você, em tudo o que disse. quando você cria alguma coisa, quer protegê-la de tudo. aí sim tem sentido pelo menos criptografar o código fonte. peça por ele o preço que você quiser, pois um cliente que precisa dele certamente vai comprar, ou tentar procurar outro scripter pra tentar fazer uma coisa igual. o que não vai ser fácil, pois você ainda não publicou o seu código, então ele não vai ter como saer como você o fez. mas a partir do momento que você publicar, ele passa a ser de domínio público, ressalto que por mais bem armado que seja o esquema de proteção, algum espertinho sempre chega e copia. mas aí você já vai ter ganhado o seu serviço. aqueles 2 meses trabalhando naquele script vão valer a pena, porque o seu cliente já terá pago o serviço. gladiador, sendo ou não sendo opensource, como o nosso amigo jissa falou, você precisa receber pelo que você faz, senão não teria sentido aprender toda aquela montanha de códigos e não ter nenhum retorno. claro que você não pode vender o PHP, assim como o MySQL. se eu faço um site para um cliente, eu vou cobrar o meu serviço, o trabalho que eu tive para fazer tudo aquilo. mas eu passo o código para ele e falo que se ele quiser pode alterar, desde que conheça a linguagem o cara não vai pagar uma fortuna e sair distribuindo o código, mesmo porque aquele código foi feito especificamente para ele... agora concordo que se eu crio alguma coisa que talvez tenha alguma utilidade geral, com certeza eu compartilho o código, não teria problema algum. se você quiser, a gente monta até uma equipe para criar um sistema de portal ou fórum opensource totalmente brasileiro. não teria problema algum para mim. mas uma coisa é uma coisa, outra é outra. se eu desenvolvo PHP para um cliente, ele tem que pagar o serviço e o suporte, não o código. concluindo, existem coisas que devem e coisas que não precisam ser protegidas. isso o seu ego vai dizer. quando tiver alguma coisa para compartilhar, entro aqui e no phpbrasil.com e posto o código para quem quiser ver. o que estraga, realmente, são os manézinhos da vida que fuçam tudo, copiam, e dizem que é deles... alguns deles até passam por esses fórums, mas nenhum desenvolve a capacidade de criar alguma coisa sozinho. deixemos que a consciência deles acuse, porque um dia eles é que estarão participando, talvez até contribuindo com este fórum com suas próprias criacões. outra coisa, quem aqui que nunca exibiu um código-fonte na vida, para saber como funciona tal código? eu sempre exibo, porque não sei nada de javascript além do básico. mas não uso só o 'copiar', uso o 'aprender' também. afinal, foi assim que aprendi html, olhando o trabalho dos outros, copiando e depois criando os meus próprios códigos. hack to learn, not learn to hack

então... por isso mesmo. a html não é a linguagem que você deve se aperfeiçoar, justamente porque ela é simples e qualquer "pestinha" sabe... a html é uma base que todos devem ter para pular para outra linguagem mais avançada... chega uma hora que você não se contenta mais em ficar desenvolvendo sites 'estáticos' e quer alguma coisa nova, e que funcione de forma mais esperada. ou seja, algo que realmente interaja com o visitante... claro que tem coisinhas no html que valem a pena serem ocultas, mas lembre-se que cedo ou tarde vem alguém e copia. isso é inevitável. o que eu quis dizer com isso é que a html não deve ser levada muito a sério. é bom saber o máximo possível, claro. assim como css e javascript, que é o tema discutido aqui. por exemplo, visite sites 'de nome', como UOL, Terra, BOL, Banco do Brasil, Banespa etc... até mesmo o site da ScriptBrasil tem o código liberado para quem quiser ler. perceba nisso que eles não estão preocupados com proteção de código. desculpe, não foi nada pessoal. sobre o PHP, foi só um exemplo. se você ler mais atentamente o meu post vai perceber que eu não saí do assunto 'html' []'s

cara, eu não entendo. pra quê proteger o código html? o importante mesmo (as linguagens dinâmicas como PHP) não chega no cliente simplesmente porque é executado no servidor como um programa (É um programa) e envia a saída (html) para o cliente... eu nunca me importei muito com isso. quem monta esses esquemas de proteção sempre se esquecem de alguma coisa. no mozilla, por exemplo, a página da infinite não abriu, talvez por causa do carregamento de scripts. quando eu escrevo algum site, penso primeiro em como ele vai rodar na máquina do cliente, já que aquele site entupido de javascripts vai rodar perfeitamente apenas em máquinas mais rápidas. é a mesma coisa que você dizer ao seu visitante: 'olha, pra visitar este site, você tem que fazer um upgrade total no seu pc'... sou a favor de usar javascripts para tarefas simples, como o (útil) window.history.go(-1) no link 'voltar' mas construções complicadas só devem ser usadas mesmo quando são realmente necessárias. mesmo porque qualquer script que rode no cliente com o intuito de ocultar ou proteger o código-fonte, não funciona realmente, apenas atrasa a exibição do próprio... (olha, eu não estou dando bronca em ninguém, apenas falei o que penso)

com css dá esse cod centraliza na horizontal (primeiro 'center') e vertical (segundo 'center') alinhamento horizontal: left, center e right alinhamento vertical: top, center e bottom dá pra fazer alinhamento por quantidade de pixels da borda também, mas em alguns navegadores não funciona muito bem espero ter ajudado

<form method="get"> não seria isso?