FallenHawk

Cara, não consigo entender direito o LEFT JOIN..

Ele junta os campo da tabela da esquerda (a) com os da tabela da direita -->, mas para que? Qual a função exata disso, o que faz esse left join ??

INNER
-- Pega só se as duas tiverem resultado (acho que é esse que o Celão quer)

LEFT
-- Pega todos da tabela da esquerda mesmo que não haja um valor correspondendo na tabela direita.

RIGHT
-- Pega todos da tabela da direito mesmo que não haja um valor correspondendo na tabela esquerda.

http://www.w3schools...ql/sql_join.asp

Uma sugestão: fazer uma query pra cada usuário encontrado é over demais.

Crie uma lista (usando as funções de lista como listvalue) com os IDs da primeira query e faz essa lista ser separada por vírgulas.

Agora você simplesmente usa essa lista de IDs no campo IN da query.

Ex:

SELECT algo from TABELA where ID IN (#lista#)

Quanto ao problema, eu não entendi ele muito bem, mas creio que é na query. Você também precisa de uma chave primária pra query dar 100% certo e usar no GROUP BY.

Tente algo como:

SELECT
   a.*, b.*
FROM
   tabela1 a 
LEFT JOIN 
   tabela2 b ON (a.userid = b.algum_campo)
WHERE
   a.tipousuario=1 and a.status=1 
GROUP BY
   a.chave_primária
ORDER BY 
   b.algum_campo DESC

Mas você nunca pensou em usar um sistema gratuito com o nedstart ou o Extreme Tracker? Eles dão muita informação (pena que o site fica em ingles).

Você pode fazer uma detectação simples usando Gecko, MSIE e Opera no "CONTAINS" do <CFIF> para ajudar uma variável que depois seria adicionada num DB.

XHTML não é só um HTML com um monte de "/" no fim das tags.
Ele é muito mais que isso. E sua importância vai além da sintaxe limpa.

XHTML é o HTML que pode ser lido com um parser XML
Desde o início os navegadores usaram parsers complacentes com SGML, que são mais lentos que os parsers XML. Isso porque parsers SGML são mais complexos por terem que lidar com tags abertas e outras fechadas, tendo que transformar toda a bagunça numa coisa que possa ser então passada ao interpretador do navegador e mostrado sem (muitos) erros na tela.

Todo o documento na web tem um tipo MIME. O HTML sempre teve o tipo text/html (muitos aqui já viram a tag <meta> com o content-type: text/html..).
Então, os servidores web se acostumaram a mandar os documentos HTML como text/html aos navegadores.

Mandando o text/html ao navegador, o servidor 'dizia' "aí vai um documento HTML" - HTML só pode ser lido com um parser SGML (por ter as aberrações que mencionei).

Já o XHTML deve (devia) ser servido como application/xhtml+xml: isso faz com que os navegadores interpretem o código realmente com um parser XML e não SGML.

Resultado: se você deixar uma tag aberta (sem fechar) e usar o parser XML, o parser falha e a única coisa que o visitante vai ter é um erro de parsing.

Vejam (inglês):
http://www.xml.com/p...e-into-xml.html

Porém esbarramos num problema: Navegadores antigos (IE6, versão antigas do Mozilla e Opera6) não sabem o que é application/xhtml+xml e por isso também não sabem que isso se trata de um documento XHTML. Logo, eles vão "baixar o arquivo" e não vão renderizar nada.

Por isso a W3C permitiu que os documentos XHTML fossem válidos se servidos como text/html. Porém, um XHTML servido como text/html não possui a principal vantagem de ser interpretado como XML, mas possui a vantagem de, se válido, ser interpretado como tal sem erros. Acontece que, mandando como text/html, os navegadores continuaram a aceitar os mesmos erros de sempre, sem dar os erros de parsing. Isso pode quebrar uma das razões do XHTML ter sido inventado.
http://jonasgalvez.c...04-06/validacao

Mudar o tipo MIME de um XHTML vai sim mudar o modo com que as tags respondem, por exemplo: todos os estilos CSS deverão estar em caixa-baixa (seu velho BODY {color: black; } não vai mais funcionar se você mandar o seu XHTML como XML).

DTD muda a rendering Engine do navegador
Isso já não tem nada a ver com o XHTML.
Isso tem mais relação com o CSS.

Com um DTD atual (HTML 4.01 Strict, XHTML 1 ou acima) os navegadores vão usar o "Standards Compliance Mode" (que respeita os padrões) e não o "Quirks Mode" (que é amigável a páginas construídas antes de 2001).

Se você tiver usando um DTD XHTML 1.0 (tanto faz qual):
-- O IE6 vai parar com o problema do box model.
-- O Opera vai parar de adicionar espaço entre floats como o IE.
-- O Netscape também vai mandar pro espaço as margens do 'além' nos divs e tabelas

Essa é a razão do DTD: o chamado "Switch" de modos. Essencial para quem vai desenvolver um XHTML Tableless válido.

Mas se você olhar o site no IE5.5 ou menor, você não vai ver diferença nenhuma. Essa técnica do switch foi inventada recentemente pra dar suporte aos padrões nos navegadores sem quebrarem páginas antigas (imagine o caos que seria se as páginas fora dos padrões parassem de funcionar).

Em resumo: um DTD tira suas dores de cabeça com navegadores decentes (fazendo com que Opera, Safari e Mozilla "mostrem" sua página da forma mais padronizada possível). O IE simplesmente vai parar com o problema do box-model, o resto dos bugs.. bom o resto você é que vai ter que achar e concertar.

Cada vez mais pessoas têm acessado a web através de celulares, video-games, palms e outras plataformas que não o PC convencional

Por isso a necessidade do XHTML: parsers XML são mais simples e deixam com que esse tipo de dispositivo possa acessar a web de forma mais rápida e simples.

"O XML foi feito para ser muito mais fácil de entregar via internet do que o SGML (HTML) provou ser e muito mais fácil para desenvolvedores de software implementar." -- http://etext.lib.vir...a.edu/sgml.html

XHTML é o HTML, baseado no XML e por isso será muito mais rápido e simples que o HTML. O HTML, que era baseado no SGML, é muito complexo para os novos meios de acessar a web.

Recomendo tentar o XHTML, ele é bem simples e mais fácil que o HTML. Mas tentem também não usar tabelas pro layout, ajuda um monte (e economiza muito mais banda e tempo de carregamento do que você vai gastar colocando um DTD).

Interessante.

Mas o problema é que algumas linguagens dinâmicas são movidas a partir do atributo name.

Isso eu quero ver.

Mas o interessante do id é que voce pode controlar pelo javascript.

Linguagens dinâmicas são processadas pelo servidor.
O atributo "ID" quem vai mandar é o navegador, usando a especificação de POST (ou GET) do HTTP. Tente fazer um form de método = "get" e você vai ver que o navegador vai tomar os cuidados pra fazer a url na forma "?id=valor".

Quanto ao JS, ambos podem ser referidos.
O JS pode usar o document.getElementById() para os ids e o document.forms.formulario.campo no caso dos "name".

Espero ter ajudado.

,18 Jul 2004, 17:07 ] caraca ...eh meio xxxxxx ... eh mais facil eu rodar todo o site no meu pc ...

que servidor web eu preciso instalar ?

Qualquer um que saiba responder ao pedido que o ColdFusion fizer.
Tanto o PHP quanto o ASP podem responder pedidos do ColdFusion e fazer pedidos ao ColdFusion num servidor remoto.

Acho que tudo isso é o que o pessoal chama de "webservice" - serviços remotos para serem acessados por outras aplicações.