-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gerador de páginas #59
Comments
Outra coisa, isso pode resolver o problema de performance por conta de ter N mapas na home page. No celular fica meio pesado (to fazendo a parte responsiva =] ) |
O @IAMFELIPESOUZA tinha algumas idéias também podemos colocar todas em prática. |
legal @williamespindola , podemos analisar N condições e matar todas numa versão nova. Outra coisa, podemos também pegar um dominio .io só fazendo um alias pra URL do github. |
@rafaell-lycan ja esta em um domínio .io http://saiadecasa.github.io/ |
We are poor :-(! |
Vocês não acham legal usar angular não?
|
Cara, manda um PR com sua ideia funcionando, blz? Achei muito interessante! Falou! — |
Tranquilo, vou montar a estrutura aqui e mando |
To montando o website com Jekyll. Uma dúvida, vai permanecer o mesmo layout? Angular também é legal, porque se não quisermos usar DB, podemos alimentar um JSON como recurso e configurar para mostrar apenas eventos que ainda não aconteceram a partir de Date.now() Qual a melhor solução? =) |
Outra coisa, com Jekyll cada evento é um arquivo.md, isso acho bem válido pra postar novos eventos. |
Pessoal, acho que essas decisões estão em aberto ainda.
Mandam PRs protótipos pra discutirmos em cima, ok?
|
Sim pessoal nos envie protótipos! Temos um no develop em produção também... |
@williamespindola seria possível o proprio usuário cadastrar o evento no site e automaticamente isso bate no endpoint do github remetendo a um PR do mesmo na org? |
Esse não é o foco agora. O foco agora é manter apenas com os Pull Requests mesmo, sem inclusão pelo próprio site. A nossa idéia sempre foi "forçar" esse fluxo do Git e Github para os contribuidores, dessa forma o pessoal aprende o processo para usar com qualquer projeto open source, entende? — On Sat, Feb 28, 2015 at 11:48 AM, Felipe Souza [email protected]
|
entendo @rogeriopradoj, eu só queria saber mesmo se é possível para quem sabe um uso futuro tanto nesse projeto como em outros por aí. |
Ola pessoal, ainda estao discutindo o que vao usar para gerar paginas? Vi seu projeto e queria saber se posso ajudar.. |
Daria pra fazer algo em js pra consumir um json, já que é bem básico o que tem nas páginas... |
Isto que estava pensando, podem usar hogan.js (pq e leve) para gerar o HTML. |
A tecnologia eu não conheço pra apontar, mas qualquer uma que seja capaz de parsear um json e fazer um bind em um loop, atende o que precisaria aqui. |
Nada definido ainda? Acho que geradores estáticos (Jekyll, DocPad) são melhores, porque o site já vai pronto pro cliente, podendo usar um arquivo JSON externo pra manter os eventos do mesmo jeito. |
Fala pessoal; Tenho uma sugestão para fazer sobre o site. Não sei se essa issue é o melhor lugar, mas antes de criar uma específica para isso gostaria de compartilhar a ideia. A ideia é ter o mapa como principal item na tela. Dele ser o cara que o usuário vai ver. A página seria composta basicamente pelo mapa, que teria um marker pra cada evento. Já vi em vários lugares isso, mas o único exemplo que consigo lembrar agora é do Android Device Manager: Acho isso interessante porque a principal informação que o site quer passar é quando e onde os eventos vão acontecer, de maneira simples e direta - e é exatamente isso que o mapa vai fornecer. Poderia ter uma lista do lado com informações básicas de todos os eventos disponíveis no mapa e, clicando nesse evento (ou no marker dele), ele é centralizado no mapa e são mostrados seus detalhes. Podemos usar também o recurso de junção de markers do Google Maps, caso os eventos sejam muito próximos: Acho que isso traria uma informação mais concentrada -- um mapa para todos os eventos ao invés de uma lista com diversos mapas --, mais fácil de navegar quando a lista de eventos for grande, além de economizar banda de internet e processamento, exatamente pelo fato de apenas um Google Maps estar sendo carregado. |
@danguilherme olá, parece bem interessante essa proposta! (desculpe a demora para dar alguma posição!) Será que você consegue dar ajuda junto com o #210 que o @LeoPersan está tocando? Falou Rogério C/C @saiadecasa/collaborators @saiadecasa/owners |
@rogeriopradoj, obrigado pela resposta! Comecei implementando um exemplo: http://eventos-br.surge.sh/ (favor não reparar no estilo! hahaha). Como dito, o principal são os eventos, com um único mapa, e uma lista deles. Clicando tanto nos eventos quanto nos pins, os detalhes do evento são mostrados. O projeto está no GitHub e testei apenas no Chrome, enquanto fazia. Usei DocPad como gerador do site estático e um pouco de ES6, espero que dê pra entender tudo, mas qualquer coisa estou à disposição. Caso seja essa solução a ser utilizada, precisaríamos de um layout meio que definido, infelizmente esse não é o meu forte rs. Outra coisa, você comentou sobre a issue #210... é pra priorizar ela e depois implementar esse novo layout ou fazer os dois já integrados? De qualquer maneira, vou ver se consigo dar uma olhada nela. |
Se eu puder emitir uma opinião é de que seria melhor usar o Jekyll, primeiro porque o Github dá suporte pras builds automáticas, não precisaria colocar em um dominio ou ter uma estrutura propria. Segundo lugar, todos os eventos ficam em .md separados, o que facilita múltiplos PR's ao mesmo tempo, ou remover um evento por exemplo, não correndo o risco de um cagar no outro. A gente usa Jekyll lá no DNE e roda muito bem. Nós temos uma estrutura própria de servidor, mas por outros motivos, mas tudo é gerado via Jekyll. |
@raymonsanches acho que pode ser (ou não ser, hehe) qualquer gerador de estático. No meu blog estou usando o @sculpin que é em PHP. Lá no escritório usando o Hugo que é em Go. Entre os dois estou indo mais para o Hugo. Na vantagem do build automático do Jekyll não tem muita dificuldade pois podemos colocar esse um script simples no Travis-CI por exemplo que gere os arquivos automaticamente. Sobre os .md separados, acho que talvez possa sim virar uma opção, como o @rafaell-lycan já cobra a gente faz tempo ;-) |
Pessoas legais, tudo bem?
Estou ultimamente brincando com Jekyll no meu blog e estou curtindo.
Vantagens: Fácil de aprender, suporte a Markdown, ridiculo para implementar coisinhas.
Desvantagens: Pra desenvolver localmente, é necessário ter Ruby instalado.
Seria legal dar uma repaginada, onde listamos todos os eventos (home) gerando novas páginas com detalhes sobre cada evento. Assim fica tudo mais organizado e ainda escrevemos um único arquivo (.md) sobre cada novo evento.
Outras sugestões são bem vindas.
The text was updated successfully, but these errors were encountered: