Atualizar responseKey na em session/start.py

[sayyesassistant]

Igor,

Eu preciso que vc atualize o hidden field responseKey para que as responses possam ser atualizadas, veja o exemplo que eu usei:

$.post($('.session-tracker').attr('action'), $('.session-tracker').serialize(), function(data){ if(data.status == "success" && data.value.responseKey) { // update responseKey $('#responseKey').val(data.value.responseKey); } else { $('#sayyes-session').hide(); $('#sayyes-500').show(); } }, 'json');

Eu também deixei uma DIV lá para que a sessão seja finalizada se a response não puder ser cadastrada, se puder manter essa valiodação ótimo:

$('#sayyes-session').hide(); $('#sayyes-500').show();

Se precisar se um exemplo de sessão:

http://www.sayyes.cc/session/start.py?key=ahFzfnNheXllc2Fzc2lzdGFudHIUCxIHU2Vzc2lvbhiAgICAoLaxCgw

Abs

[hankpillow]

Fala Thiago, na verdade essa implementação ja esta rolando.

Da uma olhada na linha 137 do mock-service.py que eu tenho.

A diferença é que, ao invéz de retornar o responseKey direto no value, eu estou colocando ele dentro de um objeto e dentro de um array, dessa forma, se amanha vc quiser adicionar novos hiddens vc pode fazer isso sem precisar de nenhuma implementação de frontend.

Acho legal deixar isso num object separado ("hiddens" nesse caso) , pois esse resultado vai acabar ficando com mais itens (conforme a sugestão do ultimo email).

Se não funcionar ou vc tiver alguma dúvida me avise.

abs

[sayyesassistant]

Oi Igor,

Então, a responseKey sou eu que devolvo lá p/ view, ela é a chave para a atualização da response, não é uma forma de autenticação ou algo relativo a seguranã não.

É a primary key da entidade mesmo.

Quando seu script faz um POST via ajax lá para o response.py, a responseKey vem no retorno, ex:

{ "status": "success", "exception": null, "value": { "responseKey": "ahNkZXZ-c2F5eWVzYXNzaXN0YW50chwLEg9TZXNzaW9uUmVzcG9uc2UYgICAgICAwAoM" }, "message": "Response registered" }

Eu preciso que vc pegue essa responseKey que eu devolvo e coloque no formulário .session-tracker, no hidden input ID responseKey.

É a mesma coisa que vc faz com o campo ID viewName, que eu já vi que está sendo atualizado lá no session-tracker.

Eu preciso disso para que a SessionResponse seja atualizada ao invés de uma nova ser criada.

Se vc colocar num objeto, eu não tenho recursos para achar esse objeto na view, pois esses POSTs são submetidos juntos com a navegação pelas views.

Abs

[hankpillow]

Oi Thiago, acho que é mais simples do que parece.

Eu já estou lendo e escrevendo o responseKey, a diferença é que no result eu espero no javascript.

Hoje vc está mandando:

{
   status: "success",
   exception: null,
   message: "Response registered",
   value: {
            responseKey: "L97277SFUIS0GFBPHYJM2DDEK"
   }
}

E eu mudei um pouco esse result para esse formato:

(~/mock-service/request-view.json)

{
   status: "success",
   exception: null,
   message: null,
   value: {
      hiddens: [
         {
            responseKey: "L97277SFUIS0GFBPHYJM2DDEK"
         }
      ]
   }
}

A única diferença é que estou encapsulando o responseKey dentro de um array, pois dessa forma já deixamos o sistema flexivel para persistir quantos hiddens a gente quiser, assim como o userResponse que a gente está falando por email.

O que vc acha? se for problema eu mudo aqui e deixo o responseKey no root mesmo e blz também.

abraço,

[sayyesassistant]

Oi igor,

Sim, ultra OK sobre esse formato, não tem problema nenhum, ele é melhor sim.

Mas mesmo retornando dessa forma, vc precisa atualizar o form-tracker p/ que o responseKey volte p/ mim lá no python, da mesma forma que vc faz com o hidden viewName. É só por a chave lá.

Como tudo acontece no JS, eu não tenho recursos p/ saber que esses valores voltaram do python, entendeu?

Eu tô no server side....

Abs

[hankpillow]

Puuutz Thiago, que vergonha cara.

Eu ja tinha feito isso no inicio da semana, mas nao tinha feito merge pro master.

Acabei de fazer o merge e testar e esta tudo ok.

Já fiz push pro github também.

Ficou assim:

No primeiro request para trocar de view:

http://localhost:8088/mock-service/request-view.json

Post data:

sessionKey : abc-123-def-456 viewName : travel

Response:

{
   "status": "success", 
   "exception": null,
   "message": null,
   "value": {
      "hiddens": [
         {"responseKey": "FDWMPZGSG4STK5CJ8D312EIAT"}
      ]
   }
}

No segundo request para trocar de view:

http://localhost:8088/mock-service/request-view.json

Post data:

sessionKey : abc-123-def-456 viewName : beginning responseKey : FDWMPZGSG4STK5CJ8D312EIAT

Vc verá agora que a chave responseKey que foi enviada no primeiro requesta esta sendo enviada novamente para o server na proxima navegação.

Com isso acho que a gente mata esse issue.

[sayyesassistant]

Fantástico! Issue resolvida!