Response...

[Bruno Augusto 417]

Bom, vou reviver o tópico mais um pouquinho.

 

Seria correto enviar um cabeçalho informativo, do grupo 4xx ou 5xx, quando uma Exception é disparada (e pêga pelo Handler definido)?

 

Independente da resposta acima, já que se negativa eu apenas removo o que tenho atualmente, me esclareçam uma coisa.

 

Eu tenho dois Exception Handlers, um para desenvolvimento, que é mais "bonitinho" e com várias informações que pode facilitar (ou não :ermm: ) a detecção de onde o erro ocorreu, e outro mais simples, focado puramente para o ambiente de produção.

 

Errado ou não, por hora eu envio um Response Code 500 (Internal Server Error) no Handler de Desenvolvimento e um Response Code 400 (Bad Request) no de Produção.

 

Da lista que tenho, foram os mais próximas a se encaixar na situação. <_<

 

Com toda essa implementação da classe Response, percebi que o Response Code 500 "mata" o restante do que a Response faz.

 

Como a Response vai enviar conteúdo, e cabeçalhos não podem ser enviados depois de conteúdo, os dela devem ser enviados antes do output ser enviado.

 

Mas o Response Code 500, interrompe bruscamente o "fluxo" entre a aplicação e o browser, fazendo com o que o ouput não seja enviado.

 

Para enviar o código 500 E a saída HTML, eu tive de enviar o cabeçalho E a Resposta. Daí então definir o Template a ser usada e enviar a Resposta DE NOVO, mas desta vez sem o cabeçalho.

 

Como Request e Response são únicas, são classes com Singleton e workaround acima funciona. Mas tenho certeza de que isso não é certo, e com isso voltamos à resposta da primeira pergunta.

 

Por fim, a questão final seria: Se o Response Code 500 "mata" o output da Response, outros cabeçalhos também o fazem?

 

Se fazem, quem se encarrega de "entender" o código e abortar o output? Eu (minha aplicação) ou o navegador?

[JCMais 75]

Seria correto enviar um cabeçalho informativo, do grupo 4xx ou 5xx, quando uma Exception é disparada (e pêga pelo Handler definido)?

Possivelmente, depende do porque, e do contexto no qual essa Exception foi disparada.

 

Errado ou não, por hora eu envio um Response Code 500 (Internal Server Error) no Handler de Desenvolvimento e um Response Code 400 (Bad Request) no de Produção.

Neste ponto você está incorreto, você generalizou os códigos de resposta para estes dois. Digamos que você dispare uma Exception em uma action porque determinado Resource não foi encontrado, neste caso se tiver em produção seria 500, caso contrário 400, mas o correto não é nenhum, nem outro, mas sim 404. Neste caso eu recomendo definir o código de resposta de acordo com a Exception que for capturada pelo o teu Handler definitivo. Assim, você pode por exemplo criar uma classe de Exception para as Action, que pode receber como parametro o código HTTP à ser enviado, ou algo do tipo.

 

Com toda essa implementação da classe Response, percebi que o Response Code 500 "mata" o restante do que a Response faz.

Então tem algo errado, ela não deveria "matar" o restante que a Response faz.

 

Para enviar o código 500 E a saída HTML, eu tive de enviar o cabeçalho E a Resposta. Daí então definir o Template a ser usada e enviar a Resposta DE NOVO, mas desta vez sem o cabeçalho.

Isto está totalmente errado. Você está enviando duas respostas, para apenas uma requisição.

 

Como Request e Response são únicas, são classes com Singleton e workaround acima funciona. Mas tenho certeza de que isso não é certo, e com isso voltamos à resposta da primeira pergunta.

Request e Response não deveriam ser Singleton, e caso você queira simular uma requisição internamente, dentro de uma requisição real? Por exemplo, para testar se a requisição é válida? E se for necessário testar mais de uma Requisição ao mesmo instante em testes unitários por exemplo? Este é um dos casos em que Singleton = Bad Design.

 

Por fim, a questão final seria: Se o Response Code 500 "mata" o output da Response, outros cabeçalhos também o fazem?

 

Se fazem, quem se encarrega de "entender" o código e abortar o output? Eu (minha aplicação) ou o navegador?

Primeiro, como disse o 500 não deve matar o output da Response, você deve verificar por erros antes de definir o output da Response, isto porque no momento que você verificar que existe um erro, você cancelaria a renderização da action atual, e redirecionaria, internamente, por exemplo, para uma controller apenas para o tratamento de erros, nele você iria renderizar um template para o erro atual. E pronto, apenas isto, o restante segueria normalmente, o teu Response Code seria 500, e o body da tua Response seria o template renderizado anteriormente.

[Bruno Augusto 417]

Seria correto enviar um cabeçalho informativo, do grupo 4xx ou 5xx, quando uma Exception é disparada (e pêga pelo Handler definido)?

Possivelmente, depende do porque, e do contexto no qual essa Exception foi disparada.

O conceito atual é que, para Exceptions "críticas", daquelas que podem afetar o funcionamento da Aplicação, como por exemplo usar uma variável de template não definida, eu forço o uso do Handler de Desenvolvimento.

 

Assim, evito ser pêgo pela preguiça ( :P ) e corrijo o problema. Uma vez consertado, esse Handler nunca mais será forçado.

 

