Depósito de idéias para o TWiki

Auto Save

Esse add-on é quase 100% Javascript com exceção de um script no serv para limpeza de auto-saves já finalizados ou esquecidos. A idéia é salvar o estado da edição em uma área temporária (do TWiki) de tempos em tempos como o gMail faz para impedir que o usuário perca tudo caso tenha uma perda de conexão ou travamento.

Fluxo:
  1. O usuário entra no modo de edição do tópico MeuTopico na web MinhaWeb
  2. O AutoSaveAddOn testa se já existe o tópico auto-save: AutoSaveWeb.%WIKINAME%_MinhaWeb_MeuTopico
    • Caso não exista, ou está vazio, não é preciso fazer nada.
    • Caso exista com conteúdo:
      1. Testa se a revisão do auto-save é igual a revisão atual do tópico.
        • Caso seja igual recupere o pergunte se o usuário quer recuperar o auto-save e execute a ação.
        • Caso seja diferente, avize e pergunte se o usuário quer recuperar o auto-save ou deleta-lo.
  3. Daí em diante a cada X segundos o AutoSaveAddOn salva a informação do tópico em edição no seu tópico de auto-save da seguinte forma:
    1. Cria o hash topicState
    2. Coleta o nome e valor de cada campo do form de edição e cria o hash topicState.form com estas informações
    3. Adiciona a revisão atual em topicState.rev
    4. Adiciona o data e hora atual em topicState.date
    5. Gera uma representação JSON de topicState
    6. Adiciona "\n/*\n   * Set ALLOWTOPICVIEW = %WIKINAME%\n*/" na string JSON
    7. Envia, via AJAX, a string JSON como valor do campo text para o tópic auto-save
  4. Quando o usuário clicar em "Salvar" o AutoSaveAddOn deve primeiro "apagar" o auto-save e só então submeter o form.

Notas:
  • Para recuperar o conteúdo deve-se visitar a URL do tópico auto-save via AJAX com ?raw=on&template=pattern&skin=text
  • Prototype já provê a infra para fazer isso.

Comente:

Essa idéia é matadora. Mas tem que pensar como é que vai ser quando o cara entrar pra editar e a versão do tópico salvo automaticamente for mais recente que a versão que o cara está editando (por exemplo quando rola um crash no browser e o cara volta pra editar.

Mas pensando bem … não seria melhor simplesmente adicionar uma versão AJAX à funcionalidade de "Checkpoint" que o TWiki já tem?

-- AntonioTerceiro - 04 Oct 2007

AJAX no Checkpoint é uma… mas se não quisermos salvar antes de completar? E acho que é aí que isso fica realmente útil pq clicar no Checkpoint vez em quando não é difícil.

-- AurelioAHeckert - 09 Oct 2007
 




Interação Predefinida com Visitantes Não Autenticados

Seria interessante prover a possibilidade de se criar enquetes ou comentário no TWiki, abertos para usuários não logados, mas sem abri-lo para que seja editável sem login (a-lá Wikipedia).

Podemos definir modelos claros de colaboração não autenticada usando a infra já existente. wink

O necessário é criar a notação que define a interação e um script que a entenda e receba submissões de visitantes. Esse script terá o nome pipe.

Creio que o melhor é termos um tópico contendo uma lista de informações para o pipe.

Exemplo de definição para comentário aberto ao público em Blogs TWiki based no tópico Blogs.Comments.GestCommentDef:
  • script: save
  • user: UnknowGest
  • web: Blogs.Comments
  • topic: Comment%PIPEPARAM{comment-to}%XXXXXXXXXX
  • add param: topicparent=%PIPEPARAM{comment-to}%
  • add param: formtemplate=CommentForm
  • add param: date=%GMTIME{"$rcs"}%

Como acontece…
O visitante preenche um form que contém os campos comuns de comentário e um input oculto de nome def com o valor Blogs.Comments.GestCommentDef e action para %SCRIPTURL{pipe}%.
<form action="%SCRIPTURL{pipe}%">
  <input type="hidden" name="def" value="Blogs.Comments.GestCommentDef" />
  <input type="hidden" name="comment-to" value="%BASETOPIC%" />
  <input name="nome" />
  <input name="e-mail" />
  <textarea name="text"></textarea>
  <input type="submit" value="Enviar" />
</form>

Note que Blogs.Comments é o nome da Web. Comments é uma sub-web de Blogs


Exemplo de definição para enquete aberta ao público no tópico Colivre.SoftwarePoolDef:
  • script: save
  • user: UnknowGest
  • web: Colivre
  • topic: SoftwarePoolData
  • add param: comment_action=save
  • add param: comment_type=tableappend
  • add param: comment_index=0
  • valid values for "comment":
    • GIMP
    • Inkscape
    • Firefox
  • only exec pipe if: "%GETCOOKIE{SoftwarePool}%" ne "voted"
  • set cookie "SoftwarePool":
    • value: voted
    • expires: 01-01-2020 00:00:00

O form para que o usuário envie seu voto:
<form method="post" action="%SCRIPTURL{pipe}%">
  Software preferido:
  <select name="comment">
    <option>GIMP</option>
    <option>Inkscape</option>
    <option>Firefox</option>
  </select>
  <input type="submit" value="Enviar" />
</form>

Essa idéia se aproveita de funcionalidades do CommentPlugin. A prova de conceito da base de dados e contagem feitas desta forma pode ser vista em Sandbox.CommentTest.

Notas:
  • script, web, topic e user só podem ser definidos no tópico de definição.
  • o script deve ser executado via interface de linha de comando.

Comente:

 




Código PERL em Tópicos (Whitelisted)

Temos criado TWikiAplications cada vês mais complexas e exigimos uma overhead desnecessário em alguns casos para solucionar problemas como a sequência de renderização de variáveis ou (mais raro) ação inesperada do TWiki, dada a complexidade de uso não planejada para as variáveis. Outro problema é que fazemos uso avançado das varáveis que poderia ser feito com usao direto da API do TWiki sem exigir interpretação de variáveis e execução de funções que preparam o resultado para o uso final quando ainda queremos algo intermediário.

Bem… Se pudéssemos colocar código PERL num tópico, assim como colocamos Javascript, as TWikiAplications ganhariam um salto qualitativo em legibilidade e performance, além da abertura de novas possibilidades. Contudo temos que nos preocupar com erros casuais ou ações mal intencionadas.

Para que isso seja possível temos que limitar claramente uma lista de funções/funcionalidades que o usuário pode colocar em seu código. Qualquer função/funcionalidade fora desta lista faz com que o TWiki simplesmente não execute o bloco de código e renderize uma mensagem de erro no local indicando o que ele encontrou de inadequado.

O foco será em dar acesso direto e simplificado a API do TWiki, mas mesmo a API acessível será restrita a um sub-conjunto de funções de coleta de informação, nada que modifique ou crie arquivos deve ser acessível.

As variáveis também serão protegidas. Cada referência a variável no código deverá ser traduzida para um item de hash. Algumas variáveis do ambiente (nada de crítico) serão copiadas nesse hash antes da execução para que seu valor seja acessível. Exemplo de como deve acontecer: $fruta vira $protectVar{'fruta'}. Desta forma todas as variáveis serão globais. Já é melhor que antes, mas pode melhorar.

Alguns caracteres serão reconhecidos como separadores de palavras, tudo o que estiver entre eles deve ser ou variável ou uma função/funcionalidade permitida, caso contrário retorna erro.

Separadores: espaço tab quebra-de-linha ( ) [ ] { } . ; , → = == != eq ne

funções/funcionalidades permitidas:
  • if
  • while
  • for
  • foreach
  • <
  • >
  • abs
  • index
  • int
  • join
  • readTopicText
  • searchInWebContent

Metodos de TWiki::Func poderão ser chamados diretamente TWiki::Func:: será adicionado a esses nomes depois do filtro.

Strings: apenas as de aspas simples para impedir interpretação de código embutido.

Como filtar:
  1. converter as strings em valores do @protectStr
  2. limpar cometários
  3. fazer split do código usando os separadores como base
  4. testar cada item do array do código para identificar palavra fora da whitelist
    1. Algo não permitido: Descreve erro e finaliza
    2. Tudo ok:
      1. protege variáveis
      2. adiciona TWiki::Func:: nos métodos deste módulo
      3. executa.

Comente:

se a idéia é usar uma linguagem, acho que é mais sustentável fazer um compilador pra uma linguagem simplezinha, ou mesmo embutir um interpretador Javascript dando acesso a alguma coisa do TWiki.

-- AntonioTerceiro - 04 Oct 2007

Pensei assim porque acredito que será bem mais fácil e leve simplismente dar um eval num código PERL, por isso quero filtra-lo com Whitelist wink

-- AurelioAHeckert - 09 Oct 2007
 
Topic revision: r1 - 05 Jul 2008, UnknownUser
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Wiki-Colivre? Send feedback