Iniciar sessão ou registar-se
  1.  # 21

    Boas,

    Colocado por: Ferraz Oliveiracomo é que é feita a actualização dos posts? POST? GET?


    Sem ver o código: se são enviados ficheiros, é obrigatório que seja por POST e que o "encoding" seja "multipart".

    Colocado por: Ferraz Oliveira- tem track changes ligado?


    ??

    Colocado por: Ferraz OliveiraSe são dados vindos de uma BD então suponho que será um template (aliás...olhando para o HMI tenho quase a certeza) que é preenchido com os dados vindos da BD.


    Uh?
    Qual template?
    Não é assim que se faz as coisas em webdevelopement.

    Colocado por: Ferraz OliveiraDeve ser um único template que deve ser copiado/criada uma nova instância. Se fosse sempre um "singleton" a partir do momento em que tivesse ocorrido um erro num tópico ocorreria em todos os outros.


    O erros (estes) acontecem com "má" formatação de html num comentário, e afecta todo o html seguinte.
    Se existir má formatação de um comentário, só a página onde está esse comentário será afectada, se for por exemplo a outra página do mesmo tópico (seguinte ou anterior) não verá "problemas".

    Colocado por: Ferraz OliveiraBD não deve ter track changes. Quando muito terá uma tabela de históricos. Por aí poderá (mas deve dar mais trabalho que resolver uma equação diferencial de grau 1000) tentar saber quando é que o erro ocorreu.


    Uh?

    Colocado por: Ferraz OliveiraPenso que a solução (uma vez que para dar por tudo você teria que pôr um parser sobre o template e isso dá mais trabalho - mas lá está...fica bem feito e só se faz uma vez, não tem que andar a tentar corrigir isso cada vez que acontecer) poderá passar por você abrir o template do tópico em questão e fazer um parse a "olhómetro" a ver se existe alguma tag corrompida.


    Não!
    O parser terá de ser feito ao comentário inserido, se preferência quando é criado e inserido na BD (não seria a primeira vez que veria o parser a correr sobre dados vindos da BD).

    Divirtam-se,
    João Dias e seu gato psicanalista
    Concordam com este comentário: Nene2011
  2.  # 22

    Colocado por: oxelferBoas,



    Sem ver o código: se são enviados ficheiros, é obrigatório que seja por POST e que o "encoding" seja "multipart".



    ??



    Uh?
    Qual template?
    Não é assim que se faz as coisas em webdevelopement.



    O erros (estes) acontecem com "má" formatação de html num comentário, e afecta todo o html seguinte.
    Se existir má formatação de um comentário, só a página onde está esse comentário será afectada, se for por exemplo a outra página do mesmo tópico (seguinte ou anterior) não verá "problemas".



    Uh?



    Não!
    O parser terá de ser feito ao comentário inserido, se preferência quando é criado e inserido na BD (não seria a primeira vez que veria o parser a correr sobre dados vindos da BD).

    Divirtam-se,
    João Dias e seu gato psicanalista


    Por isso é que fiz tantas perguntas. Sem saber como funciona o servidor. Mas tu também poderia ter olhado com mais atenção para o o browser e ter chegado à conclusão que era um POST mas não pelo facto de serem passados ficheiros ou não. Há maneiras mais subtis e elegantes. Mas quando eu venho aqui para o fórum tento desligar a parte profissional.

    Mas ficheiros também podem ser enviados por GET...se bem que a coisa se torna insegura!

    Quando falo de um template caro joão falo de uma página preformatada com uma série de tags que são preenchidas com os dados que o servidor (quando é feito um pedido ao servidor) vai buscar. E dado que o HMI dos tópicos, sejam novos ou não é igual, a base chama-se template...a tal página preformatada que é preenchida com os dados que o servidor vai buscar.

    Uma base de dados bem construída tem um histórico. Não tem de raíz...até porque numa operação de CRUD, a partir do momento em que se faz o commit os dados anteriores "perdem-se". Só estão em memória entre o período que ocorre entre o start da transacção e o commit para se poder fazer rollback! A pessoa que implementa a base de dados (que não sei quem foi) é que, se estiver disposto a isso, deve ter uma tabela com o histórico. Assim, cada vez que um tópico é actualizado na tabela só consta a informação do último post e tudo o resto está numa tabela de histórico em que o browser pede ao servidor para ir buscar os ultimos X posts daquele tópico baseado no número de elementos (neste caso comentários) definidos por página.

    Se as coisas fossem feitas da maneira que sugeri no parágrafo acima o html afectado seria apenas o html do próprio comentário. E, se houvesse um template nem sequer era necessário haver parsing do html porque o cliente, quando verifica as tags, e estas estão incorrectas avisaria o user e assim só passava o html correctamente formatado para o servidor.

    Eu apenas fiz as questões que fiz para tentar, estando impossibilitado de olhar in loco a situação, descobrir de onde poderia vir potencialmente o problema.

    Cumprimentos
  3.  # 23

    Boas,

    Colocado por: Ferraz OliveiraMas ficheiros também podem ser enviados por GET...se bem que a coisa se torna insegura!


    Pode-me dar um exemplo?
    Que eu saiba não é possível.

    Colocado por: Ferraz OliveiraQuando falo de um template caro joão falo de uma página preformatada com uma série de tags que são preenchidas com os dados que o servidor (quando é feito um pedido ao servidor) vai buscar. E dado que o HMI dos tópicos, sejam novos ou não é igual, a base chama-se template...a tal página preformatada que é preenchida com os dados que o servidor vai buscar.


    Estávamos a falar dos comentários.

    Colocado por: Ferraz OliveiraUma base de dados bem construída tem um histórico. Não tem de raíz...até porque numa operação de CRUD, a partir do momento em que se faz o commit os dados anteriores "perdem-se".


    Não me leve a mal, mas:
    Em webdesign as coisas não funcionam assim (normalmente).
    Insere-se um comentário -> Cria-se um registo
    Altera-se um comentário -> altera-se um registo

    Colocado por: Ferraz OliveiraA pessoa que implementa a base de dados (que não sei quem foi) é que, se estiver disposto a isso, deve ter uma tabela com o histórico.


    Não é normal neste tipo de software.

    Colocado por: Ferraz OliveiraAssim, cada vez que um tópico é actualizado na tabela só consta a informação do último post e tudo o resto está numa tabela de histórico em que o browser pede ao servidor para ir buscar os ultimos X posts daquele tópico baseado no número de elementos (neste caso comentários) definidos por página.


    Não é assim que funciona:
    Temos duas tabelas:
    1 - topicos
    2 - comentarios

    Criar um tópico: 1 registo em topicos e 1 registo em comentarios
    Insere-se um comentário: insere-se um registo em comentários.

    NOTA: A tabela topicos pode ou não existir.


    Colocado por: Ferraz OliveiraSe as coisas fossem feitas da maneira que sugeri no parágrafo acima o html afectado seria apenas o html do próprio comentário.


    Quando existe uma falha na formatação do html (nem sempre, mas neste casos), todo o html seguinte (de toda a página) estará mal formatado.

    Colocado por: Ferraz OliveiraE, se houvesse um template nem sequer era necessário haver parsing do html porque o cliente, quando verifica as tags, e estas estão incorrectas avisaria o user e assim só passava o html correctamente formatado para o servidor.


    Agora perdi-me:
    não necessita porque quando verifica?!?!?
    mas o verificar não é um parsing?


    Divirtam-se,
    João Dias e seu gato psicanalista
  4.  # 24

    Colocado por: oxelferBoas,



    Pode-me dar um exemplo?
    Que eu saiba não é possível.



    Estávamos a falar dos comentários.



    Não me leve a mal, mas:
    Em webdesign as coisas não funcionam assim (normalmente).
    Insere-se um comentário -> Cria-se um registo
    Altera-se um comentário -> altera-se um registo



    Não é normal neste tipo de software.



    Não é assim que funciona:
    Temos duas tabelas:
    1 - topicos
    2 - comentarios

    Criar um tópico: 1 registo em topicos e 1 registo em comentarios
    Insere-se um comentário: insere-se um registo em comentários.

    NOTA: A tabela topicos pode ou não existir.




    Quando existe uma falha na formatação do html (nem sempre, mas neste casos), todo o html seguinte (de toda a página) estará mal formatado.



    Agora perdi-me:
    não necessita porque quando verifica?!?!?
    mas o verificar não é um parsing?


    Divirtam-se,
    João Dias e seu gato psicanalista


    Caro João:
    GET: você encripta um ficheiro no cliente e envia-o no URL para o servidor. Quer mais simples?

    Os comentários que você insere no browser não são inseridos numa text box? Se são sempre inseridos numa text box é porque a página à qual o seu browser está a fazer rendereing é sempre a mesma (a estrutura base)...ou seja...um template. O conteúdo é que muda e é formatado pelo servidor e enviado para trás.

    Em relação ao design da base de dados não me vou pronunciar porque eu de bases de dados não percebo nada e nem conheço o modelo. Base de dados só conheço o Excel.

    Se houvesse um template bem formatado e pensado o html mal feito só afectaria aquele post e não o restante porque o html estaria bem confinado dentro de uma tag mãe. Além disso, se houvesse validação do html nunca aconteceria a situação que o civismo reportou. Verificar e validar são coisas diferentes: Eu posso verificar se as tags estão abertas e fechadas mas não se a posição delas é válida. E é precisamente por não haver validação e verificação que o dito bug aconteceu.

    Cumprimentos

    Ricardo
  5.  # 25

    Boas,

    Colocado por: Ferraz OliveiraGET: você encripta um ficheiro no cliente e envia-o no URL para o servidor. Quer mais simples?


    uh?
    Encripto o que?
    O ficheiro ou o conteúdo ficheiro?
    Se encriptar o conteúdo «, não está a enviar um ficheiro!

    Colocado por: Ferraz OliveiraOs comentários que você insere no browser não são inseridos numa text box? Se são sempre inseridos numa text box é porque a página à qual o seu browser está a fazer rendereing é sempre a mesma (a estrutura base)...ou seja...um template. O conteúdo é que muda e é formatado pelo servidor e enviado para trás.


    Esta a confundir MUITAS coisas.

    Colocado por: Ferraz OliveiraSe houvesse um template bem formatado e pensado o html mal feito só afectaria aquele post e não o restante porque o html estaria bem confinado dentro de uma tag mãe.


    Tag mãe?
    Isso pura e simplesmente não existe!
    Uma tag mal fechada (nem sempre, mas quase sempre) "estraga" todo o html seguinte, e não há forma de fugir a isto.
    (lógicamente depende da tag, há tags que se forem mal fechadas não vêm mal ao mundo)

    Colocado por: Ferraz OliveiraAlém disso, se houvesse validação do html nunca aconteceria a situação que o civismo reportou.


    Validação de HTML = parser.

    Divirtam-se,
    João Dias e seu gato psicanalista
  6.  # 26

    Colocado por: Ferraz OliveiraGET: você encripta um ficheiro no cliente e envia-o no URL para o servidor. Quer mais simples?



    Não será bem assim...

    Por GET qualquer parametro/valor será sempre passado na chamada ao próprio URI, por POST os parâmetros/valores são passados já durante a ligação efectiva.

    Concordo com o reflexo, não estou a ver que consiga passar um ficheiro por GET, pelo menos de forma prática, uma vez que o tamanho máximo de um URL ronda os 8192 bytes (apache por exemplo) 8K apenas.. não é lá muito útil. Mas sim como prova de conceito sim.. seria possível.
  7.  # 27

    Boas,

    Colocado por: hangasPor GET qualquer parametro/valor será sempre passado na chamada ao próprio URI, por POST os parâmetros/valores são passados já durante a ligação efectiva.


    Por html é impossível passar um ficheiro por GET, e é tão simples provar isso como alterar o method de um formulário para GET e ver se o ficheiro é enviado. Além de ser POST, para enviar ficheiros é preciso que o formulário tenha o method como multipart
    O que se pode passar é passar o conteúdo de um ficheiro por GET, mas não vejo uma única razão para o fazer.

    Divirtam-se,
    João Dias e seu gato psicanalista
    Concordam com este comentário: hangas
  8.  # 28

    Relativamente à questão em causa.. o FD está a usar a plataforma de fóruns Vanilla http://vanillaforums.com/

    Possivelmente não na versão mais recente (não me dei ao trabalho de ver sequer) e algumas questões poderão já estar resolvidas.

    Mas o problema da desformatação e quase de certeza conteúdo "inválido" nos comentários. Mas quanto à "sanitation" dos conteúdos de utilizador, vulgo posts e comentários,
    é normal que sejam parsed/escaped antes de ir para a BD, embora em alguns casos particulares possa
    haver a necessidade de fazer esse "sanity check" nos dois sentidos. Por exemplo os os dados puderem ir parar à BD por outros canais não controlados.
    • hangas
    • 14 dezembro 2011 editado

     # 29

    Colocado por: oxelferO que se pode passar é passar o conteúdo de um ficheiro por GET, mas não vejo uma única razão para o fazer.



    Sim, bastaria fazer por exemplo http://some.host.com/sendfile.php?file=_um_ficheiro_qualquer_codificado_em_base64_ou_uuencode_
    Mas sim! não tem interesse nenhum!
  9.  # 30

    Boas,

    Colocado por: hangasPossivelmente não na versão mais recente (não me dei ao trabalho de ver sequer) e algumas questões poderão já estar resolvidas.


    Pelos 10 min que perdi com o vanilla:
    Seria necessário fazer um upgrade para uma versão posterior*.

    * não me estou a recordar agora dos termos correctos. Por versão digo passar de qualquer coisa como 1.23 para 2.32, pois se for de 1.21 para 1.34 será outro nome qualquer que não me lembro, ou o inverso.

    Divirtam-se,
    João Dias e seu gato psicanalista
    •  
      FD
    • 14 dezembro 2011

     # 31

    Colocado por: hangasPossivelmente não na versão mais recente (não me dei ao trabalho de ver sequer) e algumas questões poderão já estar resolvidas.

    O Piafinho já se voluntariou para ajudar, vamos aguardar.

    Quanto à versão seguinte do Vanilla: ainda dá um bocado de trabalho fazer a migração e o meu lema é "funciona? não mexe" (apesar destes pequenos detalhes).
  10.  # 32

    Boas,

    Colocado por: FDQuanto à versão seguinte do Vanilla: ainda dá um bocado de trabalho fazer a migração e o meu lema é "funciona? não mexe" (apesar destes pequenos detalhes).


    Não seria eu "informático" se não concordasse ;)

    Divirtam-se,
    João Dias e seu gato psicanalista
  11.  # 33

    Demorei algum tempo até vir aqui outra vez e perdi todo o texto que tinha escrito.

    @Hangas...ninguém disse que é de prático. Apenas disse que é possível. E de qualquer maneira, 8k podem ser suficientes para passar um ficheiro com mais de 20 vezes esse tamanho sem sequer o comprimir...

    @João: validação e verificação não são a mesma coisa. E fazer o parse de um html não quer dizer que ele seja válido. Numa aplicação web só através de um formulário é que se comunica com o servidor? Quando falo de uma tag-mãe falo de uma tag que implemente uma espécie de container (como uma root tag num ficheiro xml).

    E eu não estou a dizer que a aplicação está assim ou assado. Estou a dizer como é que eu implementaria uma coisa deste género. Obviamente que é bastante mais fácil e prático pegar numa coisa off-the-shelf. Mas depois tem algumas limitações que não podem ser alteradas porque não há maneira de interferirmos nós com a implementação do serviço.
  12.  # 34

    Colocado por: oxelfer* não me estou a recordar agora dos termos correctos.


    Upgrade de para uma Major Version vs. Minor Version?
  13.  # 35

    Boas,

    Colocado por: Ferraz Oliveiravalidação e verificação não são a mesma coisa.


    Chame-lhe o que quiser.

    Colocado por: Ferraz OliveiraNuma aplicação web só através de um formulário é que se comunica com o servidor?


    Não.
    Mas se não me falha a memória todo o contacto com um servidor web é feito ou por POST ou por GET (mesmo que não esteja implícito) e se for por GET não é possível o envio de ficheiros.

    Colocado por: Ferraz OliveiraQuando falo de uma tag-mãe falo de uma tag que implemente uma espécie de container (como uma root tag num ficheiro xml).


    E qual é ela (tag-mãe)?
    Que eu saiba (e posso estar enganado) não existe nenhuma tag ou container como lhe chama que me limpe (ou consiga ignorar) a má formatação de html anterior a ela.


    Divirtam-se,
    João Dias e seu gato psicanalista
  14.  # 36

    Boas,

    Colocado por: hangasUpgrade de para uma Major Version vs. Minor Version?


    Acho que não, mas não me recordo mesmo.

    Era qualquer coisa como isto, mas não são estes os termos:

    1.21 e 1.22 são da mesma versão mas de sub-versões (LOL) diferentes.
    1.21 e 2.22 são de versões diferentes

    Divirtam-se,
    João Dias e seu gato psicanalista
    • hangas
    • 14 dezembro 2011 editado

     # 37

    Olhe que então deve ser isso.

    Da 1.x para a 2.x aumenta uma Major Version.
    Da 1.2 para a 1.3 aumenta apenas uma Minor version.

    Em alguns casos usa-se também o build number. 1.2.1133 Major 1, Minor 2, Build 1133.

    Normalmente para se qualificar para uma nova Major Version implica alterações estruturais ou um número significativo de novas funcionalidades. Não há garantia de compatibilidade com a Major anterior.
    Num upgrade de minor version, pode haver algumas features novas, ou alteração nas existencia e algumas correcções importantes.

    Edit: Embora o principio seja este a nomenclatura não é obviamente fixa. Depende dos processos de desenvolvimento de cada empresa. Há empresas que utilizam por exemplo 4 ou 5 grupos. ex. 2.23.53.12

    Num build upgrade é normalmente pequenos bug fixes e geralmente é feito de forma automática. isto é. de cada vez que há uma alteração (commit) no repositório de código o produto é complicado e incrementado o build number.
    Concordam com este comentário: FD, oxelfeR (RIP)
    •  
      FD
    • 14 dezembro 2011

     # 38

    Colocado por: hangasDepende dos processos de desenvolvimento de cada empresa.

    O Google Chrome já vai na versão 16... e é quase igual à versão 1.
  15.  # 39

    É igual em aspecto, mas é esse o objectivo. Internamente já quase não tem nada a ver com a versão 1.

    Existem também pelo menos 3 ramos de desenvolvimento.
    STABLE para o público em geral
    BETA para os que querem testar a potencial próxima versão, embora menos estável
    DEV ramo para os aventureiros que querem experimentar a última versão possível ou que querem contribuir para o desenvolvimento eles próprios, são versões mesmo em bruto que alteram mais do que uma vez por dia e que podem não funcionar de todo :)


    Basta seguir o changelog

    http://www.softpedia.com/progChangelog/Google-Chrome-Changelog-108166.html
  16.  # 40

    Boas,

    Colocado por: hangasOlhe que então deve ser isso.


    A explicação está correcta, mas os termos não eram esses, ou então eram (são) e sou eu que estou a ficar chéché!

    Divirtam-se,
    João Dias e seu gato psicanalista
 
0.0179 seg. NEW