Arquivos dinâmicos vão para as pastas views e assets e estáticos para javascript e css,
Tratamento de erros:
500
404
Tudo que envolve código dinâmico vai para suas pastas em app.
A pasta assets vão:
js
css
sass
less
Objetivo dessa pasta assets é compilar estes arquivos em arquivo único chamado: application.js ou aplication.css. Esta pasta na prática serve para reduzir a quantidade de requests do nosso sistema. Se os arquivos .js e .css não fossem unidos reduzindo a quantidade de cada .js e .css, a quantidade de requests seriam aumentadas e muito diminuindo a performance visto que seria uma requisição para cada arquivo necessário.
Quando usar a pasta public?
Caso não saiba ainda utilizar a pasta assets, porém lembre-se que estes arquivos da pasta public fazem cache no navegador. Isso implica diretamente na usabilidade do cliente, pois se o cliente está utilizando nosso site/sistema e já fez cache desses arquivos, quando fizermos alguma alteração, o navegador continuará utilizando os arquivos antigos pois estão no cache, assim ficando desatualizado.
Um exemplo de uso ideal para páginas estáticas são as de tratamento de erros como 500 e 404, pois caso estes erros tenham sido tratados em páginas dinâmicas que dependem do servidor, estes tratamentos também não funcionarão.
Se o que queremos utilizar no nosso site, sabemos que nunca serão alterados também é melhor utilizar as pastas de arquivos estáticos, pois estas pelo fato de não terem processamento deixam nosso site mais rápido, mais fluido.
Dentro da pasta assets na pasta stylesheets veremos o arquivo application.css que nele temos este trecho de código que basicamente informa a aplicação que, por exemplo, tem que renderizar os arquivos de css que estão na árvore de arquivos referente a este próprio arquivo. Assim, os outros css, a partir deste funcionarão de acordo com o planejado.
*= require_tree .
*= require_self
Este arquivo application.ccs ele é o arquivo principal dos outros css. Ele que faz o require dos outros. Buildado ou não.
Se eu quiser fazer o require de apenas uma arquivo eu apago este código acima e escrevo apenas o desejado:
*= require body
Então para exemplificar, criaremos um arquivo css dentro da págia stylesheets que modifica o body de toda a aplicação.
body {
background: #9797c9;
}
Já os arquivos estáticos que se localizam na pasta public tem que ser refernciados diretamente no html de duas formas:
diretamente na tag script:
A pasta public tem acesso de fato público. Se digitarmos na url após o localhost e a porta o nome do arquivo com seu formato, o contreúdo deste arquivo será mostrado.
Erro 404:
http://localhost:3000/404.html
http://localhost:3000/teste.js
Para exemplificar também a idéia dos arquivos estáticos vs dinâmicos podemos perceber que ao rodar a aplicação em ambiente de produção teremos que recompilar os arquivos dinâmicos caso contrário eles não serão reconhecidos.
Já os estáticos continuam funcionando.
Este processo de compilação deixa os arquivos mais performáticos e os salva na pasta public/assets.
Após esta compilação em ambiente de produção os arquivos funcionam normalmente.
É interessante de notar que em ambiente de produção as telas de erros do rails não são aprensentadas, mas sim as páginas prontas de cada erro da pasta public que inclusive podem ser também tratadas:
Podemos também observar que em produção também não podemos visualizar no console os erros que estão acontecendo. Para isso temos uma pasta chamada log e um arquivo chamado production.
Aula 33
Arquivos dinâmicos vão para as pastas views e assets e estáticos para javascript e css, Tratamento de erros:
Tudo que envolve código dinâmico vai para suas pastas em app.
A pasta assets vão:
Objetivo dessa pasta assets é compilar estes arquivos em arquivo único chamado: application.js ou aplication.css. Esta pasta na prática serve para reduzir a quantidade de requests do nosso sistema. Se os arquivos .js e .css não fossem unidos reduzindo a quantidade de cada .js e .css, a quantidade de requests seriam aumentadas e muito diminuindo a performance visto que seria uma requisição para cada arquivo necessário.
Quando usar a pasta public?
Um exemplo de uso ideal para páginas estáticas são as de tratamento de erros como 500 e 404, pois caso estes erros tenham sido tratados em páginas dinâmicas que dependem do servidor, estes tratamentos também não funcionarão.
Se o que queremos utilizar no nosso site, sabemos que nunca serão alterados também é melhor utilizar as pastas de arquivos estáticos, pois estas pelo fato de não terem processamento deixam nosso site mais rápido, mais fluido.
Dentro da pasta assets na pasta stylesheets veremos o arquivo application.css que nele temos este trecho de código que basicamente informa a aplicação que, por exemplo, tem que renderizar os arquivos de css que estão na árvore de arquivos referente a este próprio arquivo. Assim, os outros css, a partir deste funcionarão de acordo com o planejado.
Este arquivo application.ccs ele é o arquivo principal dos outros css. Ele que faz o require dos outros. Buildado ou não.
Se eu quiser fazer o require de apenas uma arquivo eu apago este código acima e escrevo apenas o desejado:
Então para exemplificar, criaremos um arquivo css dentro da págia stylesheets que modifica o body de toda a aplicação.
Já os arquivos estáticos que se localizam na pasta public tem que ser refernciados diretamente no html de duas formas:
A pasta public tem acesso de fato público. Se digitarmos na url após o localhost e a porta o nome do arquivo com seu formato, o contreúdo deste arquivo será mostrado.
Para exemplificar também a idéia dos arquivos estáticos vs dinâmicos podemos perceber que ao rodar a aplicação em ambiente de produção teremos que recompilar os arquivos dinâmicos caso contrário eles não serão reconhecidos. Já os estáticos continuam funcionando.
Roando em produção:
Ou:
Recompilando os assets em ambientes de produção:
Este processo de compilação deixa os arquivos mais performáticos e os salva na pasta public/assets. Após esta compilação em ambiente de produção os arquivos funcionam normalmente.
É interessante de notar que em ambiente de produção as telas de erros do rails não são aprensentadas, mas sim as páginas prontas de cada erro da pasta public que inclusive podem ser também tratadas:
Demonstrando como tratar uma página erro: https://youtu.be/4nmQgWbSnA0?t=2328
Podemos também observar que em produção também não podemos visualizar no console os erros que estão acontecendo. Para isso temos uma pasta chamada log e um arquivo chamado production.