Errado ou não, por hora eu envio um Response Code 500 (Internal Server Error) no Handler de Desenvolvimento e um Response Code 400 (Bad Request) no de Produção.

Neste ponto você está incorreto, você generalizou os códigos de resposta para estes dois. Digamos que você dispare uma Exception em uma action porque determinado Resource não foi encontrado, neste caso se tiver em produção seria 500, caso contrário 400, mas o correto não é nenhum, nem outro, mas sim 404. Neste caso eu recomendo definir o código de resposta de acordo com a Exception que for capturada pelo o teu Handler definitivo. Assim, você pode por exemplo criar uma classe de Exception para as Action, que pode receber como parametro o código HTTP à ser enviado, ou algo do tipo.

Hmmmmm.... Posso fazer melhor até.

 

Alterando um pouquinho minha classe-base de Exceptions, posso permitir que um Response Code específico seja usado. Assim, quando pêgo pelo Handler, esse valor será usado na Response.

 

E, como todas as classes de Exception derivam dessa uma, ainda posso abstrair Response Codes padrão, caso nenhum seja informado ali, junto ao throw.

 

Com toda essa implementação da classe Response, percebi que o Response Code 500 "mata" o restante do que a Response faz.

Então tem algo errado, ela não deveria "matar" o restante que a Response faz.

Uma ajudinha para identificar esse problema? Essa coisa de Response ainda é nova pra mim...

 

Muito embora eu acredite que nem seja culpa dela e sim do Front Controller.

 

Para enviar o código 500 E a saída HTML, eu tive de enviar o cabeçalho E a Resposta. Daí então definir o Template a ser usada e enviar a Resposta DE NOVO, mas desta vez sem o cabeçalho.

Isto está totalmente errado. Você está enviando duas respostas, para apenas uma requisição.

Pois é, sei que está errado. E ainda estou na luta pra conseguir entender.

 

Como Request e Response são únicas, são classes com Singleton e workaround acima funciona. Mas tenho certeza de que isso não é certo, e com isso voltamos à resposta da primeira pergunta.

Request e Response não deveriam ser Singleton, e caso você queira simular uma requisição internamente, dentro de uma requisição real? Por exemplo, para testar se a requisição é válida? E se for necessário testar mais de uma Requisição ao mesmo instante em testes unitários por exemplo? Este é um dos casos em que Singleton = Bad Design.

Hmmmm.... Talvez seja por isso que eu tentei, meio que de brincadeira mesmo, puxar os cabeçalhos da requisição atual, dentro dela mesma e deu pau no Apache xD

 

Mas isso é o de menos. Perpetuar as informações que preciso do Front Controller até a View sem Singleton, basta que eu utilize a própria hierarquia de camadas que funciona.

 

Aquilo que é definida na camada mais baixa (Front Controller) estará disponível tranquilamente nas mais altas (Controller e View, por exemplo).

 

Por fim, a questão final seria: Se o Response Code 500 "mata" o output da Response, outros cabeçalhos também o fazem?

 

Se fazem, quem se encarrega de "entender" o código e abortar o output? Eu (minha aplicação) ou o navegador?

Primeiro, como disse o 500 não deve matar o output da Response, você deve verificar por erros antes de definir o output da Response, isto porque no momento que você verificar que existe um erro, você cancelaria a renderização da action atual, e redirecionaria, internamente, por exemplo, para uma controller apenas para o tratamento de erros, nele você iria renderizar um template para o erro atual. E pronto, apenas isto, o restante segueria normalmente, o teu Response Code seria 500, e o body da tua Response seria o template renderizado anteriormente.

Este problema está diretamente ligado à análise aprofundada do meu Front Controller. Acredito que quando acertá-lo eu mate três coelhos como uma cajadada só.

 

A prpósito, quê que aconteceu com os sistema de QUOTE? Simplesmente por citar a sua mensagem não consegui copiar as minhas (as quais você citou) e manter um bom fluxo de legibilidade.

 

Tive que editar sua mensagem, copiar o texto e ir respondendo manualmente. Sofrível...

[JCMais 75]

A questão dos Quotes é porque ao citar uma mensagem que já tem citação, a citação anterior é removida, não sei porque decidiram fazer desta forma, mas aí já é com os caras lá de cima. :lol:

 

Tem como postar o teu Front Controller? Seria legal se você pudesse colocar esta tua framework/biblioteca no GitHub, caso tenha conta lá. ^_^

[Bruno Augusto 417]

Apesar de estar melhorando progressivamente, na medida do possível, já que meu tempo de programação é curto, pelo menos por enquanto, não vou dar o mapa para o El Dorado assim, tão rápido.

 

Quanto ao GIT, eu até criei uma conta lá, para experimentar o equivalente ao PasteBin dele (esqueci o nome). Já o GIT mesmo, não sei usar.

 

mas de um modo geral, aquilo que realmente me impede de postar é que, como eu disse, apesar de estar progredindo, algumas coisas ainda me envergonham nele. Não que eu esteja fazendo algo errado de propósito, mas é que estou engatinhando nesse mundo de Design Patterns e a crítica de quem entende é voraz.

 

Sem contar que tem alguns recursos no sistema praticamente únicos. :rolleyes: