Atualizações de Jacson Ativar/desativar aninhamento de comentários | Atalhos do Teclado

  • Jacson 17:47 em 24 de March de 2014 Link permanente |
    Tags:   

    Dúvidas na implementação do Minka 

    Estamos com algumas dúvidas na implementação da parte de cadastro/exibição de soluções, partindo com base em:
    Wireframe: http://dev.redelivre.org.br/files/2014/03/3-consulta-catalogo-final.png

    Formulário de cadastro: https://docs.google.com/a/ethymos.com.br/forms/d/1aaOtBSwqHFGePTxNUxmni315toM0D15rfvGYX28StHE/viewform?edit_requested=true

    Percebi que a um diferença em o que é cadastrado e em o que exibido, gostaria de saber como que podemos definir, na exibição:
    queén puede usario
    cómo se usa
    consejos y datos útiles
    Valoración (muestra indicadores y comentarios de la comunidad)

    O ultimo não sei nem como que podemos ter esse dado ou informá-lo. Também há vários campos no cadastro que não são mostrados, como as categorias a que pertence a solução.

     

  • Jacson 17:45 em 5 de February de 2014 Link permanente |
    Tags: form   

    Alternativa ao google form “self hosted” 

    Achei essa ferramenta para criar forms, o que acham, vale a pena implementar na Rede Livre?

    http://minikomi.github.io/Bootstrap-Form-Builder/

     

    • Eduardo Zulian 11:03 em 13 de fevereiro de 2014 Link permanente | Faça login para responder

      Legal o projeto!

      Mas qual é o problema com a atual e quais as vantagens e desvantagens em adicionarmos esse form builder?

  • Jacson 17:53 em 27 de November de 2013 Link permanente |
    Tags:   

    Widget RSS3.0, especificação? Precisamos das demandas desse plugin.

     

    • Eduardo Zulian 11:54 em 29 de novembro de 2013 Link permanente | Faça login para responder

      Solta uma pequena ideia sobre ele, @jacson, porque não sei do que se trata!

      • Jacson Passold 14:24 em 3 de dezembro de 2013 Link permanente | Faça login para responder

        Conforme eu comentei na reunião, Isso é o que eu lembre de conversar informais que tive com o Jpmelh e com o Phillipe:
        Imagino que temos 2 demandas nesse projeto:
        1) Leech RSS: Ter uma “cara de mais bonita” (layout do widget), provavelmente mais opções, tem que ver porque 3.0, isso eu não sei;
        2) Provider RSS: Que precisa disponibilizar de forma organizada os dados do site, por exemplo, rss de uma taxionomia, de uma post_type;

        • Phillipe Trindade 19:07 em 10 de dezembro de 2013 Link permanente

          É isso aí, Jac!

          Funcionalidades
          Na real precisamos já prever maneiras de circular conteúdo entre a rede e de fora da rede dentro dela… Ou seja, prever um agregador que possibilite 1) receber e 2) sindicar cinco coisas dos post_types:

          1. Título
          2. Resumo
          3. Autor
          4. Data
          5. Imagem destacada

          Creio que o mais cabeludo vai ser a imagem destacada…

          Para mim, a maior referência é o widget “Posts de uma Categoria” do Guarani, cuja configuração dá essas opções, permitindo usar o 5. ao “destacar um post”, no que o widget chama a imagem destacada.

          Quem sabe essa opção fique restrita ao RSS sindicado dentro da rede, mas não tem problema.

          Layout
          Uma segunda questão é o layout. Acho que o ideal é não ter um próprio. Hoje, ele exibe os itens 1, 2, 3 e 4 em texto simples, mas, na lógica dos Posts de uma Categoria, seria importante exibir esse conteúdo dentro da identidade visual de cada tema, principalmente se o destaque estiver ativo.

          Outra referência é o layout do tema creta do plugin Delibera, em que a Thalita preparou um código que adapta alguns detalhes da exibição ao layout do tema, o que talvez contemple já boa parte dessa problemática.

          Espero ter sido claro. Sigo aí para mais dúvidas.

  • Jacson 18:59 em 7 de November de 2013 Link permanente |  

    Busca Avançada Widget 

    Então gente estamos discutindo o widget de busca avançada que será desenvolvida pelo nosso colega João Paulo Apolinário, junto com o Design do Henrique, cujo layout coloco em anexo como exemplo, mas não para a redelivre, apenas uma noção pelo layout proposto pelo Henrique para o Direito a moradia.

    Filtro avançado fechado

    Filtro avançado aberto

    Minha proposta inicial é um widget que se adapte ao contexto e seja capaz de fazer filtro em vários locais do wordpress e utilize ajax como método de atualização de um local a ser definido na configuração, porem em conversa com o Eduardo, achamos mais simples e intuitivo para o usuário utilizar postback e o filtro de query do WordPress.

    Vamos a minha proposta:
    1) O filtro é um widget;
    2) Possui as seguintes capacidades de pesquisa:
    2.1) Texto;
    2.2) Data (inicial, final, período);
    2.3) Taxionomias (classificação, tags, etc);
    2.3.1) Opção através de botão de seleção de “E” ou “OU”;
    2.3.2) Listagem em forma de árvore com opção de marcação;
    2.4) Detecção automática ou não do post_type, tendo opções como auto (automática) e todos
    3) Ser configurável para mostrar a opções de filtragem;
    4) Configurar quais taxionomias mostrar.
    5) Se for ajax (talvez uma opção para isso), qual parte do site atualizar:
    5.1) Uma opção seria por ID do elemento (muito complexa);
    5.2) Pegar o Id do elemento através de um “shadowbox” com a área do site e os possíveis elementos;
    5.3) Tentar supor qual o elemento por aproximação dos campos com post-id;

     

    • Phillipe Trindade 19:58 em 7 de novembro de 2013 Link permanente | Faça login para responder

      “mais simples e intuitivo para o usuário utilizar postback e o filtro de query do WordPress.”
      Será possível a barra “ir carregando” os resultados, como no campo de “novo usuário”?

      “2.3.2) Listagem em forma de árvore com opção de marcação;”
      Não entendi!

      2.4) Detecção automática ou não do post_type, tendo opções como auto (automática) e todos
      Tbm não entendi. Isso é o que eu perguntei lá em cima?

      “5) Se for ajax (talvez uma opção para isso), qual parte do site atualizar:”
      O que implica ser ou não ser Ajax?

      Valeu, Jacson!

      • Jacson Passold 2:04 em 8 de novembro de 2013 Link permanente | Faça login para responder

        “Será possível a barra “ir carregando” os resultados, como no campo de “novo usuário”?”
        Não, só através de ajax e de uma barra de rolagem infinita, o que é complicado para agora, mas pode ser uma extensão para o futuro como já sugeriu o Eduardo.

        Arvore é estilo o que os exploradores de arquivos normalmente usam, onde você clica em um nodo para abrir (visualizar) os nodos seguintes, como por exemplo clicar em uma pasta para ver as subpastas. Opção de marcação é algo que possibilite checar um elemento da arvore um ou ramo inteiro, como uma checkbox.

        “2.4) Detecção automática ou não do post_type, tendo opções como auto (automática) e todos”
        Isso faz parte das opções de configuração, vou melhorar isso para ficar mais claro. Essa opção determina qual ou quais tipos de posts (post, página, pauta, item do mapa, mídia, etc) serão exibidos e em adicional a opção todos e a opção automática, que por exemplo detecta que vai ficar por post se vc estiver vendo posts, por página se vc estiver vendo uma lista páginas, pautas se você estiver no delibera, etc.

        5) nesse caso sugiro a leitura:
        http://pt.wikipedia.org/wiki/AJAX_%28programa%C3%A7%C3%A3o%29
        http://pt.wikipedia.org/wiki/Postback

        postback é enviar todo o conteúdo para o servidor, ou seja, recarregar a página para realizar a busca
        ajax ou callback é enviar parte do conteúdo selecionado e recuperar apenas a informação pertinente de atualização e faze-lo em tempo real, sem necessidade da recarga da pagina.

    • joaopaulo 2:13 em 8 de novembro de 2013 Link permanente | Faça login para responder

      Olá pessoal. Jacson, gostei bastante das sugestões, ficou bem robusto. O design está ótimo também, acredito que possamos aproveitar dessa estrutura e deixar o layout flutuar entre o design de cada tema, com opções de customização.

      Fiquei em dúvida no seguinte ponto:
      “5.3) Tentar supor qual o elemento por aproximação dos campos com post-id;”
      Não sei se entendi direito esse ponto. Mas se eu tiver entendido, acredito que é exatamente o que a busca/queries do WordPress faz, não? Nesse caso não precisaríamos reinventar a roda. Perdão se eu tiver compreendido errado.

      Abraço a todos

      • Jacson Passold 12:14 em 8 de novembro de 2013 Link permanente | Faça login para responder

        Acho que meu “sistema de indexação” não ficou bem explicado, o 5.3 faz parte da opção por ajax (5), o ajax não atualiza o alvo do WordPress e sim o que você especificar, o problema é achar o alvo certo, nesse caso específico, achar em qual elemento, do tema onde esse widget foi ativado, está a lista de ‘posts’ que o widget precisar atualizar. Pode ser que você tenha uma opção melhor para contornar isso, todas as vezes que utilizei ajax no wordpress, eu tive que achar o elemento para atualizar.

    • joaopaulo 10:15 em 10 de novembro de 2013 Link permanente | Faça login para responder

      Surgiu outra dúvida aqui, se é um widget – e não uma página – ao ser inserido em qualquer página ou qualquer posição de widget do tema, essa busca por exemplo, poderia ficar na sidebar de uma interna de blog por exemplo, certo?

      No caso da imagem de exemplo está no contexto: O widget está na área de acervo mas não necessariamente busca apenas dentro da área de acervo, correto? Então, ao clicar em pesquisar, o usuário seria remetido à pagina de resultados da busca para – só então – conforme mude os filtros, essa atualização passar a vir via AJAX.

      Correto ou não?

      • Jacson Passold 19:00 em 12 de novembro de 2013 Link permanente | Faça login para responder

        ele não redireciona, tem duas situações possíveis:
        postback: recarrega a página filtrando
        callback: faz o ajax, esse é bem mais complicado, já que teria que “recarregar, pegando do conteúdo retornado somente os dados do id correto e atualizando.

        • João Paulo Apolinário 22:16 em 12 de novembro de 2013 Link permanente

          Entendi. Eu acho que precisa ser o recarregamento da página filtrando, porque vamos supor que o widget seja inserido numa página que lista posts mas não é uma “category.php”, é uma page-algumacoisa.php, customizada. Nesse caso, não necessariamente o plugin/widget vai encontrar a query dos posts da página atual.

          Tem outras situações problemáticas, como colocar o widget numa single de post, por exemplo.

          Imagino que um reload filtrado resolva o problema porque, caso ele esteja numa página “certa” de conteúdo a ser filtrado ela só recarrega a página, se for uma página distinta/errada ele direciona pra uma página customizada de resultados de pesquisa com os filtros selecionados.

          De qualquer maneira, preliminarmente estou construindo as queries de busca e filtro que serão usadas independente da estrutura.

    • joaopaulo 6:59 em 12 de novembro de 2013 Link permanente | Faça login para responder

      Para deixar essa minha dúvida mais tangível estou terminando a primeira versão preliminar do plugin entre hoje e amanhã e vou liberar para testes

    • Phillipe Trindade 23:41 em 13 de novembro de 2013 Link permanente | Faça login para responder

      Pessoal, não sei mais qual João Paulo é qual…

  • Jacson 11:54 em 6 de November de 2013 Link permanente |
    Tags: padroes   

    Padrões de Desenvolvimento, vamos discutir? 

    Precisamos definir os padrões de desenvolvimento, como por exemplo:

    widgets (blocos encaixáveis?)

    1) Ter uma pasta widgets dentro do plugin (extensão) ou tema;
    2) Dentro desta pasta ter para cada widget uma pasta com o nome da classe dele, e dentro da pasta o arquivo php com o mesmo nome representando a classe;
    3) Dois arquivos para os modelos de visualização->view.php, e formulário->form.php;
    4) Se for necessário css, coloca-los em uma pasta css;
    5) Se for necessário JavaScripts, coloca-los em uma pasta JS e evitar coloca-los dentro do código php ou html;

    Blocos de código;

    [comando]
{
     [bloco];
}

switch
{
    case "":
    {
          [bloco];
    } break;
}

    Nomenclatura de arquivos
    classes:
    1) Mesmo nome da classe;
    2) Um arquivo por classe, a não ser em caso muito específico;
    …

    Formato do Arquivo
    1) Fim de linha LF (fim de linha padrão unix)
    2) Sem shorttags;
    3) Inicio e fim da tag php:

    

    3) Evitar abrir e fechar tags htmls em arquivos separados, como por exemplo abrir no cabeçalho (header) e fechar no rodapé (footer)
    

    


     
    


    • 

  • 

 

    
Jacson

16:09 em 31 de October de 2013 
Link permanente
| 


 



    

    

    Maravilha Edu
    

    


     
    


    • 











 

 



 








c
escrever novo post


j
post seguinte/ comentário seguinte


k
 
post anterior/comentário anterior


r
 
Resposta


e
 
Editar


o
 
mostrar/esconder comentários


t
 
voltar ao topo


l
 
vá para login


h
 
mostrar/ocultar ajuda


shift + esc
 
Cancelar